[cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Fri Mar 12 05:16:32 MST 2010

Hi Bill,
I'm back to dealing with access checks. I noticed that some updates have been done to ADTS that clarify Access Control Rights and Validated Writes, so at present there is nothing I need in this particular area. I might have more specific questions later, about particular rights, but if you haven't closed this case I think you can do so. My apologies for the long wait on this one.

Regards,
Nadya

----- Original Message -----
From: Bill Wesse <billwe at microsoft.com>
To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
Sent: Wednesday, December 16, 2009 4:50:29 PM (GMT+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

No problem - I understand busy! Unless you indicate otherwise, I will archive this case, pending any future follow up from you…

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

From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com] 
Sent: Wednesday, December 16, 2009 6:09 AM
 To: Bill Wesse
 Cc: cifs-protocol at samba.org
 Subject: Re: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Yeah, sorry about that. I just can't seem to get to paying serious attention to the FSMO roles yet, still involved in the ACL work...
----- Original Message -----
From: Bill Wesse <billwe at microsoft.com>
To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
Sent: Tuesday, December 15, 2009 4:42:39 PM GMT+0200 Europe;Athens
Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Good morning Nadya! I have included your original questions and my responses below. Since I have not heard from you in quite a while, I will archive the case on Thursday; we can, of course, reopen it if you require that.

==============================================================================
Why are the domain admins also provided full permissions if not needed for replication?  Is this for the administrative purposes only?  
7.1.1.1.2 Config NC Root
7.1.1.1.3 Schema NC Root
7.1.1.1.4 Domain NC Root
In order for D2 to replicate the NC, D2 must be granted the following rights on the NC root…

Response:

I confirm the Domain Administrators group is granted full permissions on the various naming contexts for the purposes of administration. For example, to restore deleted objects, as well as granting replication permissions for other accounts.

==============================================================================
Question:

While I was in Redmond, we discussed whether, if a new access control right is added by an application such as Exchange, it is up to the Directory Server to perform if the requester has that right or to the client (Outlook or Exchange), and we determined that it is up to the client. Can you confirm that?

Response:

The actual updates for Validated Rights (by the DSA) is done as SYSTEM; however, all access checks are performed using 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.

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.

==============================================================================
Question:

Is there somewhere in the docs an example of what the DS does and does not do with a user defined access right? It would be much easier for me to understand it that way. Or, perhaps, a more detailed explanation on the function of validAccesses, because "This attribute specifies the type of access that is permitted with an extended right." does not give me a very good idea.

Response:

The following link contains both Visual Basic and C++ code that should be helpful:

Example Code for Creating a Control Access Right
http://msdn.microsoft.com/en-us/library/ms676408(VS.85).aspx

References:

[MS-ADSC]: Active Directory Schema Classes
2.26 Class controlAccessRight
http://msdn.microsoft.com/en-us/library/cc221827(PROT.13).aspx

[MS-ADA3]: Active Directory Schema Attributes N-Z
2.359 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc220991(PROT.13).aspx

[MS-ADLS]: Active Directory Lightweight Directory Services Schema
2.383 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc221445(PROT.13).aspx

Valid-Accesses Attribute
http://msdn.microsoft.com/en-us/library/ms680891(VS.85).aspx
The type of access that is permitted with an extended right.

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

From: Bill Wesse 
Sent: Friday, November 06, 2009 8:20 AM
 To: 'Nadezhda Ivanova'
 Cc: cifs-protocol at samba.org
 Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Hi – I will stand by!

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

From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com] 
Sent: Friday, November 06, 2009 4:13 AM
 To: Bill Wesse
 Cc: cifs-protocol at samba.org
 Subject: Re: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Hi Bill,
I will need some time to take a look at the links you have sent, as I am in the middle of something else. I will let you know as soon as I can if they answer my questions.

Best Regards,
Nadya
----- Original Message -----
From: Bill Wesse <billwe at microsoft.com>
To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
Sent: Wednesday, November 4, 2009 7:19:27 PM GMT+0200 Europe;Athens
Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Good day Nadya – I am resending my email of October 26.

