Active Directory Back to Basics - The Schema
What is the Schema?
In a nutshell the schema is the blueprint for Active Directory. There is one schema per Active Directory forest and its stored in the schema naming context (CN=Schema,DC=domain,DC=domain). It is made up of classes and attributes. The schema master FSMO role is responsible for maintaining and making changes to the schema, and only the DC holding this role can make changes to the schema.
Each object in Active Directory is an instance of a class. Lets take a look in more detail. The classSchema and attributeSchema are defined separately within the Active Directory schema. Since attributes are associated with classes keeping them separate means that attributes can belong to multiple classes.
We can see this through the Active Directory Schema MMC. To access the MMC you first need to register the schmmgmt.dll using regsrv32. Once registered you can launch the MMC where you would see something similar to this.
http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/SNAGHTML18af1d5_thumb.png
As you can see classes and attributes are shown separately.
Lets take a look at the user class as an example.
http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb.png
We can see that the user class has a few properties which define it, the common name, x500 OID and Class type.
LDAP was originally based on the X.500 standard, and since Active Directory is based on LDAP we see references to the X.500 OID. The X.500 standard was defined by the ISO and ITU organisations. In simple terms the X.500 standards specify that individual object classes within an organization can be uniquely defined and identified. This is where the OID (object identifier) came from.
How is the OID made up?
The OID is made up of two parts, the first part indicates the path to the branch holding the object in the X.500 tree, the second part defines the object within that branch. Looking at the OID for the user class we can break it up as follows, I’ve highlighted the various parts
X.500 OID = 1.2.840.113556.1.5.9
Object ID = 1.2.840.113556.1.5.9
Branch = 1.2.840.113556.1.5.9
The branch keeps going down to the first point. Each organisation that needs to use OIDs can request an enterprise number from IANA. For example Microsoft have an OID of 1.3.6.1.4.1.311, however countries also have an OID number and for the US this is 1.2.840. Microsoft opted to use this instead of their enterprise OID number. We can see this here
US = 1.2.840
You may see some much shorter OID’s, this is because Microsoft used the original classes from the X.500 standard.
Class Type
There are three categories of class type that can be specified, Structural, Abstract and Auxiliary.
We can see from our user example the class type is structural – this indicates that we can create objects of this class in active directory. Abstract classes are the same as structural in that they it can hold its own and inherit attributes from other classes, however you can’t create an object with an abstract class. Auxiliary class is just used to store attributes that can be used by other classes, An example of an auxiliary class would be securityPrincipal.
Inheritance
We now know that classes can inherit attributes from other classes, so lets take a look at the user class in a little more detail and see what this really means.
http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb1.png
Looking at the above screen capture of the user properties attributes tab we can see that there are no mandatory attributes set (mustContain) but there are a number of optional attributes (mayContain). We also know that you can’t create a user account in active directory without at minimum the sAMAccountName and a security ID (objectSID). So this leads us to inheritance. Looking at the relationship tab we can see a number of Auxiliary classes, one of which is securityPrincipal. If we look into the attributes on the securityPrincipal class we can see mandatory (mustContain) attributes are objectSID and sAMAccountName. So we now understand that the user class is inheriting the mustContain attribute from the securityPrincipal class. The same applies with the mayContain attribute.
http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb2.pnghttp://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb3.png
Attributes
Attributes are stored within the schema as an instance of the class attributeSchema. We can get a list of all the attributes of this class here.
Lets take a look at an example attribute focusing on the userPassword attribute.
http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb4.png
From this we can see similar properties to the class, description, common name and X.500 OID. We also see an additional syntax and range. There are multiple syntax available such as Boolean, Case insensitive string, integer etc. The syntax, or data-type, defines what the attribute can hold, In this example Octet String refers to a byte string. We can also see the minimum and maximum values – in this example it means the userPassword attribute can be a minimum of 1 and maximum of 128.
We can also see some additional properties for the userPassword attribute:
| Attribute is active | This simply defines if the attribute is in use or not |
| Index this attribute | This is a search flags value to show if the attribute needs to be indexed |
| Ambiguous Name Resolution | This is a search flags value. ANR allows partial matches to be found when searching AD. An explanation can be found here |
| Replicate this attribute to the global catalog | This sets the isMemberOfPartialAttributeSet property of the attribute to "True", which makes the attribute a member of the Partial Attribute Set (PAS), which means it is replicated to the global catalogs |
| Attribute is copied when duplicating a users | This is another search flags value and enables the attribute to be copied when copying users, an example of this would be the department attribute which is copied over when copying user accounts |
| Index this attribute for containerized searches | This is a search flag value to indicate if the attribute is indexed |
NB: indexing of objects can speed up LDAP queries, however it will also consume disk space. Indexes are not replicated amongst domain controllers, rather each domain controller is responsible for building its own index.
Summary
In summary the AD Schema is the bare bones / underpinning of Active Directory. It’s function and health is critical to the correct workings of AD and any changes should only ever be made after fully testing and understanding the implications that they will cause. Each forest contains one schema, and really the only way back from a failed schema update / corruption is a full forest restore.
I’ve only touched on the basics of how the schema works and hangs together, but hopefully you will find some of this article useful to help your understanding.