[Samba] Access to s3 shares when userPrincipalName differs from the sAMAccountName
angelos.oikonomopoulos at fp-commerce.de
Wed Feb 16 09:07:40 MST 2011
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
> 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
> 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
>> 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.
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1006 bytes
Desc: not available
More information about the samba-technical