==============================================================================
Question:

While I was in Redmond, we discussed whether, if a new access control right is added by an application such as Exchange, it is up to the Directory Server to perform if the requester has that right or to the client (Outlook or Exchange), and we determined that it is up to the client. Can you confirm that?

Response:

The actual updates for Validated Rights (by the DSA) is done as SYSTEM; however, all access checks are performed using 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.

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.

==============================================================================
Question:

Is there somewhere in the docs an example of what the DS does and does not do with a user defined access right? It would be much easier for me to understand it that way. Or, perhaps, a more detailed explanation on the function of validAccesses, because "This attribute specifies the type of access that is permitted with an extended right." does not give me a very good idea.

Response:

The following link contains both Visual Basic and C++ code that should be helpful:

Example Code for Creating a Control Access Right
http://msdn.microsoft.com/en-us/library/ms676408(VS.85).aspx

References:

[MS-ADSC]: Active Directory Schema Classes
2.26 Class controlAccessRight
http://msdn.microsoft.com/en-us/library/cc221827(PROT.13).aspx

[MS-ADA3]: Active Directory Schema Attributes N-Z
2.359 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc220991(PROT.13).aspx

[MS-ADLS]: Active Directory Lightweight Directory Services Schema
2.383 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc221445(PROT.13).aspx

Valid-Accesses Attribute
http://msdn.microsoft.com/en-us/library/ms680891(VS.85).aspx
The type of access that is permitted with an extended right.

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

From: Bill Wesse 
Sent: Monday, October 26, 2009 2:05 PM
 To: 'Nadezhda Ivanova'; 'cifs-protocol at samba.org'
 Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Hello again Nadya – here is what I have found – please let me know if this is what you need!

==============================================================================
Question:

While I was in Redmond, we discussed whether, if a new access control right is added by an application such as Exchange, it is up to the Directory Server to perform if the requester has that right or to the client (Outlook or Exchange), and we determined that it is up to the client. Can you confirm that?

Response:

The actual updates for Validated Rights (by the DSA) is done as SYSTEM; however, all access checks are performed using 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.

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.

==============================================================================
Question:

Is there somewhere in the docs an example of what the DS does and does not do with a user defined access right? It would be much easier for me to understand it that way. Or, perhaps, a more detailed explanation on the function of validAccesses, because "This attribute specifies the type of access that is permitted with an extended right." does not give me a very good idea.

Response:

The following link contains both Visual Basic and C++ code that should be helpful:

Example Code for Creating a Control Access Right
http://msdn.microsoft.com/en-us/library/ms676408(VS.85).aspx

References:

[MS-ADSC]: Active Directory Schema Classes
2.26 Class controlAccessRight
http://msdn.microsoft.com/en-us/library/cc221827(PROT.13).aspx

[MS-ADA3]: Active Directory Schema Attributes N-Z
2.359 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc220991(PROT.13).aspx

[MS-ADLS]: Active Directory Lightweight Directory Services Schema
2.383 Attribute validAccesses
http://msdn.microsoft.com/en-us/library/cc221445(PROT.13).aspx

Valid-Accesses Attribute
http://msdn.microsoft.com/en-us/library/ms680891(VS.85).aspx
The type of access that is permitted with an extended right.

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

From: Bill Wesse 
Sent: Monday, October 26, 2009 10:47 AM
 To: 'Nadezhda Ivanova'; cifs-protocol at samba.org
 Subject: RE: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Thanks for the update Nadya; I will get to work on this a bit later today.

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

From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com] 
Sent: Monday, October 26, 2009 10:35 AM
 To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help; cifs-protocol at samba.org
 Subject: Re: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Resending this, as some people received the second half in Greek for some reason...

