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.”

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

Schema.zip