Mapping workstation\user to domain\user incorrectly?

[Steven Danneman]

This last week I've gone even further down this rabbit hole, and found a
few more issues in authenticating local users to a domain which has a
user of the same name. 

 

First off, when passing WORKSTATION\user local credentials to a Windows
domain member (both Win2K and Win2K3) I haven't seen that server pass
them onto the DC for authentication.  Every time, the Windows server
recognizes that the workstation name given as the domain is not part of
any trusted domain it can authenticate against and immediately returns
STATUS_TRUSTED_RELATIONSHIP_FAILURE (Win2K) or STATUS_LOGON_FAILURE
(Win2K3) to the client.

 

Whereas Samba 3.0.24 converts the WORKSTATION to its domain and asks the
DC for credentials or with my following patch, leaves the WORKSTATION
name, but still asks the DC for credentials.

 

Index: auth/auth_util.c

===================================================================

--- auth/auth_util.c    (revision 82495)

+++ auth/auth_util.c    (working copy)

@@ -169,14 +169,6 @@ NTSTATUS make_user_info_map(auth_usersup

        else

                domain = lp_workgroup();

 

-       /* do what win2k does.  Always map unknown domains to our own

-          and let the "passdb backend" handle unknown users. */

-

-       if ( !is_trusted_domain(domain) && !strequal(domain,
get_global_sam_name()) )

-               domain = my_sam_name();

-

-       /* we know that it is a trusted domain (and we are allowing
them) or it is our domain */

-

        result = make_user_info(user_info, smb_name, internal_username,

                              client_domain, domain, wksta_name,

                              lm_pwd, nt_pwd,

 

I thought sending the known un-authenticatable WORKSTATION\user pair to
the DC would still result in correct, if not a little inefficient,
behavior.  However, we have a customer, whose account lockout policy (5
times within 30 minutes) for DOMAIN\user is still triggered by multiple
bad authentication attempts with WORKSTATION\user.  I haven't been able
to reproduce this exact policy in my own test domain, but it's
definitely happening in theirs.  Perhaps this is a bug in Windows, whose
account lockout policy code doesn't expect to be sent WORKSTATION\user
pairs that have match the username of a user in the domain.

 

Regardless, I've tried to make Samba behave more like a Windows domain
member, passing on credentials for known and trusted domains, but
automatically denying credentials for unknown domains.  The following
small patches do just that, though this is my first foray into the
winbindd code so I'd appreciate a review if I'm making incorrect
assumptions about these subsystems.

 

Index: auth/auth_winbind.c

===================================================================

--- auth/auth_winbind.c (revision 82495)

+++ auth/auth_winbind.c (working copy)

@@ -86,7 +86,9 @@ static NTSTATUS check_winbind_security(c

        ZERO_STRUCT(request);

        ZERO_STRUCT(response);

 

-       request.flags = WBFLAG_PAM_INFO3_NDR;

+       if (lp_allow_trusted_domains())

+               request.flags |= WBFLAG_PAM_CONTACT_TRUSTDOM;

+       request.flags |= WBFLAG_PAM_INFO3_NDR;

 

        request.data.auth_crap.logon_parameters =
user_info->logon_parameters;

 

Index: nsswitch/winbindd_pam.c

===================================================================

--- nsswitch/winbindd_pam.c     (revision 82495)

+++ nsswitch/winbindd_pam.c     (working copy)

@@ -229,10 +229,9 @@ static struct winbindd_domain *find_auth

                        DEBUG(3, ("Authentication for domain [%s]
skipped "

                                  "as it is not a trusted domain\n",

                                  domain_name));

-               } else {

-                       return domain;

-               }

                }

+               return domain;

+       }

 

        return find_our_domain();

 }

 

-Steven

 

> 

> Hello All,

> 

> I'm having an authentication problem in Samba 3.0.24 and have some

> questions about an implementation decision.

> 

> Let me first explain my setup.  I have a Win2K3 domain 2K3D, a Samba

> server acting as a domain member, and a Win2K3 client in its own

> workgroup.

> 

> W2K3Client ----> Samba Domain Member ----> Win2K3 DC

> 

> There exists a domain user "testuser" and on the client machine there

> exists a local user with the same name.

> 

> On the W2K3Client I am logged in as the local user W2K3Client\testuser

> and I attempt to access a share on the Samba server using Windows

> Explorer and the UNC path \\SambaDM\share.

> 

> Now I expect my default W2K3Client\testuser credentials to be used,
fail

> against the Samba server because W2K3Client is not recognized as a

> trusted domain, and then be prompted for proper credentials by Windows

> Explorer.

> 

> What actually happens is Samba realizes it can't recognize the

> W2K3Client domain, changes the domain to that which it's a member of

> 2K3D, then attempts to authenticate against the DC, but fails because

> the password is incorrect.  Furthermore the domain has a lockout

> password policy after 5 bad attempts, which is met in a single UNC

> access attempt.

> 

> I've traced this behavior to auth/auth.c:make_user_info_map() which

> purposefully converts the domain with the comment:

> 

> /* do what win2k does.  Always map unknown domains to our own

>    and let the "passdb backend" handle unknown users. */

> 

> I've attempted to recreate this myself using a Win2K server in place
of

> Samba with the same domain and client, but in those cases Win2K does
not

> change the given domain, but instead realizes that W2K3Client is not a

> trusted domain and returns STATUS_TRUSTED_RELATIONSHIP_FAILURE.

> 

> Does anyone know/remember the configuration where a Win2K file server

> will act this way?  For the moment this seems like incorrect behavior
to

> me because of the local user/domain user conflict demonstrated.

> 

> Thanks,

> 

> Steven Danneman |  Software Developer

> Isilon Systems    P +1-206-315-7500    F +1-206-315-7485

> www.isilon.com

> 

> How breakthroughs begin.(tm)