[cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)

[Bill Wesse]

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:abartlet at samba.org] 
Sent: Monday, August 24, 2009 7:30 PM
To: Bill Wesse
Cc: cifs-protocol at samba.org; pfif at tridgell.net; 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.