Understanding the AD LDS Schema
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
An Active Directory Lightweight Directory Services (AD LDS) schema defines, using object classes and attributes, the types of objects and data that can be created and stored in an AD LDS directory. Each AD LDS configuration set has its own independently manageable schema, which is stored in the schema directory partition. In keeping with the AD LDS design concepts of simplicity and flexibility, the base (or default) AD LDS schema contains only the classes and attributes that are needed to start an AD LDS instance. The schema can be extended with new classes and attributes, either by administrators or by the applications themselves. In addition, unneeded schema classes and attributes can be deactivated. As with all objects in the directory, access control lists (ACLs) protect schema objects, so that only authorized users can alter the schema. Every object in an AD LDS directory is an instance of an object class that is defined in a schema, as shown in the following illustration.
.gif)
Object classes
An object class represents a category of objects, such as users, printers, or application programs, that share a set of common characteristics. The definition for each object class contains a list of the attributes that can be used to describe instances of the class. For example, the User class has attributes such as givenName , surname , and streetAddress . The list of attributes for a class is divided into those attributes that an object of that class must contain and additional attributes that an object may contain. The definition of each class also lists the classes whose objects can be parents of objects of a given class.
For example, the following table shows the definition for the AD LDS User class.
| Attribute | Value |
|---|---|
Dn |
CN=User,CN=Schema,CN=Configuration |
objectClass |
top; classSchema; |
cn |
User; |
distinguishedName |
CN=User,CN=Schema,CN=Configuration; |
subClassOf |
organizationalPerson; |
mayContain |
audio; carLicense; departmentNumber; displayName; employeeNumber; employeeType; givenName; homePostalAddress; jpegPhoto; labeledURI; photo; preferredLanguage; roomNumber; secretary; uid; userPKCS12; userSMIMECertificate; x500uniqueIdentifier; |
rDNAttID |
cn; |
adminDisplayName |
User; |
adminDescription |
User; |
objectClassCategory |
1; |
lDAPDisplayName |
user; |
name |
User; |
objectGUID |
dac9093a-d2aa-408a-81bb-0fe8179165da; |
schemaIDGUID |
bf967aba-0de6-11d0-a285-00aa003049e2; |
objectCategory |
CN=Class-Schema,CN=Schema,CN=Configuration; |
defaultObjectCategory |
CN=Person,CN=Schema,CN=Configuration; |
Attributes
The schema also defines each attribute. The definition for each attribute includes unique identifiers for the attribute, the syntax for the attribute, optional range limits for the attribute values, whether the attribute can have only one value or multiple values, and whether the attribute is indexed. The directory schema defines each attribute exactly once. Each attribute can then be referenced by multiple object classes. For example, the description attribute is defined once and then referenced by many object classes.
The following table shows the attribute definition for telephone number , a representative schema attribute.
| Attribute | Value |
|---|---|
objectClass |
top; attributeSchema; |
cn |
Telephone-Number; |
distinguishedName |
CN=Telephone-Number,CN=Schema,CN=Configuration; |
instanceType |
0x4 = ( IT_WRITE ); |
whenCreated |
11/12/2002 13 |
22 |
14 Pacific Standard Time Pacific Daylight Time; |
whenChanged |
11/12/2002 13 |
22 |
14 Pacific Standard Time Pacific Daylight Time; |
uSNCreated |
217; |
attributeID |
2.5.4.20; |
attributeSyntax |
2.5.5.12; |
isSingleValued |
TRUE; |
rangeLower |
1; |
rangeUpper |
64; |
uSNChanged |
217; |
showInAdvancedViewOnly |
TRUE; |
adminDisplayName |
Telephone-Number; |
adminDescription |
Telephone-Number; |
oMSyntax |
64; |
searchFlags |
0; |
lDAPDisplayName |
telephoneNumber; |
name |
Telephone-Number; |
objectGUID |
bf19d7eb-ea0f-4f2d-af67-f439a037d8a4; |
schemaIDGUID |
bf967a49-0de6-11d0-a285-00aa003049e2; |
attributeSecurityGUID |
77b5b886-944a-11d1-aebd-0000f80367c1; |
systemOnly |
FALSE; |
systemFlags |
0x10 = ( FLAG_SCHEMA_BASE_OBJECT ); |
isMemberOfPartialAttributeSet |
TRUE; |
objectCategory |
CN=Attribute-Schema,CN=Schema,CN=Configuration; |
Single-valued and multivalued attributes
Attributes can be single-valued or multivalued. An instance of a single-valued attribute can contain only a single value. An instance of a multivalued attribute can contain multiple values that must all use the same syntax. Each value of a multivalued attribute must be unique.
Note
A multivalued attribute stores its values in random order. Therefore, you should not make any directory decisions—programmatic or manual—based on the order of the values in a multivalued attribute.
Indexed attributes
Indexing attributes helps to improve the performance of queries that are based on the indexed attribute. Both single-valued and multivalued attributes can be indexed; classes cannot be indexed. Attributes can be marked for indexing through their schema definition. Indexing an attribute also makes it possible for users to use wildcards (*) as prefixes and suffixes when they specify a search string. When you mark an attribute as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class. Indexing attributes, particularly multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. Therefore, you should index only commonly used attributes.
For general information about schemas, see Active Directory Schema (https://go.microsoft.com/fwlink/?LinkId=80809).