LDAP Information Model
The LDAP information model describes the structure of information in a directory. The LDAP information model is based on the entry, which contains information about some object, for example, a person or computer. In Active Directory, an LDAP entry is referred to as an object. Entries are composed of attributes, which have a type and one or more values.
The LDAP information model organizes objects into a hierarchical tree structure. The implementation of the model is called the schema, which is a set of objects that defines the structure and content of every object that can be created in a directory service.
A default (base) schema is installed with Active Directory. The Active Directory schema is stored in the schema directory partition, and the schema is replicated to every domain controller in the Active Directory forest.
Classes and Attributes
Classes and attributes are defined in the schema by classSchema objects (object classes) and attributeSchema objects (object attributes), as follows:
- Object classes are categories of objects that can be created in the directory. For example, users, computers, and printers are classes of objects. Every object in the directory is created as an instance of some class according to the definition that is stored in the classSchema object for the respective class.
- Object attributes are the characteristics of the object. (These characteristics are also called properties). An attribute can hold a value or values that represent some property of the object. For example, given name, surname, and e-mail address are attributes of every object of the user class, and their values can be created only as character strings. The schema specifies the attributes that are required to have values and the attributes that can have values as an option. In Active Directory, only attributes that have values assigned to them actually use storage space in the database.
- Each attribute has a syntax that is specified in the schema that determines the kind of values that are allowed in the attribute. Examples of attribute syntaxes are Unicode string, binary, and integer.
New object classes and attributes can be added to the schema, and existing objects can be modified by adding or modifying classSchema and attributeSchema objects.
Child classes inherit attributes from their parent classes. Therefore, each class builds on the attribute set of its parent class. The position in the directory tree of one object relative to another is also defined in the schema.
Categories of Object Classes
Different categories of object classes make it possible to define structure in the directory. The 1993 X.500 specification requires that object classes be assigned to one of three categories:
- Structural
- Abstract
- Auxiliary
Structural classes
Structural classes are the only classes that can have instances in the directory. That is, you can create directory objects whose class is one of the structural classes. A structural class:
- Can be used in defining the structure of the directory.
- Is derived from either an abstract class or another structural class.
- Can include any number of auxiliary classes in its definition.
Abstract classes
Abstract classes are templates that are used to derive new structural classes. Abstract classes cannot be instantiated in the directory. This means that no object can belong only to an abstract class; each object of an abstract class also belongs to some structural subclass of that class. A new abstract class can be derived from an existing abstract class. Abstract classes only provide attributes for subordinate classes, which are called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived (its superclass) in addition to those attributes that are specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth.
Auxiliary classes
Auxiliary classes are like include files; they contain a list of attributes. Adding an auxiliary class to the definition of a structural class or an abstract class adds the auxiliary class’s attributes to the definition of the structural class or the abstract class. An auxiliary class cannot be instantiated in the directory, but new auxiliary classes can be derived from existing auxiliary classes. For example, the securityPrincipal class is an auxiliary class, and it derives its attributes from the parent abstract class called Top. Although you cannot create a security principal object in the directory (because auxiliary classes cannot have instances), you can create an object of the structural class user, which has the securityPrincipal class as an auxiliary class. The attributes of the securityPrincipal class help the system recognize the user object as a security account. Similarly, the group class has securityPrincipal as an auxiliary class.
Windows 2000 Server vs. Windows Server 2003 auxiliary classes
The behavior of auxiliary classes has changed in Windows Server 2003. In Windows 2000 Server, changes that are made to an auxiliary class affect its parent class as well as all instances of the parent object. For example, adding an auxiliary class called pager to the structural class user affects all instances of user, which are all of the user accounts that are created with the user class.
In Windows Server 2003, auxiliary classes can be assigned dynamically to individual instances of classes, rather than being applied automatically to all instances. For example, you can assign the pager auxiliary class to only those users who need it.
Object Identifiers
Object identifiers (also known as OIDs) are hierarchical, dotted-decimal numeric values that uniquely identify entries in a data model. Object identifiers are found in OSI applications, X.500 directories, Simple Network Management Protocol (SNMP), and other applications in which uniqueness is required. Object identifiers are based on a tree structure in which a designated issuing authority (such as the ISO) allocates a branch of the tree to a subauthority, which in turn can allocate subbranches. The Active Directory schema identifies the object identifier for each class, attribute, and syntax.
Schema Versions
The schema directory partition has an attribute called objectVersion that stores the schema version number for a forest. To facilitate upgrading your forest from Windows 2000 Server to Windows Server 2003, Windows Server 2003 includes a tool (Adprep.exe) that automatically upgrades the schema to the version that is required by Windows Server 2003. Before you upgrade the first domain controller, you must use this tool to prepare the domain and the forest so that the schema is upgraded before the operating system is upgraded. Running Adprep.exe prepares the forest and the domain for the Active Directory upgrade by making certain data changes, including an extension of the schema. This schema extension merges existing schema information with new schema information that is supplied by Adprep.exe. This merging of schema information does not affect any schema modifications that you may have already made in your existing environment.
Leaf Objects and Container Objects
Objects in Active Directory are either leaf objects or container objects. A leaf object is an object that has no child objects. The term “container” refers to one of two things:
- An object of the container structural class
- An object that has child objects
In the schema, a structural class defines objects that can be created as instances of the class in Active Directory. To have child objects, an object must be an instance of a class that is defined by the schema as being a possible superior of those child objects.
Note
- A new attribute in the Windows Server 2003 schema, msDsApproxImmedSubordinates, stores the approximate count of immediate children of a container. You can use the ADSI Edit snap-in in Microsoft Management Console (MMC) to view the value of this attribute for any container object. Windows 2000 Server containers do not have this attribute.
Directory Tree
The directory tree represents the hierarchy of Active Directory objects for a given forest. The structure of the hierarchy is derived from the schema, and the directory service implements the hierarchy. The hierarchy provides the basis both for using names for navigation and for defining the scope of search requests.
Every object in Active Directory has exactly one parent, and a reference to the parent object is stored with the object. By virtue of these parent references, the hierarchy of objects that are managed by Active Directory forms a tree structure. The objects that populate the directory create this tree structure according to the rules of the schema. For example, the schema might dictate that a given class of object can be the child of one class but not the child of another class.
The following are architectural restrictions and requirements in the directory tree:
- Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the child of an organizational unit (OU).
- The root of the directory tree is a DSA-Specific Entry (DSE) called the rootDSE, or the directory root. The rootDSE is an object that has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of a given domain controller. Therefore, the rootDSE constitutes the root of the directory tree from the perspective of the domain controller to which you are connected.
- Below the rootDSE, every directory has a root domain, which is the first domain that is created in a forest. This domain always has a child container called the Configuration container, which contains configuration data for the forest.
rootDSE
An LDAP directory service is also referred to as a DSA. In Active Directory, servers that host DSAs are domain controllers.
At the root of an LDAP directory tree is a DSE (the rootDSE), which is not part of any directory partition. TherootDSE represents the top of the logical namespace for one domain controller. The rootDSE attributes contain information about the directory server, including its capabilities and configuration.
There is only one root for a given DSA, but the information that is stored in the root is specific to the domain controller to which you are connected. Among other things, the attributes of the rootDSE identify the following key information:
- The directory partitions (the domain, schema, and configuration directory partitions) that are specific to one domain controller
- The forest root domain directory partition
In this way, the rootDSE provides a “table of contents” for a given domain controller.