Hi Bill,
Thank you for all the fine work on compiling the links! I read the info, and I have some questions.
Regarding control access rights, here is what you have written in your blog, and my questions:
For extended rights, which are special operations not covered by the standard set of access rights. For example, the user class can be granted a "Send As" right that can be used by Exchange, Outlook, or any other mail application, to determine whether a particular user can have another user send mail on their behalf. Extended rights are created on controlAccessRughts objects by setting the validAccesses attribute to equal the ADS_RIGHT_DS_CONTROL_ACCESS (256) access right.  

<Nadya>
While I was in Redmond, we discussed whether, if a new access control right is added by an application such as Exchange, it is up to the Directory Server to perform if the requester has that right or to the client (Outlook or Exchange), and we determined that it is up to the client. Can you confirm that? Is there somewhere in the docs an example of what the DS does and does not do with a user defined access right? It would be much easier for me to understand it that way. Or, perhaps, a more detailed explanation on the function of validAccesses, because "This attribute specifies the type of access that is permitted with an extended right." does not give me a very good idea.

Regarding the permissions on naming contexts:
 Section 7.1.1.1 that you have quoted, states the access rights that "D1" needs to have in order to replicate the context. I examined the security descriptors of the naming contexts, and the rights quoted are given to several trustees, such as ENTERPRISE DOMAIN CONTROLERS and Builtin/Administrators. Why does Administrators need to have such rights, also, doesn't SYSTEM need them? 
While in Redmond, we agreed with Hongwei and Darryl that what we need is actually information on what are the default permissions on each naming context for each FSMO role,  and what each of these permissions mean. What you have provided is a very valuable addition indeed! But to be able to implement the FSMO roles in Samba, with the correct permissions on each naming context, we need to be able to grasp the full picture. Darryl mentioned that there are MCPP documents that explain states scenarios, such as what happens when a particular FSMO role is assumed - what permissions are added, etc. Do you think you can help me locate these?

Thanks for all your help, and your patience!

Best Regards,
 Nadya  
----- Original Message -----
From: cifs-protocol-bounces at cifs.org <cifs-protocol-bounces at cifs.org>
To: hongweis at microsoft.com <hongweis at microsoft.com>, billwe at microsoft.com <billwe at microsoft.com>, dochelp at microsoft.com <dochelp at microsoft.com>, cifs-protocol at samba.org <cifs-protocol at samba.org>, Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
Sent: Monday, October 26, 2009 4:14:38 PM GMT+0200 Europe;Athens
Subject: Re: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Hi Bill,
Thank you for all the fine work on compiling the links! I read the info, and I have some questions.
Regarding control access rights, here is what you have written in your blog, and my questions:
For extended rights, which are special operations not covered by the standard set of access rights. For example, the user class can be granted a "Send As" right that can be used by Exchange, Outlook, or any other mail application, to determine whether a particular user can have another user send mail on their behalf. Extended rights are created on controlAccessRight <http://msdn.microsoft.com/en-us/library/cc221827.aspx> objects by setting the validAccesses <http://msdn.microsoft.com/en-us/library/cc220991.aspx> attribute to equal the ADS_RIGHT_DS_CONTROL_ACCESS (256) access right.   <Nadya> While I was in Redmond, we discussed whether, if a new access control right is added by an application such as Exchange, it is up to the Directory Server to perform if the requester has that right or to the client (Outlook or Exchange), and we determined that it is up to the client. Can you confirm that? Is there somewhere in the docs an example of what the DS does and does not do with a user defined access right? It would be much easier for me to understand it that way. Or, perhaps, a more detailed explanation on the function of validAccesses, because "This attribute specifies the type of access that is permitted with an extended right." does not give me a very good idea. </Nadya>

Regarding the permissions on naming contexts:
 Section 7.1.1.1 that you have quoted, states the access rights that "D1" needs to have in order to replicate the context. I examined the security descriptors of the naming contexts, and the rights quoted are given to several trustees, such as ENTERPRISE DOMAIN CONTROLERS and Builtin/Administrators. Why does Administrators need to have such rights, also, doesn't SYSTEM need them? 
