Good morning Andrew. Thanks for your feedback. I have interpolated available information below.
>> Andrew - I think I might have missed a previous email of yours. If so, I >> offer my apologies. >> >> The actual Windows behavior is - as Matthias noted previously - that >> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints >> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4). > >OK, When will this security bug be addressed? I thought I saw a difference in >this behaviour for Windows 2008 - >honestly I was expecting 'Windows 2008 >fixed this' as your reply. This is currently 'work-in-progress', and I will update you as soon as I have information. My understanding is that this is not an issue with releases after Windows 2003 (which matches with your comments concerning Windows 2008). >> We are currently working on which document this should be addressed in >> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct >> place, since SPN validation is carried out by Active Directory, >> outside the scope of the NetLogon protocol. I do not yet have any >> information concerning whether or not any product bugs will be filed, >> but I have alerted the appropriate folks here at Microsoft. That may >> impact any forthcoming Windows Behavior notes. >OK. I would appreciate an update on what the expected long-term behaviour of >Microsoft products will be, so we >know what we must emulate. (Oh the joys of >bug-for-bug compatibility) Some of this will depend on Windows 2003 and earlier bug/fix details. I will keep you advised! >Thanks for the detail. I look forward to being able to use it some day :-) My pleasure! Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Monday, August 24, 2009 7:30 PM To: Bill Wesse Cc: [email protected]; [email protected]; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-08-24 at 07:35 -0700, Bill Wesse wrote: > Andrew - I think I might have missed a previous email of yours. If so, I > offer my apologies. > > The actual Windows behavior is - as Matthias noted previously - that > NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints > (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4). OK, When will this security bug be addressed? I thought I saw a difference in this behaviour for Windows 2008 - honestly I was expecting 'Windows 2008 fixed this' as your reply. > We are currently working on which document this should be addressed in > ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct > place, since SPN validation is carried out by Active Directory, > outside the scope of the NetLogon protocol. I do not yet have any > information concerning whether or not any product bugs will be filed, > but I have alerted the appropriate folks here at Microsoft. That may > impact any forthcoming Windows Behavior notes. OK. I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we know what we must emulate. (Oh the joys of bug-for-bug compatibility) > [MS-ADTS]: > Active Directory Technical Specification > 3.1.1.5.3.1.1.4 servicePrincipalName > The object has class computer (or a subclass of computer). > In AD DS, the servicePrincipalName value satisfies the following > constraints: > o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4, > "Mutual Authentication"). > o The instance name matches one of the following: the full DNS name of > the machine, the sAMAccountName of the machine (without the terminating "$"), > one of the msDS-AdditionalDnsHostName, or one of the > msDS-AdditionalSamAccountName (without the terminating "$"). > > The guidance I provided earlier addresses these constraints; I regret > omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName. > > > Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for > > the account under the established secure channel, the following checks > > would be prudent: > > > > Reference: > > [MS-ADA3]: Active Directory Schema Attributes N-Z > > 2.252 Attribute servicePrincipalName > > > > 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) > > account sAMAccountName attribute (minus the trailing '$' character) for the > > account under the established secure channel. > > > > Reference: > > [MS-ADA3]: Active Directory Schema Attributes N-Z > > 2.221 Attribute sAMAccountName > > > > 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) > > account dNSHostName attribute for the account under the established secure > > channel. > > > > Reference: > > [MS-ADA1]: Active Directory Schema Attributes A-L > > 2.185 Attribute dNSHostName > > > > 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix > > (e.g., the domain DNS name). > > > > Reference: > > [MS-ADA2]: Active Directory Schema Attributes M > > 2.181 Attribute msDS-AllowedDNSSuffixes Thanks for the detail. I look forward to being able to use it some day :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
