[cifs-protocol] 114082011718524 NTLM username / password routing on member servers and on an AD DC

[Sreekanth Nadendla]

Hello Andrew,                        
Domain Controller maintains the state of hasPartialReplicaNCs, msDS-HasInstantiatedNCs. When there are changes to be replicated, it can happen in the following two ways.

1) Scheduled Replication.
2) Event-Driven Replication.

From MS-ADTS 3.1.1.5.1.5   
When an originating or replicated update occurs in the NC replica on the server, the server notifies each destination DC that has an entry in repsTo. The server notifies the destination DC by calling method IDL_DRSReplicaSync. The destination DC contacts the server and requests it to provide updates—this is event-driven replication as described in section 3.1.1.1.14.

For a description of what needs to happen to replicate changes from Samba DC side, please review MS-ADTS 3.1.1.1.14  "Scheduled and Event-Driven Replication".  Note the reference to MS-DRSR which provides protocol details on how to perform replication between domain controllers.

Some Helpful Resources

Replicas subtypes are defined in:
[MS-ADTS] 3.1.1.1.5 NC, NC Replica
http://msdn.microsoft.com/en-us/library/cc223168.aspx

Some general use cases are described in:
[MS-ADOD] 2.7.5 Directory Replication
http://msdn.microsoft.com/en-us/library/hh871845.aspx

Let me know if you have further questions.


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Tuesday, August 19, 2014 11:39 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: NTLM username / password routing on member servers and on an AD DC


I've got Samba to the point where Samba can be a subdomain to a windows AD domain, something we have been working on for a number of years.

As context, we did some work on this at a number of previous plugfest events, and this work has been mostly to re-animate this effort, and to make it useful to end users, by having it also work for NTLM authentication.  

In doing NTLM authentication, it has become clear to me that I need a much more correct routing solution than I've used to date.  That is, for a username of user at mycompany.com (A UPN not associated with any domain), user at my.domain.com, user at sub.my.domain.com or SUB\user, how do I, potentially not being a global catalog server, work out that a user has this SPN, and route that to the appropriate trusted domain?  

How should I work these things out first as a domain member (eg a file server), and more particularly as a DC?

It appears from our previous investigations that as a domain member, we should authenticate locally if the username in SERVER\user, then forward to a DC, and if the DC returns NO_SUCH_USER but not authoritative (a flag on the SamLogon reply), then to try and authenticate locally.

Is there a similar pattern of forwarding required on the DC, perhaps to a global catalog server who may know the fill set of users in the forest?

As an added degree of difficultly, If there are 3 domains, in the typical parent-and-two-child pattern, how do I work out the 'route'
across the transitive trust?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba