Lets assume we have the following test setup.
discworld_pdc (Samba PDC)
discworld_samba (domain member with 'map untrusted to domain = yes')
If we connect from discworld_client to discworld_samba (master or 3.6) with the following command:
smbclient -U WURSTBROT+bob%secret //samba.discworld.site/wurst
We get an error that the password is wrong. If we do the same the the winxp member, then we can successfully log in.
The second response sent by NTLMv2 uses a variable length client challenge which includes the domain name:
v2-Hash = HMAC-MD5(password, user name, domain name)
We have currently a bug that with "map untrusted to domain" we change the domain name of the response to the mapped domain name. So if the PDC tries to build the v2 hash it uses the mapped domain name and fails.
Created attachment 8797 [details]
Created attachment 8813 [details]
Created attachment 8814 [details]
Karolin, please add the patches to the next releases. Thanks!
Pushed to v3-6-test and autobuild-v4-0-test.
Pushed to v4-0-test.
Closing out bug report.
From the samba mailing list:
[Samba] 3.6.15/fix for BUG 9817 breaks our cross-domain support
Thomas Werschlein thomas.werschlein at geo.uzh.ch
Fri Aug 23 07:43:58 MDT 2013
Previous message: [Samba] CUPS working but errors from Windows clients accessing printer
Next message: [Samba] Samba4: Internal DNS doesn't forward
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
We discovered that the the patch for BUG 9817 (https://bugzilla.samba.org/show_bug.cgi?id=9817) which was first included into Samba 3.6.15 breaks our cross-domain setup:
AD DC Domain "AD" [WinServer 2003 R2]
AD DC Domain "D" [WinServer 2008 R2]
client_1 (domain member in AD, WinServer 2003 R2)
samba_srv (domain member in D, OmniOS)
Usernames and passwords are externally synchronized between the two domains AD and D.
There is no domain trust between A and AD.
In smb.conf we have set "map untrusted to domain = yes" in order to allow cross-domain access (AD -> D) to file resources:
When a user is logged in as AD\user to client_1, he is able to access \\samba_srv\someshare without entering his username/password again (although samba_srv is member of domain D, not AD).
This behaviour stopped working with Samba 3.6.15.
Reverting the patch for BUG 9817 (setting "params.domain_name = user_info->mapped.domain_name" in source3/auth/auth_winbind.c as it used to be) did "fix" it for us and brought back the cross-domain support we currently depend on.
This is not to say that Samba is wrong: the reasoning for patch 9817 sounds obvious after all. But somehow it does not work for our peculiar setup.
Thomas Werschlein, IT Service Management
Department of Geography, University of Zurich
Andreas, is the described behaviour by design or does the fix introduce a new bug?
The patch is correct and needs to be this way with NTLMv2. The feature is for NT4 style domain controllers. If you use it with 'security = ads' I think you should not hit this code path. I suggest to open a new bug and attach the output of 'testparm' and describe your setup in more detail.