On Wed, 2008-07-02 at 07:30 -0700, Richard Guthrie wrote: > Andrew, > > I have completed my research with respect to NetrServerAuthenticate3. > Your original question was around whether there any other methods > other than NetrServerAuthenticate3 that return the RID of the > authenticated account in a thread on MS-SNTP. With respect to MS-SNTP > and the Windows Time Service , it starts account authentication with a > call to NetrLogonGetTrustRid. The documentation discusses the > Netlogon method NetrLogonGetTrustRid > (http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-SNTP%5D.pdf) > in section 1.5.2 of the current doc set. > > This method under the covers makes a call to NetrServerAuthenticate3 > in the case where the time service is located on a member server. > Details of NetrServerAuthenticate3 can be found here > (http://msdn.microsoft.com/en-us/library/cc208186.aspx). The RID is > retrieved as a return value from establishment of a session key used > for the secure channel. > > If however the time service is located on a DC that is in the domain > of the account to be authenticated, NetrLogonGetTrustRid looks at the > local SAM database to get the account and its associated RID. There > never is a call to NetrServerAuthenticate3 in this case. > > I have requested that the MS-NRPC documentation (section 3.5.4.7.1), > be updated to reflect this and will let you know the results of that > investigation. Does this answer your question?
I think so. Will the client always talk to the server it has done a NetrServerAuthenticate3 against to then requiest MS-SNTP authenticated time? (Where I'm going with this is that I could, in securing the MS-SNTP protocol, restrict SNTP access to clients who have done a NetrServerAuthenticate3 call and domain controllers, per you answer above, or if - and I have not yet asked this - the NetrServerAuthenticate3 returned RID is only used for MS-SNTP, then we could return another arbitrary 32 bit number, and key with that.) Thanks Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
