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

Bill Wesse billwe at microsoft.com
Mon Aug 24 08:35:53 MDT 2009


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).

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.

[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

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:59 AM
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-10 at 17:42 +1000, Andrew Bartlett wrote:
> On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote:
> > Thank you for the information on how R2 handles this. I will dig into that starting later today.
> 
> Has there been any progress clarifying the actual windows behaviour in 
> the past 10 days?
> 
> We would like to move on with a solution that both matches the 
> documentation and the demonstrated behaviour soon.

I would really like to get this clarified for the next Samba4 alpha.
I'm not too happy with the client being able to set any value, but this appears to be the windows behaviour.  Will there be any clarification forthcoming?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


More information about the cifs-protocol mailing list