[cifs-protocol] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)

Sun Nov 22 18:23:22 MST 2009

On Fri, 2009-11-20 at 18:02 +0000, Bill Wesse wrote:
> Good morning Andrew - I am resending this email from November 4.

I did get the message, but was surprised by the contents and I've been
unable to find the time to verify it.  

> -----Original Message-----
> From: Bill Wesse 
> Sent: Wednesday, November 04, 2009 12:22 PM
> To: 'Andrew Bartlett'
> Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'; 'Matthias Dieter Wallnöfer'
> Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
> 
> Good morning Andrew - I am resending this email from October 29.
> 
> Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved.
> 
> The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context.
> 
> According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue.
> 
> As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor.
> 
> In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object.
> 
> 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: Bill Wesse 
> Sent: Thursday, October 29, 2009 9:36 AM
> To: 'Andrew Bartlett'
> Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'; 'Matthias Dieter Wallnöfer'
> Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
> 
> Good morning Andrew - I am resending this email from October 20.
> 
> Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved.
> 
> The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context.
> 
> According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue.
> 
> As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor.
> 
> In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object.
> 
> 
> 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: Bill Wesse 
> Sent: Tuesday, October 20, 2009 10:57 AM
> To: 'Andrew Bartlett'
> Cc: pfif at tridgell.net; cifs-protocol at samba.org; Matthias Dieter Wallnöfer
> Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
> 
> Good morning Andrew - here is the response from our document team.
> 
> Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved.
> 
> The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context.
> 
> According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue.
> 
> As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor.
> 
> In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object.
> 
> 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: Thursday, October 01, 2009 6:52 AM
> To: Bill Wesse
> Cc: pfif at tridgell.net; cifs-protocol at samba.org; Matthias Dieter Wallnöfer
> Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
> 
> 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 3.1.1.5.3.1.1.2(dNSHostName) and 3.1.1.5.3.1.1.4(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 implementation).
> 
> Andrew Bartlett
> 
-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091123/0c382b6e/attachment.pgp>