RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
Yes, exactly as joe wrote, this was a terminology thing. In my language, the base schema includes all the classes and attributes that ship with the OS, and in ~Eric's language, the base schema includes only those that are specifically marked as Category 1 (to have several protections). And well, he represents the guys who own Windows and AD, so I guess they get to define the terminology... Both me and ~Eric agree that you cannot set a Category 1 attribute as confidential, but you can set Category 2 attribute as confidential. Yours, Sakari PS. Then it's another story why an attribute such as the cost of a site link is not marked to be Category 1 (the base schema) and therefore doesn't have the protection of base schema attributes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, July 14, 2005 6:59 AM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) I think it is a terminology thing. I would guess that Sakari is considering anything shipped in the base product is considered base schema. Of course your definition should match perfectly because the underlying code should be that it tests that flag and if it matches it won't allow the update. Since that is the verification mechanism, it would be an extremely odd case where it wasn't correct and would indicate a very very odd error that is nigh impossible. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, July 12, 2005 8:30 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) For clarity, this is the flag I'm making reference to: 1 systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT ); If that is set on a schema element, my contention is that on an SP1 DC it should not allow you to set the confidential bit. Show me a counterexample please. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, July 12, 2005 5:24 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Looking at your example msds-externalkey, I don't see the base flags bit set. Therefore, it would not be blocked. Looking at the code, right now, I stand by the earlier statement: we block base schema elements. Base schema elements are defined as the elements with the base schema flag set. All of them should be blocked. Please show me an example of a base schema element with the base schema flag set where I'm wrong. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Tuesday, July 12, 2005 4:39 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) Hi Brett and ~Eric, Thanks for your comments on my confidential attribute post. Now I solved, how to set the confidentiality in a way where unnecessary permissions are not granted. Brett wrote: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b) Thanks for catching my silly mistake. Yes, I meant 0x10, which is 16 in decimal. Fortunately this part was not about setting bits, but just checking which base schema attributes have protection. Brett wrote (and ~Eric agreed): B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. No there isn't. I went through the 49 extended rights that exist in SP1, and none of them seems to be for controlling confidentiality. This is actually obvious, because each of them is linked to only certain object classes, but the confidential attribute mechanism must apply to all current and future object classes. Therefore, a specific extended right cannot be used (unless Microsoft defined a fake rightsGuid for this, without a corresponding controlAccessRight object in the Configuration partition). However, I now found out that the trick is to define a certain attribute or property set with the control access permission. If you do this, the trustee won't get normal extended
RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
I think it is a terminology thing. I would guess that Sakari is considering anything shipped in the base product is considered base schema. Of course your definition should match perfectly because the underlying code should be that it tests that flag and if it matches it won't allow the update. Since that is the verification mechanism, it would be an extremely odd case where it wasn't correct and would indicate a very very odd error that is nigh impossible. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, July 12, 2005 8:30 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) For clarity, this is the flag I'm making reference to: 1 systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT ); If that is set on a schema element, my contention is that on an SP1 DC it should not allow you to set the confidential bit. Show me a counterexample please. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, July 12, 2005 5:24 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Looking at your example msds-externalkey, I don't see the base flags bit set. Therefore, it would not be blocked. Looking at the code, right now, I stand by the earlier statement: we block base schema elements. Base schema elements are defined as the elements with the base schema flag set. All of them should be blocked. Please show me an example of a base schema element with the base schema flag set where I'm wrong. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Tuesday, July 12, 2005 4:39 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) Hi Brett and ~Eric, Thanks for your comments on my confidential attribute post. Now I solved, how to set the confidentiality in a way where unnecessary permissions are not granted. Brett wrote: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b) Thanks for catching my silly mistake. Yes, I meant 0x10, which is 16 in decimal. Fortunately this part was not about setting bits, but just checking which base schema attributes have protection. Brett wrote (and ~Eric agreed): B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. No there isn't. I went through the 49 extended rights that exist in SP1, and none of them seems to be for controlling confidentiality. This is actually obvious, because each of them is linked to only certain object classes, but the confidential attribute mechanism must apply to all current and future object classes. Therefore, a specific extended right cannot be used (unless Microsoft defined a fake rightsGuid for this, without a corresponding controlAccessRight object in the Configuration partition). However, I now found out that the trick is to define a certain attribute or property set with the control access permission. If you do this, the trustee won't get normal extended rights, such as Reset Password. This trick has been illegal so far, and therefore if you try it with DSACLS, it will give you an error that you can specify an attribute or property set only with WP(Write Property) and RP(Read Property) permissions, not with CA(Control Access). So, the following is the correct syntax, but the current DSACLS (nor the R2 ADAM version) doesn't yet support it: dsacls ou=demo,dc=sanao,dc=com /G jim:ca;msDS-ExternalKey; ~Eric wrote: The LDP required for this is the LDP in R2's ADAM, not in the currently shipping one. Sorry. Yes, exactly. Just get R2 beta, locate ADAM in it, extract LDP.EXE from there, and use that tool's Security Descriptor feature to add a following ACE (preferably to an OU, and with the inherit flag on): - specify Control access as the permission - specify the desired attribute or property set as the Object type ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema
RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
Hi Brett and ~Eric, Thanks for your comments on my confidential attribute post. Now I solved, how to set the confidentiality in a way where unnecessary permissions are not granted. Brett wrote: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b) Thanks for catching my silly mistake. Yes, I meant 0x10, which is 16 in decimal. Fortunately this part was not about setting bits, but just checking which base schema attributes have protection. Brett wrote (and ~Eric agreed): B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. No there isn't. I went through the 49 extended rights that exist in SP1, and none of them seems to be for controlling confidentiality. This is actually obvious, because each of them is linked to only certain object classes, but the confidential attribute mechanism must apply to all current and future object classes. Therefore, a specific extended right cannot be used (unless Microsoft defined a fake rightsGuid for this, without a corresponding controlAccessRight object in the Configuration partition). However, I now found out that the trick is to define a certain attribute or property set with the control access permission. If you do this, the trustee won't get normal extended rights, such as Reset Password. This trick has been illegal so far, and therefore if you try it with DSACLS, it will give you an error that you can specify an attribute or property set only with WP(Write Property) and RP(Read Property) permissions, not with CA(Control Access). So, the following is the correct syntax, but the current DSACLS (nor the R2 ADAM version) doesn't yet support it: dsacls ou=demo,dc=sanao,dc=com /G jim:ca;msDS-ExternalKey; ~Eric wrote: The LDP required for this is the LDP in R2's ADAM, not in the currently shipping one. Sorry. Yes, exactly. Just get R2 beta, locate ADAM in it, extract LDP.EXE from there, and use that tool's Security Descriptor feature to add a following ACE (preferably to an OU, and with the inherit flag on): - specify Control access as the permission - specify the desired attribute or property set as the Object type ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Yours, Sakari List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Looking at your example msds-externalkey, I don't see the base flags bit set. Therefore, it would not be blocked. Looking at the code, right now, I stand by the earlier statement: we block base schema elements. Base schema elements are defined as the elements with the base schema flag set. All of them should be blocked. Please show me an example of a base schema element with the base schema flag set where I'm wrong. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Tuesday, July 12, 2005 4:39 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) Hi Brett and ~Eric, Thanks for your comments on my confidential attribute post. Now I solved, how to set the confidentiality in a way where unnecessary permissions are not granted. Brett wrote: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b) Thanks for catching my silly mistake. Yes, I meant 0x10, which is 16 in decimal. Fortunately this part was not about setting bits, but just checking which base schema attributes have protection. Brett wrote (and ~Eric agreed): B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. No there isn't. I went through the 49 extended rights that exist in SP1, and none of them seems to be for controlling confidentiality. This is actually obvious, because each of them is linked to only certain object classes, but the confidential attribute mechanism must apply to all current and future object classes. Therefore, a specific extended right cannot be used (unless Microsoft defined a fake rightsGuid for this, without a corresponding controlAccessRight object in the Configuration partition). However, I now found out that the trick is to define a certain attribute or property set with the control access permission. If you do this, the trustee won't get normal extended rights, such as Reset Password. This trick has been illegal so far, and therefore if you try it with DSACLS, it will give you an error that you can specify an attribute or property set only with WP(Write Property) and RP(Read Property) permissions, not with CA(Control Access). So, the following is the correct syntax, but the current DSACLS (nor the R2 ADAM version) doesn't yet support it: dsacls ou=demo,dc=sanao,dc=com /G jim:ca;msDS-ExternalKey; ~Eric wrote: The LDP required for this is the LDP in R2's ADAM, not in the currently shipping one. Sorry. Yes, exactly. Just get R2 beta, locate ADAM in it, extract LDP.EXE from there, and use that tool's Security Descriptor feature to add a following ACE (preferably to an OU, and with the inherit flag on): - specify Control access as the permission - specify the desired attribute or property set as the Object type ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Yours, Sakari List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
For clarity, this is the flag I'm making reference to: 1 systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT ); If that is set on a schema element, my contention is that on an SP1 DC it should not allow you to set the confidential bit. Show me a counterexample please. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, July 12, 2005 5:24 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Looking at your example msds-externalkey, I don't see the base flags bit set. Therefore, it would not be blocked. Looking at the code, right now, I stand by the earlier statement: we block base schema elements. Base schema elements are defined as the elements with the base schema flag set. All of them should be blocked. Please show me an example of a base schema element with the base schema flag set where I'm wrong. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Tuesday, July 12, 2005 4:39 PM To: ActiveDir@mail.activedir.org Subject: RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) Hi Brett and ~Eric, Thanks for your comments on my confidential attribute post. Now I solved, how to set the confidentiality in a way where unnecessary permissions are not granted. Brett wrote: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b) Thanks for catching my silly mistake. Yes, I meant 0x10, which is 16 in decimal. Fortunately this part was not about setting bits, but just checking which base schema attributes have protection. Brett wrote (and ~Eric agreed): B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. No there isn't. I went through the 49 extended rights that exist in SP1, and none of them seems to be for controlling confidentiality. This is actually obvious, because each of them is linked to only certain object classes, but the confidential attribute mechanism must apply to all current and future object classes. Therefore, a specific extended right cannot be used (unless Microsoft defined a fake rightsGuid for this, without a corresponding controlAccessRight object in the Configuration partition). However, I now found out that the trick is to define a certain attribute or property set with the control access permission. If you do this, the trustee won't get normal extended rights, such as Reset Password. This trick has been illegal so far, and therefore if you try it with DSACLS, it will give you an error that you can specify an attribute or property set only with WP(Write Property) and RP(Read Property) permissions, not with CA(Control Access). So, the following is the correct syntax, but the current DSACLS (nor the R2 ADAM version) doesn't yet support it: dsacls ou=demo,dc=sanao,dc=com /G jim:ca;msDS-ExternalKey; ~Eric wrote: The LDP required for this is the LDP in R2's ADAM, not in the currently shipping one. Sorry. Yes, exactly. Just get R2 beta, locate ADAM in it, extract LDP.EXE from there, and use that tool's Security Descriptor feature to add a following ACE (preferably to an OU, and with the inherit flag on): - specify Control access as the permission - specify the desired attribute or property set as the Object type ~Eric wrote: We actually block all base schema elements if I remember correctly. No you don't. Of the 1070 base schema attributes, you only block the 1007 ones that are marked as category 1. The remaining 63 attributes, such as msDS-ExternalKey, are not marked and therefore don't have this or any other protection for base schema attributes. Yours, Sakari List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
First off I don't really know security, so I'm like 43% confident in the accuracy of what I'm about to say ... Two things: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b), you either meant 0x10 (16 decimal) or 0x8 (8 decimal) probably. Really you should understand which bits you want to set, be careful with that. B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. Finally, I'd say any All Extended Rights should not be granted to anyone. Other stuff, like the right to replicate changes in or out, go in that bucket, it would be dangerous. So I'm not sure what the problem is ... is the problem that the tools (ACL editor and DSACLS) don't provide a way to explicitly and easily grant the desired extended right? That wouldn't be the first time such a thing got dropped. :P BTW, this might work, download ADAM, and install tools, and use the ldp.exe from the %windir%\ADAM directory. This ldp.exe has an ACL Editor in it that is vastly superior more powerful, providing very explicit control over almost everything about the ACL. Cheers, -BrettSh [msft] Building 7 Garage Door Operator Posting AS IS ... On Mon, 11 Jul 2005, Sakari Kouti wrote: About confidential attributes in SP1: When you set an attribute to be confidential, mere read permission is no longer enough for you to see the attribute value. HOW TO ENABLE - Select the attribute to be set as confidential. Category 1 attributes are not possible to select, which rules most of the base schema attributes out but not all... Cat1 is marked in the corresponding attributeSchema object in its systemFlags attribute, as bit 0xF (or 16 in decimal). - Locate the corresponding attributeSchema object in the schema, and set bit 0x80 (or 128 in decimal) in its searchFlags attribute. HOW TO DELEGATE - Grant All Extended Rights for anyone, who needs to see the confidential attribute and grant this on the object, where the attribute is (or you could also use inheritance, of course). For example, grant All Extended Rights on the Sales OU, where are the user Jill and contact Carl. - SP1 ACL Editor hides All Extended Rights on object classes that don't have any extended rights associated, such as contact. In that case you would use DSACLS, such as the command dsacls cn=jill,ou=demo,dc=sanao,dc=com /G jim:ca PROS - If you delegate Read All Properties to someone, you can exclude some attributes from this All by marking them as confidential. This also applies when people have Read All Properties through the Pre-Windows 2000 compatible access group. CONS - As you need to grant All Extended Rights, the trustee who got the permissions, gets not just permission to see a confidential attribute, but she also gets all current and future extended rights on the target object. For example, if you want Jim to see the users' social security numbers, he will also get permission to reset their passwords. And if one year later a directory-enabled application adds its own extended right to your AD, Jim will have that new permission right away on the affected users. - Account Operators have Full Control over user objects, so they also have All Extended Rights, so they are able to read users's confidential attributes. If this feature were implemented as a new access mask bit, it would have removed the first described drawback. Yours, Sakari === From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, May 09, 2005 4:31 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL.. Excellent thanks ~Eric... This looks to be a good document. However, anyone else think this info on confidential attributes is a bit weak in the documentation Improved security to protect confidential attributes To prevent Read access to confidential attributes, such as a Social Security number, while allowing Read access to other object attributes, you can designate specific attributes as confidential by setting a search flag on the respective attributeSchema object. By default, only domain administrators have Read access to confidential attributes, but this access can be delegated. For more information about access to attributes, see How Security Descriptors and Access Control Lists Work on the Microsoft Web site http://go.microsoft.com/fwlink/?LinkId=45972 at http://go.microsoft.com/fwlink/?LinkId=45972. The link takes you to a document from March 28, 2003 which I highly doubt has more info about confidential attributes. This is something that actually requires you to make changes to use, not like saying hey we also keep SID Histories in the tombstone objects now which doesn't take any action on the part of the admins
RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)
Sadly, a misstep on the part of our friendly garage door operator. use the ldp.exe from the %windir%\ADAM directory The LDP required for this is the LDP in R2's ADAM, not in the currently shipping one. Sorry. We can send this to you if you need it now, or just fetch it out of the R2 beta bits.[1] I'll go ahead and pass this along to garage door operator management, perhaps move him to a garage door painter role. This way he has the time required to really focus without the distractions of being a full garage door operator. - Select the attribute to be set as confidential. Category 1 attributes are not possible to select, which rules most of the base schema attributes out but not all... Cat1 is marked in the corresponding attributeSchema object in its systemFlags attribute, as bit 0xF (or 16 in decimal). We actually block all base schema elements if I remember correctly. B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. I agree with Brett. Please see CONTROL_ACCESS. ~Eric [1] - There goes my mail quota for the week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, July 10, 2005 4:56 PM To: ActiveDir@mail.activedir.org Subject: Re: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL..) First off I don't really know security, so I'm like 43% confident in the accuracy of what I'm about to say ... Two things: A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b), you either meant 0x10 (16 decimal) or 0x8 (8 decimal) probably. Really you should understand which bits you want to set, be careful with that. B) Why can't you grant the explicit extended right for reading the confidential attribute? I assume there is one, there has to be. Finally, I'd say any All Extended Rights should not be granted to anyone. Other stuff, like the right to replicate changes in or out, go in that bucket, it would be dangerous. So I'm not sure what the problem is ... is the problem that the tools (ACL editor and DSACLS) don't provide a way to explicitly and easily grant the desired extended right? That wouldn't be the first time such a thing got dropped. :P BTW, this might work, download ADAM, and install tools, and use the ldp.exe from the %windir%\ADAM directory. This ldp.exe has an ACL Editor in it that is vastly superior more powerful, providing very explicit control over almost everything about the ACL. Cheers, -BrettSh [msft] Building 7 Garage Door Operator Posting AS IS ... On Mon, 11 Jul 2005, Sakari Kouti wrote: About confidential attributes in SP1: When you set an attribute to be confidential, mere read permission is no longer enough for you to see the attribute value. HOW TO ENABLE - Select the attribute to be set as confidential. Category 1 attributes are not possible to select, which rules most of the base schema attributes out but not all... Cat1 is marked in the corresponding attributeSchema object in its systemFlags attribute, as bit 0xF (or 16 in decimal). - Locate the corresponding attributeSchema object in the schema, and set bit 0x80 (or 128 in decimal) in its searchFlags attribute. HOW TO DELEGATE - Grant All Extended Rights for anyone, who needs to see the confidential attribute and grant this on the object, where the attribute is (or you could also use inheritance, of course). For example, grant All Extended Rights on the Sales OU, where are the user Jill and contact Carl. - SP1 ACL Editor hides All Extended Rights on object classes that don't have any extended rights associated, such as contact. In that case you would use DSACLS, such as the command dsacls cn=jill,ou=demo,dc=sanao,dc=com /G jim:ca PROS - If you delegate Read All Properties to someone, you can exclude some attributes from this All by marking them as confidential. This also applies when people have Read All Properties through the Pre-Windows 2000 compatible access group. CONS - As you need to grant All Extended Rights, the trustee who got the permissions, gets not just permission to see a confidential attribute, but she also gets all current and future extended rights on the target object. For example, if you want Jim to see the users' social security numbers, he will also get permission to reset their passwords. And if one year later a directory-enabled application adds its own extended right to your AD, Jim will have that new permission right away on the affected users. - Account Operators have Full Control over user objects, so they also have All Extended Rights, so they are able to read users's confidential attributes. If this feature were implemented as a new access mask bit, it would have removed the first described drawback. Yours, Sakari === From: [EMAIL PROTECTED]
