Implementing an interoperable directory service requires an LDAP compliant backend. At some point you will need to load the targeted version of a schema from Windows into your implementation. Presented here are some of the concepts, documentation and tools to consider when working with the
Let’s start with some basic concepts about the Active Directory schema. The schema keeps track of things such as classes, class attributes, and relationships between objects such as subclasses and super classes. A super class is a parent while a child class inherits its attributes from the super class. The schema also enforces rules that govern both the structure and the content of the directory.
A class is a category of objects that share a set of common characteristics. It is a formal description of an object that can be stored in the directory. Each object in the directory is an instance of one or more classes in the schema.
Attributes define the types of information that an object can hold. For each class, the schema specifies the mandatory attributes and optional attributes that constitute the set of shared characteristics of the class.
The syntax is the data type of a particular attribute. Syntaxes determine what data type an attribute can have. Active Directory uses a set of predefined syntaxes. The predefined syntaxes do not actually appear in the directory, and new syntaxes cannot be added.
The schema is represented in Active Directory by a set of objects known as schema objects. This discussion will focus mainly on examining
I’ve included a schema file derived from the MS-AD* documentation in the protocols test suite that can be examined to see the various classes and attributes included in the schema for Windows 2008 Server SP1. You can also generate a schema file using LDIFDE which will contain information about your current installation.
The documents that we will be using to help us understand how this all fits together are part of the Windows Server Protocols documentation set – http://msdn.microsoft.com/en-us/library/cc216517(PROT.10).aspx . The particular documents from set that we will use are:
· [MS-ADTS]: Active Directory Technical Specification — http://msdn.microsoft.com/en-us/library/cc223122(PROT.13).aspx
· [MS-ADSC]: Active Directory Schema Classes — http://msdn.microsoft.com/en-us/library/cc221630(PROT.13).aspx
· [MS-ADA1]: Active Directory Schema Attributes A-L — http://msdn.microsoft.com/en-us/library/cc219751(PROT.13).aspx
· [MS-ADA2]: Active Directory Schema Attributes M — http://msdn.microsoft.com/en-us/library/cc220154(PROT.13).aspx
· [MS-ADA3]: Active Directory Schema Attributes N-Z — http://msdn.microsoft.com/en-us/library/cc220699(PROT.13).aspx
Let’s talk about how you can use these documents to obtain a better understanding of what an Active Directory schema looks like and how the objects, classes and attributes in the
Myschema.ldf – this is the schema file for the contoso.com domain generated with the previous ldifde command. This is an installation of Active Directory that I use for testing purposes only.
MS-AD_Schema_2K8_SP1_Consolidated-sorted.ldf – This file contains a non installation specific Active Directory schema for Windows 2008 Server SP1.
Computers.ldf – This file contains the computer objects for the contoso.com Active Directory.
Note that all of these files can be opened as text file. I used notepad to view them.
An example of an alternate usage of ldifde that exports the schema from a particular server is:
ldifde –f myschema.ldf –s JD-SERVER01.contoso.com
-f filename Output file name
– s servername The server to bind to.
Full command arguments can be found with “ldifde -?”
This file, myschema.ldf,
Before we look at some data that you can find in an actual schema file, I wanted to mention more about the schema syntax. While discussing the schema syntax, you will also get a taste of how classes and attributes are defined, and how to use the [MS-AD*] documents
The schema syntax is covered in the [MS-ADTS] document. The below description of LDAP Representations and the associated table are taken directly from that document:
The LDAP syntaxes supported by DCs are as shown in the following table. The set of syntaxes supported is not extensible by schema modifications. Each syntax is identified by the combination of the attributeSyntax, oMSyntax and, in select cases, oMObjectClass attributes of an attributeSchema object. The cases for which oMObjectClass is not used are indicated by the presence of a hyphen in the oMObjectClass column in the table. The combinations shown in the following table are exhaustive; this table is consistent and identical for all versions of Windows Server.”
LDAP syntax name
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x3E (126.96.36.199.1011.28.0.702)
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0C (1.2.840.1135188.8.131.52.12)
0x56 0x06 0x01 0x02 0x05 0x0B 0x1D (184.108.40.206.220.127.116.11)
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0B (1.2.840.113518.104.22.168.11)
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x4A (22.214.171.124.1011.28.0.714)
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x5C (126.96.36.199.1011.28.0.732)
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x06 (1.2.840.1135188.8.131.52.6)
The representation for many of the preceding syntaxes is adopted from [RFC2252] – Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions.
Notice that the columns in the above table; attributeSyntax, oMSyntax and oMObjectClass are all attributes. For each object attribute in Active Directory there is an attributeSchema object and for each class in the Active Directory there is a class Schema object.
Classes for Active Directory can be found in the [MS-ADSC]. One such class, the attributeSchema class defines an attribute object in the schema. The layout for this class, found in [MS-ADSC] is shown here:
This attribute specifies the OID for the syntax for this attribute.
Version-Specific Behavior: Implemented on Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 7.
cn (ADA1) — This attribute specifies the name that represents an object. It is used to perform searches.
ldapDisplayName (ADA1) — This attribute specifies the name used by LDAP clients, such as the ADSI LDAP provider, to read and write the attribute by using the LDAP protocol.
attributeId (ADA1) — This attribute specifies the unique X.500 object identifier (OID) for identifying an attribute
schemaIdGuid (ADA3) — This attribute specifies a unique GUID that identifies this attribute, and is used in security descriptors. It is required on an attributeSchema object. If omitted during Add, the server will auto-generate a random GUID
systemOnly (ADA3) — This attribute specifies a Boolean value that specifies whether only Active Directory can modify the class. System-Only classes can be created or deleted only by the directory system agent.
Now let’s look at an actual object in the schema file for my domain. You can do text sorts on this file in various ways. For example you can search for objects by searching for the string “objectClass: computer”. Alternatively you can create a file using LDIFDE and its search filter capability. For example you could search for all of the computers in the directory with the following command:
Ldifde -f computers.ldf –s JD-SERVER01.contoso.com –r objectClass=computer
Switches: -f to specify the file to export to, -s to specify the server to bind to, and –r the filter
You can use any of the classes found in [MS-ADSC] for this filter.
Below is one of the computer objects in my domain as seen in the schema file:
There are a couple of things to note in this example. The objectClass top is the top-level class from which all classes are derived. The object classes in the example appear in their correct