Bug 2976 - Win2k member workstation authentication order different when in Samba domain
Summary: Win2k member workstation authentication order different when in Samba domain
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DCE-RPCs and pipes (show other bugs)
Version: unspecified
Hardware: All Linux
: P1 major (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on: 12709
  Show dependency treegraph
Reported: 2005-08-10 12:54 UTC by John Janosik
Modified: 2017-06-29 07:04 UTC (History)
5 users (show)

See Also:

sets authoritative field to 0 when domain name doesn't match (632 bytes, patch)
2005-08-10 13:27 UTC, Jim McDonough
no flags Details
Volker's work in progress patch for master (59.86 KB, patch)
2017-03-16 21:50 UTC, Andrew Bartlett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Janosik 2005-08-10 12:54:51 UTC
We have the following:

A:  Standalone Windows workstation with userid X and password Y.
B:  Win2k workstation member of domain but with local userid X and password Y.

User X logs into workstation A and runs an app that maps a drive to workstation
B.  The application does not specify a userid or password in the mapping.  We
have no control over the application to change this.

When workstation B is a member of an NT domain this works OK.  When workstation
B is a member of a Samba domain the mapping fails.
Comment 1 Jim McDonough 2005-08-10 13:27:51 UTC
Created attachment 1365 [details]
sets authoritative field to 0 when domain name doesn't match

From John:

It turns out that NT sets the authoritative field in the NetrLogonSamLogon
reponse to 0 when the domain name does not match.  Here is the patch that is
working for me.


If the domain is a trusted domain instead of an unknown domain would the NT
server set authoritative to 1.
Comment 2 John Janosik 2005-08-11 07:56:28 UTC
I tested and NT does set authoritative to 1 when the domain is a trusted domain.
 Jim also brought up that we might need to do a case-insensitive match.  I'll
get a new patch tested and attached.
Comment 3 Jim McDonough 2005-08-12 08:28:59 UTC
Fix from John checked in, r9261.  Thanks!

The fix is not the above patch.  It also checks if it's not a domain we know and
if the user doesn't exist.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:25:26 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 5 Volker Lendecke 2017-03-14 10:31:20 UTC
This is not properly solved in both the classic as well as the AD DC. Assigning to Andrew for a proper fix.
Comment 6 Andrew Bartlett 2017-03-16 21:50:45 UTC
Created attachment 13076 [details]
Volker's work in progress patch for master

Attached is the work progress Volker posted to samba-technical for comment in March 2017.  I attach it here so it is not lost.

Per https://lists.samba.org/archive/samba-technical/2017-March/119395.html there are a number of concerns that need to be addressed, but while tedious these are not insurmountable:

 - make changes in sync between the two auth subsystems (the current
patch set removes the offensive flag, but only in auth3)
 - not attempt a change to inter-process communication in the same
patch set (eg move to "sam" and "samba4:sam" if specifying auth module
lists in winbindd)
 - clearly distinguish between the 'smbd as client' and
'ntlm_auth/wbinfo as client' cases in winbindd.
 - use *authoritative as the indicator. 
 - have tests (both for the specific change desired, and for the other
areas touched like rodc)
 - be bisectable

In preparation for this patch set, "map untrusted to domain" has been marked as deprecated in master.  We also need to carefully consider the change in behaviour in the AD DC, and if some users may be inadvertently relying on it.
Comment 7 Andrew Bartlett 2017-06-27 18:58:16 UTC
I think this is now fixed in master for 4.7 with dda4c891268e79b3aba317fae93ca0eacc2fcdd5