[Samba] Access to s3 shares when userPrincipalName differs from the sAMAccountName

[Andrew Bartlett]

On Wed, 2011-02-16 at 17:07 +0100, Angelos Oikonomopoulos wrote:
> On 02/07/2011 05:38 PM, Angelos Oikonomopoulos wrote:
> > On 02/04/2011 02:30 AM, Andrew Bartlett wrote:
> >> On Thu, 2011-02-03 at 10:39 +0100, Angelos Oikonomopoulos wrote:
> >>> Hello all,
> >>>
> >>> I've been trying to use a Samba3 fileserver with security = ADS in a
> >>> domain where the DC is Samba4. It all seems to work, except for users
> >>> with long names.
> >>
> >> Is the authentication using NTLM or Kerberos?
> >
> > Well, the negotiate protocol request/response packet pair between the s3
> > fileserver and the client decide on NT LM 0.12, then I'm seeing
> > communication of the client with the DC on the kerberos port and finally
> > a Session Setup AndX Response with STATUS_LOGIN_FAILURE. So I originally
> > assumed it's using a kerberos ticket.
> >
> > On the samba3 server, with log level set to 10, I get
> > NT_STATUS_LOGON_FAILURE because this test user is 'invalid on this
> > system'. Winbindd agrees of course:
> >
> > root at labrat:~# wbinfo -i arnold.schwarzenegge
> > arnold.schwarzenegge:*:11293:10513:Arnold
> > Schwarzenegger:/home/FPC/arnold.schwarzenegge:/bin/bash
> > root at labrat:~# wbinfo -i arnold.schwarzenegger
> > Could not get info for user arnold.schwarzenegger
> >
> > The traces are available at http://www.fp-commerce.de/debug/s3auth.dump
> > and http://www.fp-commerce.de/debug/samba_log.192.168.20.74. The first
> > capture was generated by running wireshark from the administrator
> > account on the box, then logging in as arnold.schwarzenegger at fpc.local,
> > then running a ping against 192.168.20.43, then listing the network
> > machines from the file manager, then double-clicking on LABRAT (the s3
> > fileserver).
> >
> > The client is .20.74 (hostname WSN-01-044, a windows 7 box), the DC is
> > .20.43 (hostname dc1) and the test fileserver (hostname labrat) is
> > .20.63. The S4 server is running git master from 16-11-2010, while the
> > S3 server is running debian squeeze (the samba version is 3.5.6~dfsg-3).
> >
> > The relevant sections from labrat's smb.conf can be found at
> > http://www.fp-commerce.de/debug/s3-smb.conf and the s4 one at
> > http://www.fp-commerce.de/debug/s4-smb.conf.
> >
> >> Either way, this is unlikely to be a Samba3 bug, given that it's not
> >> been raised before, so perhaps re-raise the issue on samba-technical,
> >> with network traces etc to show what's going on, and I'll happily look
> >> into it for you.
> >
> > Thanks for taking an interest, I hope this is some configuration error
> > on my part and can be resolved without too much effort :)
> 
> After Andrew kindly confirmed it was not a problem with my configuration 
> and hinted that the correct approach would most likely be to modify s3 
> to not use the kerberos user principal name, I tried the attached 
> trivial patch to the test s3 fileserver. With this patch, accounts with 
> long usernames can access the share without any issues.

Great!

> Now I'm not absolutely sure this will not create subtle bugs, so I'm 
> posting it here for review. I'd gladly create and/or test a more robust 
> patch (for instance the second hunk assumes that if we have the 
> logon_info data, then the account name will be valid, which I'm not sure 
> is always the case. Other code in the same function e.g. checks that 
> logon_info->info3.base.domain.string is not NULL).

As far as I'm aware, logon_info->info3.base.domain.string will always be
non-NULL in a PAC.  From memory, the docs claim it could be NULL in a
netlogon reply from NT4 servers at one point.  (And such checks tend to
be copied about). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.