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: 'p...@tridgell.net'; 'cifs-proto...@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: 'p...@tridgell.net'; 'cifs-proto...@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: p...@tridgell.net; cifs-proto...@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:abart...@samba.org] > Sent: Thursday, October 01, 2009 6:52 AM > To: Bill Wesse > Cc: p...@tridgell.net; cifs-proto...@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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
