|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 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. </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@...> To: Nadezhda Ivanova < nadezhda.ivanova@...> 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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
 Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... < cifs-protocol-bounces@...> To: hongweis@... < hongweis@...>, billwe@... < billwe@...>, dochelp@... < dochelp@...>, cifs-protocol@... < cifs-protocol@...>, Nadezhda Ivanova < nadezhda.ivanova@...> 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 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. </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@...> To: Nadezhda Ivanova < nadezhda.ivanova@...> 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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Monday, October 26, 2009 10:35 AM
To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help;
cifs-protocol@...
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@... <cifs-protocol-bounces@...>
To: hongweis@... <hongweis@...>, billwe@...
<billwe@...>, dochelp@...
<dochelp@...>, cifs-protocol@...
<cifs-protocol@...>, Nadezhda Ivanova <nadezhda.ivanova@...>
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
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. </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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...
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@...]
Sent: Monday, October 26, 2009 10:35 AM
To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help;
cifs-protocol@...
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@... <cifs-protocol-bounces@...>
To: hongweis@... <hongweis@...>, billwe@...
<billwe@...>, dochelp@...
<dochelp@...>, cifs-protocol@... <cifs-protocol@...>,
Nadezhda Ivanova <nadezhda.ivanova@...>
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
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. </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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...'
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@...
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@...]
Sent: Monday, October 26, 2009 10:35 AM
To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help;
cifs-protocol@...
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@... <cifs-protocol-bounces@...>
To: hongweis@... <hongweis@...>, billwe@...
<billwe@...>, dochelp@...
<dochelp@...>, cifs-protocol@...
<cifs-protocol@...>, Nadezhda Ivanova
<nadezhda.ivanova@...>
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
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. </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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...> To: Nadezhda Ivanova < nadezhda.ivanova@...> Cc: cifs-protocol@... < cifs-protocol@...> 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@...'
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@...
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@...]
Sent: Monday, October 26, 2009 10:35 AM
To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help;
cifs-protocol@...
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@... <cifs-protocol-bounces@...>
To: hongweis@... <hongweis@...>, billwe@...
<billwe@...>, dochelp@...
<dochelp@...>, cifs-protocol@...
<cifs-protocol@...>, Nadezhda Ivanova
<nadezhda.ivanova@...>
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
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. </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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Friday, November 06, 2009 4:13 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
Cc: cifs-protocol@... <cifs-protocol@...>
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@...'
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@...
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@...]
Sent: Monday, October 26, 2009 10:35 AM
To: Hongwei Sun; Bill Wesse; Interoperability Documentation Help;
cifs-protocol@...
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@... <cifs-protocol-bounces@...>
To: hongweis@... <hongweis@...>, billwe@...
<billwe@...>, dochelp@...
<dochelp@...>, cifs-protocol@...
<cifs-protocol@...>, Nadezhda Ivanova <nadezhda.ivanova@...>
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
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. </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@...>
To: Nadezhda Ivanova <nadezhda.ivanova@...>
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@...
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@...]
Sent: Monday, September 28, 2009 8:28 AM
To: Bill Wesse
Cc: cifs-protocol@...
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@...]
Sent: Friday, September 25, 2009 9:04 PM
To: Nadezhda Ivanova
Cc: cifs-protocol@...
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@...'
Cc: 'cifs-protocol@...'
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@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
