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 (0b1111) 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/
