Using the Windows Server Protocols documentation set to better understand the Active Directory Schema
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 Active Directory schema - Directory Services (AD -DS).
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 these objects in order to understand how they relate to their classes, attributes and syntaxes in an actual schema file. 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. The LDIFDE utility can be used to import and export Active Directory objects. It is shipped with Windows 2008 Server and beyond, or as part of the Windows 2003 resource kit. The full name for this utility is the LDAP Data Interchange Format Data Exchange tool. Although I will use the abbreviation LDIFDE throughout this discussion, its full name underlies the fact that Active Directory is based on the LDAP Data Interchange Format standard which is a file format used in LDAP implementations. For more information regarding the LDAP Format see RFC 2849 - https://www.ietf.org/rfc/rfc2849.txt .
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 - https://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 -- https://msdn.microsoft.com/en-us/library/cc223122(PROT.13).aspx
· [MS-ADSC]: Active Directory Schema Classes -- https://msdn.microsoft.com/en-us/library/cc221630(PROT.13).aspx
· [MS-ADA1]: Active Directory Schema Attributes A-L -- https://msdn.microsoft.com/en-us/library/cc219751(PROT.13).aspx
· [MS-ADA2]: Active Directory Schema Attributes M -- https://msdn.microsoft.com/en-us/library/cc220154(PROT.13).aspx
· [MS-ADA3]: Active Directory Schema Attributes N-Z -- https://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 schema relate to one another. Using the following command from a command prompt I generated an ldf file for one of my installed Active Directories by running the command: ‘ldifde –f myschema.ldf’ from a command prompt. For clarity I have included this file along with two others in this blog. Here is a description of the included files:
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
where
-f filename Output file name
- s servername The server to bind to.
Full command arguments can be found with “ldifde -?”
This file, myschema.ldf, has a much larger amount of data specific to the contoso.com domain’s Active Directory as compared to the data in the file MS-AD_Schema_2K8_SP1_Consolidated-sorted.ldf. Both of these files are attached to this blog along with additional file, computers.ldf that shows computer objects in my Active Directory installation Please note that the schema file for the contoso.com domain is a completely fictitious Active Directory schema populated for testing purposes only. The Microsoft file is intended as a template containing most classes and attributes that you would find in a Windows 2008 Server SP1 Active Directory.
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 to view both class and attribute definitions.
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:
“3.1.1.2.2.2 LDAP Representations
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 |
attributeSyntax |
oMSyntax |
oMObjectClass |
|---|---|---|---|
Boolean |
2.5.5.8 |
1 |
- |
Enumeration |
2.5.5.9 |
10 |
- |
Integer |
2.5.5.9 |
2 |
- |
LargeInteger |
2.5.5.16 |
65 |
- |
Object(Access-Point) |
2.5.5.14 |
127 |
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x3E (1.3.12.2.1011.28.0.702) |
Object(DN-String) |
2.5.5.14 |
127 |
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0C (1.2.840.113556.1.1.1.12) |
Object(OR-Name) |
2.5.5.7 |
127 |
0x56 0x06 0x01 0x02 0x05 0x0B 0x1D (2.6.6.1.2.5.11.29) |
Object(DN-Binary) |
2.5.5.7 |
127 |
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0B (1.2.840.113556.1.1.1.11) |
Object(DS-DN) |
2.5.5.1 |
127 |
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x4A (1.3.12.2.1011.28.0.714) |
Object(Presentation-Address) |
2.5.5.13 |
127 |
0x2B 0x0C 0x02 0x87 0x73 0x1C 0x00 0x85 0x5C (1.3.12.2.1011.28.0.732) |
Object(Replica-Link) |
2.5.5.10 |
127 |
0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x06 (1.2.840.113556.1.1.1.6) |
String(Case) |
2.5.5.3 |
27 |
- |
String(IA5) |
2.5.5.5 |
22 |
- |
String(NT-Sec-Desc) |
2.5.5.15 |
66 |
- |
String(Numeric) |
2.5.5.6 |
18 |
- |
String(Object-Identifier) |
2.5.5.2 |
6 |
- |
String(Octet) |
2.5.5.10 |
4 |
- |
String(Printable) |
2.5.5.5 |
19 |
- |
String(Sid) |
2.5.5.17 |
4 |
- |
String(Teletex) |
2.5.5.4 |
20 |
- |
String(Unicode) |
2.5.5.12 |
64 |
- |
String(UTC-Time) |
2.5.5.11 |
23 |
- |
String(Generalized-Time) |
2.5.5.11 |
24 |
- |
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:
cn: Attribute-Schema
ldapDisplayName: attributeSchema
governsId: 1.2.840.113556.1.3.14
objectClassCategory: 1
rdnAttId: cn
subClassOf: top
systemMustContain: schemaIDGUID, oMSyntax, lDAPDisplayName,
isSingleValued, cn, attributeSyntax, attributeID
systemMayContain: systemOnly, searchFlags, schemaFlagsEx, rangeUpper,
rangeLower, oMObjectClass, msDs-Schema-Extensions, msDS-IntId,
mAPIID, linkID, isMemberOfPartialAttributeSet, isEphemeral,
isDefunct, extendedCharsAllowed, classDisplayName,
attributeSecurityGUID
systemPossSuperiors: dMD
schemaIdGuid:bf967a80-0de6-11d0-a285-00aa003049e2
defaultSecurityDescriptor: D:S:
defaultHidingValue: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Attribute-Schema,CN=Schema,
CN=Configuration,<RootDomainDN>
systemFlags: FLAG_SCHEMA_BASE_OBJECT | FLAG_DOMAIN_DISALLOW_RENAME
The definition of this class contains many attributes, all of which can be found in the [MS-ADA*] documentation. For example, systemMustContain is an attribute that specifies the attributeIds of some of the mandatory attributes of this class. Thus all attributes themselves must contain attributeIds for schemaIDGUID, oMSyntax, lDAPDisplayName,isSingleValued, cn, attributeSyntax, attributeID. Therefore the attributeSyntax attribute found in the above table is a required ID for all attributes. Not all attributes have to contain an oMObjectClass attribute as you can see from the previous attribute syntax table . You can look for an attributes definition based on its name in either [MS-ADA1], [MS-ADA2] or [MS-ADA3]. For example, attributeSyntax , a column header in the attribute syntax table, can be found in [MS-ADA1].
You should take note of the systemFlags attribute. It contains the following bitwise flags (further defined in [MS-ADTS] section 2.2.9):
fATTINDEX: *
fPDNTATTINDEX: *
fANR: Add this attribute to the ambiguous name resolution (ANR) set (if set, then fATTINDEX must be set). See [MS-ADTS] for ANR search.
fPRESERVEONDELETE: Preserve this attribute on logical deletion. This flag is ignored on link attributes.
fCOPY: Interpreted by LDAP clients, not by the server. If set, the attribute is copied on object copy.
fTUPLEINDEX: *
fSUBTREEATTINDEX: *
fCONFIDENTIAL: This attribute is confidential; special access check is needed. For more information, see [MS-ADTS] section 3.1.1.4.3.
fNEVERVALUEAUDIT: *
fRODCFilteredAttribute: If set, this attribute is in the RODC filtered attribute set.
2.75 Attribute attributeSyntax
This attribute specifies the OID for the syntax for this attribute.
cn: Attribute-Syntax
ldapDisplayName: attributeSyntax
attributeId: 1.2.840.113556.1.2.32
attributeSyntax: 2.5.5.2
omSyntax: 6
isSingleValued: TRUE
schemaIdGuid: bf967925-0de6-11d0-a285-00aa003049e2
systemOnly: TRUE
searchFlags:fPRESERVEONDELETE
systemFlags: FLAG_SCHEMA_BASE_OBJECT
schemaFlagsEx: FLAG_ATTR_IS_CRITICAL
Version-Specific Behavior: Implemented on Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 7.
The schemaFlagsEx attribute was added to this attribute definition in Windows Server 2008
Let’s look at some of the attributes that you see above,then we will move on to an example from the schema file. All of the below definitions come from the [MS-ADA*] documents:
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:
dn: CN=FILESERVER01,OU=Servers,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: FILESERVER01
distinguishedName: CN=FILESERVER01,OU=Servers,DC=contoso,DC=com
instanceType: 4
whenCreated: 20081027221316.0Z
whenChanged: 20081027221316.0Z
uSNCreated: 12806
uSNChanged: 12810
name: FILESERVER01
objectGUID:: o2nB9yVP306ZYUYlMs0NVA==
userAccountControl: 4128
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
localPolicyFlags: 0
pwdLastSet: 128696191965312500
primaryGroupID: 515
objectSid:: AQUAAAAAAAUVAAAATP4fPlGgN5m+BTa/VgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: FILESERVER01$
sAMAccountType: 805306369
objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=contoso,DC=com
isCriticalSystemObject: FALSE
dSCorePropagationData: 16010101000000.0Z
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 order with respect to the object hierarchy. Computer is a subClassof User which is a subClassof organizationalPerson etc. Keep in mind also that the object instance inherits attributes from its parent up to the top class. This means that you may need to look at all the different classes involved in the hierarchy to find which class actually contains that attribute. For example, the codePage attribute is part of the User Class.
I leave it as exercise for the reader to use the [MS-AD*] documentation to dig digger into this object to learn more about what the various attributes in this object represent and how they are derived.
[WEW1]Inserted new text
[WEW2]Inserted a close apostrophe