While in Redmond, we agreed with Hongwei and Darryl that what we need is actually information on what are the default permissions on each naming context for each FSMO role,  and what each of these permissions mean. What you have provided is a very valuable addition indeed! But to be able to implement the FSMO roles in Samba, with the correct permissions on each naming context, we need to be able to grasp the full picture. Darryl mentioned that there are MCPP documents that explain states scenarios, such as what happens when a particular FSMO role is assumed - what permissions are added, etc. Do you think you can help me locate these?

Thanks for all your help, and your patience!

Best Regards,
 Nadya  
----- Original Message -----
From: Bill Wesse <billwe at microsoft.com>
To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
Sent: Monday, October 19, 2009 5:42:01 PM GMT+0200 Europe;Athens
Subject: RE: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Good morning – I have returned to work. Just checking in to see if your schedule permitted that review of the information.

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

From: Bill Wesse 
Sent: Tuesday, October 13, 2009 10:17 AM
 To: 'Nadezhda Ivanova'
 Subject: RE: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Good morning – I am sending this to advise you that I am out of the office for the next several days, due to illness. I will keep current on any incoming email from you. If needed, we can temporarily reassign the case to someone else on my team.

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

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

From: Bill Wesse 
Sent: Monday, September 28, 2009 8:51 AM
 To: 'Nadezhda Ivanova'
 Cc: cifs-protocol at samba.org
 Subject: RE: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

You’re welcome – I will stand by!

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

From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com] 
Sent: Monday, September 28, 2009 8:28 AM
 To: Bill Wesse
 Cc: cifs-protocol at samba.org
 Subject: RE: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Hi Bill,
Thanks, I will be able to review this information next week and will let you know if it is enough.

Regards,
Nadya

From: Bill Wesse [mailto:billwe at microsoft.com] 
Sent: Friday, September 25, 2009 9:04 PM
 To: Nadezhda Ivanova
 Cc: cifs-protocol at samba.org
 Subject: RE: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Good afternoon Nadya!

I have provided below a set of links for information that pertains to Active Directory permissions. There does not appear to be a specific guide for what the default permissions on a given Active Directory object, other than the Schema documents available at the following link. Please let me know if you have any specific questions concerning these that I have not already answered.

If you have no further questions, I will consider your question resolved.

Using the Windows Server Protocols documentation set to better understand the Active Directory Schema
http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx

For example, there are 232 defaultSecurityDescriptor (SDDL formatted) attributes in MS-AD_Schema_2K8_R2_Consolidated.txt (which is in the Schemas.zip attachment to the blog entry).

Understanding security descriptor defaulting rules for Active Directory objects
http://blogs.msdn.com/openspecification/archive/2009/08/28/understanding-security-descriptor-defaulting-rules-for-active-directory-objects.aspx

Active Directory Technical Specification Control Access Rights Concordance
http://blogs.msdn.com/openspecification/archive/2009/08/19/active-directory-technical-specification-control-access-rights-concordance.aspx

How to Use Dsacls.exe in Windows Server 2003 and Windows 2000
http://support.microsoft.com/default.aspx/kb/281146

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

From: Bill Wesse 
Sent: Tuesday, September 22, 2009 12:48 PM
 To: 'nadezhda.ivanova at postpath.com'
 Cc: 'cifs-protocol at samba.org'
 Subject: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions

Good day Nadya (please let me know if I am using your name correctly)!

I have created case SRX090922600157, in order to track our work concerning your questions (shown below). Hopefully, we have not missed anything you are enquiring after.

1. Why are the domain admins also provided full permissions if not needed for replication?
2. Is this for the administrative purposes only? 

7.1.1.1.2 Config NC Root
7.1.1.1.3 Schema NC Root
7.1.1.1.4 Domain NC Root
In order for D2 to replicate the NC, D2 must be granted the following rights on the NC root...

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100312/bd99378d/attachment-0001.html>