Andrew, I have completed my research with regard to question 4. The authenticated SNTP request uses RID's of trusted accounts. There is nothing in the protocol to exclude non-computer objects, or using RID's of accounts which are disabled or not able to log in.
With that said, the implementation in windows server uses the NetrLogonGetTrustRid, which will only return RID objects related to computer accounts. Our implementation uses the NetrLogonComputeServerDigest function to compute the crypto-checksum based on the password associated with the RID and the contents of the packet being returned. This is detailed in section 1.5.2 of the MCPP MS-SNTP document located at http://msdn.microsoft.com/en-us/library/cc246890.aspx. Let me know if further clarification is needed. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2" Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] -----Original Message----- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2008 8:38 PM To: Richard Guthrie Cc: [EMAIL PROTECTED] Subject: RE: How are disabled accounts handled in SNTP On Fri, 2008-05-30 at 15:33 -0700, Richard Guthrie wrote: > Andrew, > > I will be working with you on request. I wanted to summarize your questions > so I can accurately respond to them. I see # issues/clarifications in this > email. > > 1. What is the correct response from a server responding to SNTP request when > the request contains a RID that is disabled? > 2. What if the account does not have rights to the server it is making an NTP > request to? In particular, what is the behaviour when an account is expired etc. > 3. When responding to an SNTP request from a client with a disabled account > , should the service respond with an MD5 checksum that includes a checksum > with the password? > 4. What object classes are eligible to make a NTP request using this protocol? > 5. Do windows clients only use the RID returned from the ServerAuthenticate3 > NETLOGON call? > > Have I captured your request correctly. Please acknowledge and I will start > to work on these issues. With that amendment, this is a start. A discussion of the risks of offline password guessing should be included in the security section, mitigated by the answers to my other question. If you don't understand why this protocol is subject to offline password guessing attacks, then perhaps that needs to be clarified first. > Richard Guthrie > Open Protocols Support Team > Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, > TX - 75039 "Las Colinas - LC2" > Tel: +1 469 775 7794 > E-mail: [EMAIL PROTECTED] > > -----Original Message----- > From: Andrew Bartlett [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 27, 2008 1:18 AM > To: Interoperability Documentation Help > Cc: [EMAIL PROTECTED] > Subject: How are disabled accounts handled in SNTP > > In MS-SNTP, the RID is used as a key ID. No indication is given as to what > should happen if the account indicated by this RID is disabled, expired or > otherwise not permitted to log in. > > Should this account password be confirmed by returning an MD5 checksum > including this password? This should be dealt with in the security section, > as well as the protocol implementation description. > > Also, are all accounts eligible as NTP clients, or only certain objectClasses > (such as 'computer')? (Because of the use of raw keys, and the possibility > of an offline attack, this should be restricted as much as possible). > > Finally, do windows clients only use the RID returned from the > ServerAuthenticate3 NETLOGON call? Could a more secure implementation be > derived such that the ID returned by this call is not the RID? (This would > allow offline attacks on the password only after the NetLogon exchange). > Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
