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

Bill Wesse billwe at microsoft.com
Tue Dec 15 07:47:20 MST 2009


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.

••••••••• ••• ••••••••••• •• •••••• •••••••••
••••••• ••••••• •••• ••• •••• ••••••• •••••• ••• •••••• •••••• •••• •••• ••••• •• •••• •• ••••• •• ••••••••• ••• •••••••• • •••••••• ••• •••••••• ••••••••••• •• ••• •••••• ••••••••• ••• ••• •••••• •••••• ••• ••••• •• ••••••• ••••••••• •••• •• •••••••••• •••••• •••••••••• ••• ••••••••••••••••••••••• ••• •••• •••••••••••••• •••• •• •••• •••• ••••••• ••••• ••••••• •••••• •••• •••••
••••• •• •••••••• •• •••••• •••• ••••••• ••• •••••• •••• •••• •• •••• •• •••••••• ••••••••••• •• •••• ••• ••• ••••••• ••••••••••• •• •••• •••••• ••••••• ••• •••• •••• •••••  ••• •••• •••• •• ••••• ••••••••••• ••••• •••• ••• •••• •••••••• •• • •••• •••••••• •••••••• ••••••• ••• •• •• •••• •• ••••••••• ••• •••• ••••• •• •••••• •••• ••• ••••••• ••••••••••• •• •••• •••••• •••••••• •• •••• •• •• •••• •• ••••• ••• •••• •••••••• •••••• ••••••••• •••• ••••• ••• •••• ••••••••• •••• ••••••• •••••• •••••••••• •••• •• •••• ••••••• •••• • •••••••••• •••• •••• •• ••••••• • •••• ••••••••••• ••• •••••• •••• •• ••• ••••• ••• ••• •••• •• •••••• ••••••

•••••• ••• ••• •••• ••••• ••• •••• •••••••••

•••• ••••••••
•••••
----- 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>

••••••••• ••• ••••••••••• •• •••••• •••••••••
••••••• ••••••• •••• ••• •••• ••••••• •••••• ••• •••••• •••••• •••• •••• ••••• •• •••• •• ••••• •• ••••••••• ••• •••••••• • •••••••• ••• •••••••• ••••••••••• •• ••• •••••• ••••••••• ••• ••• •••••• •••••• ••• ••••• •• ••••••• ••••••••• •••• •• •••••••••• •••••• •••••••••• ••• ••••••••••••••••••••••• ••• •••• •••••••••••••• •••• •• •••• •••• ••••••• ••••• ••••••• •••••• •••• •••••
••••• •• •••••••• •• •••••• •••• ••••••• ••• •••••• •••• •••• •• •••• •• •••••••• ••••••••••• •• •••• ••• ••• ••••••• ••••••••••• •• •••• •••••• ••••••• ••• •••• •••• •••••  ••• •••• •••• •• ••••• ••••••••••• ••••• •••• ••• •••• •••••••• •• • •••• •••••••• •••••••• ••••••• ••• •• •• •••• •• ••••••••• ••• •••• ••••• •• •••••• •••• ••• ••••••• ••••••••••• •• •••• •••••• •••••••• •• •••• •• •• •••• •• ••••• ••• •••• •••••••• •••••• ••••••••• •••• ••••• ••• •••• ••••••••• •••• ••••••• •••••• •••••••••• •••• •• •••• ••••••• •••• • •••••••••• •••• •••• •• ••••••• • •••• ••••••••••• ••• •••••• •••• •• ••• ••••• ••• ••• •••• •• •••••• ••••••

•••••• ••• ••• •••• ••••• ••• •••• •••••••••

•••• ••••••••
•••••
----- 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/20091215/49f77767/attachment-0001.html>


More information about the cifs-protocol mailing list