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 bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@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-proto...@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.ivan...@postpath.com] Sent: Monday, September 28, 2009 8:28 AM To: Bill Wesse Cc: cifs-proto...@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
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 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. 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-boun...@cifs.org cifs-protocol-boun...@cifs.org To: hongw...@microsoft.com hongw...@microsoft.com, bil...@microsoft.com bil...@microsoft.com, doch...@microsoft.com doch...@microsoft.com, cifs-proto...@samba.org cifs-proto...@samba.org, Nadezhda Ivanova nadezhda.ivan...@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
Re: [cifs-protocol] 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.ivan...@postpath.com' Cc: 'cifs-proto...@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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
