Understanding Active Directory in Windows

Active Directory Structure and Storage Architecture

The Active Directory structure and storage architecture consists of four parts:

• Active Directory domains and forests. Forests, domains, and organizational units (OUs) make up the core elements of the Active Directory logical structure. A forest defines a single directory and represents a security boundary. Forests contain domains.
  
   
• Domain Name System (DNS) support for Active Directory. DNS provides a name resolution service for domain controller location and a hierarchical design that Active Directory can use to provide a naming convention that can reflect organizational structure.
  
   
• Schema. The schema provides object definitions that are used to create the objects that are stored in the directory.
  
   
• Data store. The data store is the portion of the directory that manages the storage and retrieval of data on each domain controller.
  
  The following figure illustrates the Active Directory data structure and storage architecture.

 

 

 

Active Directory Domains and Forests

Domains partition the directory into smaller sections within a single forest. This partitioning results in more control over how data is replicated so that an efficient replication topology can be established and network bandwidth is not wasted by replicating data where it is not required. OUs make it possible to group resources in a domain for management purposes, such as applying Group Policy or delegating control to administrators.

The following figure illustrates the relationships of OUs, domains, and forests in the logical structure architecture.

 

DNS Support for Active Directory

Active Directory in Windows Server 2003 uses DNS as its domain controller location mechanism. When any of the principal Active Directory operations, such as authentication, updating, or searching, is performed, Windows Server 2003 computers use DNS to locate Active Directory domain controllers, and these domain controllers use DNS to locate each other. For example, when a network user with an Active Directory user account logs on to an Active Directory domain, the user’s computer uses DNS to locate a domain controller for the Active Directory domain to which the user wants to log on.

To log on to a network that consists of an Active Directory forest, a client workstation must first be able to locate a nearby domain controller. The domain controller is necessary for initial authentication of both the workstation and the user and for subsequent authorization of the user for the files and resources to which the user needs access. The support that is provided to Active Directory by DNS enables a client workstation to locate a domain controller.

Active Directory Schema

The Active Directory schema contains definitions for all the objects that are used to store information in the directory. There is one schema per forest. However, a copy of the schema exists on every domain controller in the forest. This way, every domain controller has quick access to any object definition that it might need, and every domain controller uses the same definition when it creates a given object. The data store relies on the schema to provide object definitions, and the data store uses those definitions to enforce data integrity. The result is that all objects are created uniformly, and it does not matter which domain controller creates or modifies an object because all domain controllers use the same object definition.

The following figure illustrates the relationship of the schema to the data store in the schema architecture.

 

Active Directory Data Store

The Active Directory data store is made up of several components that together provide directory services to directory clients. These components include the following:

• Four interfaces:
   
  • Lightweight Directory Access Protocol (LDAP)
    
     
  • Replication (REPL) and domain controller management interface
    
     
  • Messaging API (MAPI)
    
     
  • Security Accounts Manager (SAM)
    
     
• Three service components:
   
  • Directory System Agent (DSA)
    
     
  • The database layer
    
     
  • Extensible Storage Engine (ESE)
    
     
• The directory database where the data is actually stored
  
   

The following figure illustrates the relationships of these components in the data store architecture.

 

Active Directory Application Mode (ADAM)

Active Directory Application Mode (ADAM), which was introduced with Windows Server 2003, addresses requirements of directory-enabled applications that don't need to store their data in Active Directory (AD) but could still benefit from the security and authentication AD can offer. For example, an application might have to store a large amount of information that other applications don't need or that doesn't need to be replicated to every domain controller (DC). ADAM uses a separate database that has many of AD's features (e.g., schema, replication, management) but is totally separate from AD. This separate database means that you can have a separate schema for each ADAM instance--a feature that can be useful for testing. Like AD, ADAM offers a Lightweight Directory Access Protocol (LDAP) interface that lets LDAP- and AD-based applications seamlessly use ADAM.

ADAM runs as runs as a user service rather than as a system service and doesn't have to run on a domain controller (DC). And because it's a nonsystem service, you can have multiple instances of ADAM running on one box. (However, you must configure each instance to listen on a unique LDAP port--for example, only one instance could use the default ports 389 and 636.)

Active Directory Schema

The schema is the blueprint for data storage in Active Directory. Each object in Active Directory is an instance of a class in the schema. A user object, for example, exists as an instance of the user class. Attributes define the pieces of information that a class, and thus an instance of that class, can hold. Syntaxes define the type of data that can be placed into an attribute. As an example, if an attribute is defined with a syntax of Boolean, it can store True or False as its value, or it can be null. A null value has an implementation-specific meaning; it could mean True or False depending on the application using the value.

Active Directory contains many attributes and classes in the default schema, some of which are based on standards and some of which Microsoft needed for its own use. Each release of Active Directory since Windows 2000 has included updates to the default schema. However, the Active Directory schema was designed to be extensible, so that administrators could add classes or attributes they deemed necessary.

Structure of the Schema

The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in the http://mycorp.com forest would be cn=schema,cn=Configuration,dc=mycorp,dc=com. You can view the contents of the container directly by pointing an Active Directory viewer such as ADSIEdit or LDP at it. You can also use the Active Directory Schema MMC snap-in, which splits the classes and attributes in separate containers for easy viewing, even though in reality all the schema objects are stored directly in the Schema Container.

The schema itself is made up of two types of Active Directory objects: classes and attributes. In Active Directory, these are known respectively as classSchema (Class-Schema) and attributeSchema (Attribute-Schema) objects. The two distinct forms of the same names result from the fact that the cn (Common-Name) attribute of a class contains the hyphenated easy-to-read name of the class, and the lDAPDisplayName (LDAP-Display-Name) attribute of a class contains the concatenated string format that is used when querying Active Directory with LDAP or ADSI. In the schema, the lDAPDisplayName attribute of each object is normally made by capitalizing the first letter of each word of the Common-Name, and then removing the hyphens and concatenating all the words together. Finally, the first letter is made lowercase. This creates simple names like user, as well as the more unusual sAMAccountName and lDAPDisplayName.

Whenever you need to create new types of objects in Active Directory, you must first create a classSchema object, defining the class of the object and the attributes it contains. Once the class is properly designed and added to the schema, you can then create objects in Active Directory that use the class. If the class you are adding will have custom attributes that are required to be populated when new instances of that class are created, you must define the attributeSchema objects first. If you just want to add a new attribute to an existing class, you must create the attributeSchema object and associate the attribute with whatever classes you want to use it with.