[cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
abartlet at samba.org
Thu Oct 1 04:51:38 MDT 2009
On Mon, 2009-09-28 at 13:22 +0000, Bill Wesse wrote:
> Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (as Hongwei noted). This applies to Windows 2003/2003 R2, and was fixed in Windows 2008 and beyond.
> This is currently a bug against Windows 2003, but no hotfix has yet been produced. I will be glad to alert you to when this occurs.
> Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM:
> We confirmed that Windows server 2008 and later systems addressed the problem by implementing validation of the DNSHostName and SPN in NetrLogonGetDomainInfo to enforce the same constraints as specified in section 220.127.116.11.18.104.22.168(dNSHostName) and 22.214.171.124.126.96.36.199(servicePrincipalName) in MS-ADTS.
I'm sorry, I must not have been clear in my point:
> Did we determine earlier that these updates occur regardless of the access control on the object (confirmed with AD Dev team, but I don't think it's in the docs).
I refer here to the access control that would normally be imposed by the
nTSecurityDescriptor and enforced over LDAP. It is my understanding
(discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the
actual workstation account), but I don't recall that being in the doc.
(This isn't a security hole, because you can only update your own
record, but it's important to note for those doing an ACL
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the cifs-protocol