Re: Export schema

From: Dmitri Gavrilov [MSFT] (dmitrig_at_online.microsoft.com)
Date: 12/17/04 

Date: Fri, 17 Dec 2004 10:43:02 -0700

Danny,

Forget defaultSDs, they are not the best solution. Put an inheritable ACE
somewhere at the top of hierarchy and let it propagate down. You can even do
this with the UI. It will be automatically stamped on all existing objects,
and on any newly created ones (unless they are protected from inheritance).

It does not make sense to set defaultSD on aux classes, they will never
apply.

If you need to make an attribute-specific ACE, you have to put schemaIDGUID
off the attribute into the objectType field in the ACE.

WRT protecting an attribute from being read by everyone, it is difficult. In
w2k3 sp1 we have a new attribute flag "CONFIDENTIAL", which will allow you
to protect attributes from reading by everyone (even in the presence of
default ACLs as they are today). 

-- 
Dmitri Gavrilov
SDE, Active Directory Core
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Danny Cooper" <danny.cooper@bbc.co.uk> wrote in message
news:pmh5s09hdbmapvmbk6etiod72991bc00um@4ax.com...
>
> I had been reading those links, plus many more, it just isn't clear
> enough for me to get a working solution.
>
> I get that the security on attributes is actually defined as a mask at
> the class level, and that you can specify either individual attributes
> or used a shared GUID for an attribute set.
>
> My problem is that in trying to interpret the tables, I cannot get a
> result that is useful.
>
> I am not trying to implement a security system via default security,
> just remove Authenticated Users from a specific set of new attributes,
> and grant SELF in its place.
>
> Things I think I've found:
>
> 1. security set on classes that are part of structural classes have
> their security overruled by the structural class. I thought it would
> "append" but it doesn't seem to
>
> 2. You can't "add to" a defaultSecurityDescriptor, you have to replace
> it with one that includes new settings
>
> 3. It is so far impossible to stop Authenticated Users getting put
> back in with Read All Properties - for no reason I can see
>
> 4. Setting the "P" flag in D:P(... does turn off security inheritance
> according to the schema MMC snap-in, but if a structural class that
> includes your new aux class has it on by default, then instantiated
> objects inherit too (overriding the aux class setting)
>
> 5. I still can't get a SDDL string to actually set security on a
> single attribute - it sets it for all attributes... such as you get
> Read All Properties even though you specify the GUID of the attribute
>
> 6. If you try and deny a read permission on an attribute because you
> allow it at the object level, you end up denying read on all
> attributes - this goes back to no.5 really
>
> 7. There's little point trying to adjust the default security at the
> User class level (the ultimate structure class for my new attributes)
> as this doesn't change any of the tens of thousands of existing
> instantiated User objects - they are happily continuing to inherit,
> but with the new attributes having the wrong security
>
>
> Anyway, I'll leave it as a problem for next year now. Coding it to set
> security on instantiated objects works fine - but then that is well
> documented and the user management interfaces are expecting it to
> happen and display it.
>
>
> Danny.
>
> On Wed, 15 Dec 2004 11:31:21 -0000, "Lee Flight" <lef@le.ac.uk-nospam>
> wrote:
>
> >Hi
> >
> >if you look at the 3 subheadings under
> >
>
>http://msdn.microsoft.com/library/en-us/secauthz/security/security_descript
or_definition_language.asp
> >
> >you will find that information and how to use it to build SDDL strings.
> >You can create SDDL strings that will control access at the attribute
> >or attribute set level, look at the ACE strings
> >
> >http://msdn.microsoft.com/library/en-us/secauthz/security/ace_strings.asp
> >
> >where object_guid in the ACE could be the schemaIDGuid of the attribute.
> >Such an SDDL string could be in the security descriptor of an
instantiated
> >object but as I tried to explain before it is on the object controlling
> >access
> >to the attribute it is not a security descriptor on the attribute
> >
> >The bulk of your object and attribute security configuration in AD comes
> >from that which you apply, often through inheritance, to instantiated
> >objects
> >as you can see if you use AD Users and Computers and drill down into the
> >security UI on an object it goes down to the individual property level
> >under the Advanced settings. Clearly all of this can also be set through
> >code.
> >
> >I think trying to do your security design on the backend schema is too
> >inflexible, the defaultSecurityDescriptors in the schema are meant to
cover
> >the case where you are instantiating an object without specifying a
security
> >descriptor or the security descriptor was not inheritable.
> >
> >HTH
> >Lee Flight
> >
> >"Danny Cooper" <danny.cooper@bbc.co.uk> wrote in message
> >news:b4uvr0lssrue41khsb7f3vnrqk2638t1si@4ax.com...
> >>
> >> Further to what does the P in D:P(... do, I have found a table in a
> >> document (non-Microsoft) that says:
> >>
> >> Possible DACL Flags Values
> >> ---------------------------------------------
> >>
> >> P - The ADS_SD_CONTROL_SE_DACL_PROTECTED is set in the flags field of
> >> the DACL
> >>
> >> AI - The ADS_SD_CONTROL_SE_AUTO_INHERIT_REQ flag is set for the DACL
> >>
> >> AR - The ADS_SD_CONTROL_DACL_AUTO_INHERITED flag is set for the DACL
> >>
> >>
> >> So that is how you control the security inheritence then.
> >>
> >>
> >>
> >> Danny.
> >>
> >>
> >> On Tue, 14 Dec 2004 15:25:38 +0000, Danny Cooper
> >> <danny.cooper@bbc.co.uk> wrote:
> >>
> >>>
> >>>Thanks for the further help.
> >>>
> >>>The link given does offer some valuable background (and this area of
> >>>schema extensions seems to be pretty much completely undocumented to
> >>>me), but examples are via programming (which hides much of what is
> >>>really going on). I'm trying to do this from an LDIF file.
> >>>
> >>>Following examples and the like, specifying an attributeSecurityGuid
> >>>with the attribute I want to set default security on, and then trying
> >>>to set the security from a defaultSecurity Descriptor line in the
> >>>class definition (which is referring to the attribute security GUID in
> >>>the SDDL string) gets me the class having something like the security
> >>>I'm trying to set, not the attribute. And then I can't figure out the
> >>>following:
> >>>
> >>>- how to get it to not change the security on the class, when the SDDL
> >>>string is referring to an attribute
> >>>
> >>>- how to turn off parent security inheritance (or is this what the P
> >>>in D:P(... does, which I've seen in Microsoft LDUF files but can't see
> >>>documented anywhere
> >>>
> >>>- how to use the directory permission settings listed to control a
> >>>single property, rather than all properties as they claim in documents
> >>>
> >>>- understand why nTSecurityDescriptor doesn't show me any of the
> >>>changes I make that I can see in the Schema MMC snap-in - even when
> >>>I'm adding new ACEs - but instantiating a new object does get the new
> >>>ACE applied
> >>>
> >>>Thanks for all your help but I think I'm going to have to give up on
> >>>this until it gets better documented.
> >>>
> >>>
> >>>Danny.
> >>>
> >>>
> >>>On Fri, 10 Dec 2004 20:07:04 -0000, "Lee Flight" <lef@le.ac.uk-nospam>
> >>>wrote:
> >>>
> >>>>Inline below....
> >>>>
> >>>>"Danny Cooper" <danny.cooper@bbc.co.uk> wrote in message
> >>>>news:00djr09u7bsuu9nleqq3alk728c4ee42d5@4ax.com...
> >>>>
> >>>>> What I want to do is have a different default security on an
attribute
> >>>>> of a class than the class itself. As far as I can tell the Schema
MMC
> >>>>> snap-in only allows setting default security on classes, not
> >>>>> attributes. If I use ADSI Edit then although I can see a Security
tab
> >>>>> on both classes and attributes, making changes here (for a class)
does
> >>>>> not get picked up by the Schema MMC snap-in. What is ADSI Edit
> >>>>> setting, and how can I set a new and different default security on
an
> >>>>> attribute?
> >>>>
> >>>>The security UI in ADSIedit is showing you the nTSecurityDescriptor
> >>>>on the attributeSchema and classSchema objects themselves, basically
> >>>>it's the security of the schema objects (mainly inherited from the
schema
> >>>>partition head and the defaultSecurityDescriptor of the
attributeSchema
> >>>>and classSchema object structural classes).
> >>>>
> >>>>> Is the security set from the class? I can't see how else you'd do it
> >>>>> without enforcing the new default security on the attribute no
matter
> >>>>> what classes it is in.
> >>>>
> >>>>As you say attributes can be used by many classes this provides a lot
of
> >>>>flexibility and saves redundancy. The security of the attributeSchema
> >>>>objects in the Schema partition is as above, the security of
attributes
> >>>>on
> >>>>instantiation is from the AD security model using object based ACEs.
> >>>>The "security at the attribute level" that you get with AD is through
> >>>>ACEs on the object that control (extensible) access to properties
> >>>>(attributes) or property sets that you can group attributes into.
> >>>>
> >>>>See:
> >>>>
>
>>>>http://msdn.microsoft.com/library/en-us/ad/ad/controlling_access_to_acti
ve_directory_objects.asp
> >>>>
> >>>>HTH
> >>>>
> >>>>Lee Flight
> >>>>
> >>
> >
>