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 (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/
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/
