[PATCH]: wbc: expand wbcAuthUserParams to pass alternate domain\user

[Steven Danneman]

> On Tue, May 19, 2009 at 07:22:14AM +0200, Volker Lendecke wrote:
> > On Mon, May 18, 2009 at 05:11:16PM -0700, Steven Danneman wrote:
> > > I wanted to get RFC on an addition to the wbc interface.  Kai, I
> > > know you've been working on this recently so your opinion would
> help.
> >
> > I'm fine with the idea as long as you also provide a winbind
> > implementation of it and not only modify the Likewise authentication
> > daemon.
> 
> If I get it right this should read as "As long as you also fix
> nsswitch/libwbclient/wbc_pam.c", right? This would not modify the wb
> pipe protocol?
> 
> Volker

Thanks for everyone's feedback.  I've condensed responses to everyone in
one email.

I'm happy extend the winbindd implementation as well, which would
require a change to the wb pipe protocol, but the problem this patch
fixes is specific to authenticating local users, which winbindd doesn't
currently support.

In the case of an AD user authenticating to smbd via NTLMv2, both the
domain and username sent over the wire (and thus the ones used in the
creation of the NTLMv2 hash) are the same credentials which smbd must
pass onto winbindd and winbindd onto the AD.   Thus there's no need to
send extra information via wbc, and we just use the existing
account_name and domain_name fields of struct wbcAuthUserParams.  The
on-the-wire domain given to smbd is not remapped, because it is
recognized as trusted, and the username is only remapped (vis username
map) after authentication succeeds.  In this scenario the auth_winbind
module is used, with no modification along with the
wbcAuthUserParams.response struct.

Authenticating a local user outside of smbd is different.  The
on-the-wire domain name may be the client's machine name, or it may be
an empty string (Vista sends this).  smbd in make_user_info_map(),
converts this to the SAM name of the server.  So we now have
"client_domain" and "domain" respectively.  Username mapping, for local
users, is done pre-authentication so that the mapped-to user and
password will be used in the authentication checks.  This is what
auth_sam.c does.  This gives us the on-the-wire user, used in the hash,
"smb_name" and the mapped-to user "internal_username".

In order for the authentication daemon to provide the same local auth
support as smbd, all four of these variables need to be passed to it via
wbc.

> I agree with the basic design, but I don't like this struct being
> called response2. Some name telling what the struct is about would be
> nicer. Unless we really want to use response2 instead of response in
> all callers now anyway, then I guess response2 makes sense.

Unfortunately, we do need two separate structs here, as the on-the-wire
domain can be the empty string.  Thus, we have need to pass the empty
string in response2.domain_name, and therefore have no way for the
server to tell that it shouldn't use this field, unless it strictly
isn't present.  While this struct is specific to NTLMv2 auth, the
RESPONSE struct can also be used for NTLMv2, so just versioning the
struct with "2" seemed to be the least confusing.  I agree, some
documentation explaining the difference is needed.

> Aren't you breaking the code in auth_util.c for people not using
> auth_wbc?

This is really a separate patch and I'll put it out as so.  Removing the
automapping of an empty string domain to our workgroup, allows all
domain mapping to be handled by the block of logic below it.

So essentially, if "map untrusted to domain" is false (the default),
both unknown and blank domains will be treated as the local SAM.  If it
is true, we do legacy behavior and replace them with our primary domain.

I believe this should work for all auth backends.  Do you see a way that
it won't?

-Steven