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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
