Bug 9817 - 'map untrusted to domain' does not work with NTLMv2
'map untrusted to domain' does not work with NTLMv2
Product: Samba 3.6
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Andreas Schneider
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2013-04-19 14:33 UTC by Andreas Schneider
Modified: 2013-09-03 05:55 UTC (History)
6 users (show)

See Also:

master patch (1.26 KB, patch)
2013-04-20 10:05 UTC, Andreas Schneider
no flags Details
v4-0-test patch (1.52 KB, patch)
2013-04-24 15:58 UTC, Andreas Schneider
gd: review+
asn: review? (metze)
v3-6-test patch (1.52 KB, patch)
2013-04-24 15:59 UTC, Andreas Schneider
gd: review+
asn: review? (metze)

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schneider 2013-04-19 14:33:30 UTC
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.
Comment 1 Andreas Schneider 2013-04-20 10:05:00 UTC
Created attachment 8797 [details]
master patch
Comment 2 Andreas Schneider 2013-04-24 15:58:27 UTC
Created attachment 8813 [details]
v4-0-test patch
Comment 3 Andreas Schneider 2013-04-24 15:59:15 UTC
Created attachment 8814 [details]
v3-6-test patch
Comment 4 Andreas Schneider 2013-04-25 12:37:14 UTC
Karolin, please add the patches to the next releases. Thanks!
Comment 5 Karolin Seeger 2013-04-30 07:54:08 UTC
Pushed to v3-6-test and autobuild-v4-0-test.
Comment 6 Karolin Seeger 2013-04-30 10:59:17 UTC
Pushed to v4-0-test.
Closing out bug report.

Comment 7 Karolin Seeger 2013-08-28 10:05:11 UTC
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
PGP-Key-ID: C76C851B
Comment 8 Karolin Seeger 2013-08-28 10:06:35 UTC
Andreas, is the described behaviour by design or does the fix introduce a new bug?
Comment 9 Andreas Schneider 2013-09-03 05:55:00 UTC
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.