-----------------------------------------------------------
Attention: Non-Delivery Report
-----------------------------------------------------------
This report is generated by the email server at:
ivytech.edu
The message with subject:
"RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a
list of SP1 changes? I think it was this DL......)"
and attached to this report was not delivered to
the following recipients:
Address: [EMAIL PROTECTED]
Reason: 554 5.5.2 No valid recipients (554)
--------------
--- Begin Message ---
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 (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/
>
> 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/
--- End Message ---
