MIIS Solutions: Designing Effective Schema Extensions for Active Directory, part 2

Continued from part 1...

Figure 1

So, as shown in Figure 1, attributes are assigned to auxiliary sub-classes and sub-classes are combined to help define extensions to a structural class. When new objects of the structural object type are instantiated they inherit the structure defined by the combination of the class, sub-classes, and component attributes. By creating new auxiliary classes and linking new attributes to them you can extend built in classes like Users, Groups, and Computers, but how do I restrict access to a subset of attributes? Access can be controlled by attribute, but for the greatest flexibility you will likely want to use a Property Set; especially if you have more than a few attributes to extend.

Property Sets Defined

Property Sets in Active Directory provide two important features - they organize a set of like attributes into a convenient grouping and they control access to the attributes defined within using a single ACE entry instead of individual entries per attribute. You've probably already seen a Property Set but just didn't realize it.

Figure 2

In Figure 2 we see an example of Property Sets - Account Restrictions, General Information, Group Membership, Logon Information, and Public Information (there are more as well not shown) as displayed are all Property Sets that define access to a collection of attributes. It is important to notice that each Property Set is displayed as a set of Read and Write entries in the list - there are not discrete Read Property Sets or Write Property Sets and you don't create them that way.

Take for instance the Personal Information Property Set, this collection controls access to 41 attributes with a single click! So, how are the attributes linked to Property Sets? We understand how attributes link to sub-classes and how sub-classes link to structural classes, but where are Property Sets defined?

Property Set Relationships

Property Sets, unlike attributes and classes, are not schema attributes at all but are a special type of object called a controlAccessRight object that lives in the Configuration Naming Context under the Extended-Rights container as shown in Figure 3.

Figure 3

Well, that's where they live, but how are they related to attributes? Remember that GUID Converter Tool I told you about in Part 1? You'll need that tool to confirm the relationship but essentially there are two attributes that refer to one another. The Property Set's rightsGuidattributeSecurityGUID property. If you take the rightsGuid as displayed in Figure 4 and place it in the GUID Converter Tool (Figure 5) you can see what the Octet String version looks like:

Figure 4

Figure 5

Now when we look at an attribute with the Property Set and view it's attributeSecurityGUID property (Figure 6) we see they are the same and effectively linked:

Figure 6

So, an attribute's attributeSecurityGUID holds a SID that is the same as the SID specified in a Property Set's rightsGuid. These are not pointers per se and you should note that these are single valueed properties so an attribute can only ever be a member of a single Property Set at a time. The GUID Converter Tool also provides us the LDIF and LDAP versions of the same GUID so we can place this value in an LDIF script and an LDAP query respectively!

Later on you will have less difficulty defining your own Property Sets if you can keep the relationship and GUID types straight. In part 3 we'll talk more about Default Permissions for Authenticated Users and the Pre-Windows 2000 Compatibility Access group. These two groups make restricting access to sensitive data difficult.