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:[email protected]]
Sent: Monday, August 24, 2009 7:59 AM
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-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.
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
