• Home
• Active Directory Structure - MCSE Prep

Section 4.3: Active Directory Structure

Active Directory allows the administrator to separate the logical and physical structure of the network. The logical structure involves the organization of objects, while the physical structure involves the communication of objects.

4.3.1: Logical Structure

The logical components of Active Directory are objects and their associated attributes. Object classes are merely definitions of the object types that can be created in Active Directory. The schema is the Active Directory mechanism for storing object classes. It also permits the addition of object classes and associated attributes.

Active Directory uses a hierarchical domain infrastructure of networked computers, with the domain as the foundation, to organize objects. The domain model is a design facility that permits the logical arrangement of objects within administrative, security, and organizational boundaries. Each domain has its own security permissions and unique security relationships with other domains. Active Directory uses multimaster replication to communicate information and changes among domains.

4.3.1.1: Domains

A domain comprises computer systems and network resources that share a logical security boundary. Although a domain can cross physical locations, all domains maintain their own security policies and security relationships with other domains. They can be created to define functional boundaries such as those between administrative units, or to group of resources or servers that use a common domain namespace.

The first domain that is created in Windows Server 2003 network is called the forest root domain. When other domains are created on the network, they added to the root domain to form the tree structure or the forest structure, depending on the domain name requirements.

One-Way, Nontransitive Trust

Networks running Windows NT 4.0 and earlier versions of Windows NT use oneway, nontransitive trust relationships,

which must be manually created. In a oneway, nontransitive trust relationship, if one domain trusts another domain, the other domain does not automatically trust the trusting domain, and the trusting domain

does not automatically trust the domains

that the other domain trusts.

The Active Directory directory services supports one-way, nontransitive trust relationships for connections to existing Windows NT 4.0 and earlier domains and to allow the configuration of trust relationships with domains in other trees.

A tree is a hierarchical arrangement of Windows Server 2003 domains that share a contiguous namespace. In such an arrangement the root domain name is attached as a suffix to the new domain names. The new domain is called a child domain of an existing parent domain and has a two-way, transitive trust relationship with its parent domain. Thus, a domain tree structure is formed by adding child domains to the root domain. The root domain contains the configuration and schema data for the tree.

As child domains are added to the domain tree, Active Directory partitions are replicated to one or more domain controllers within each of the domains.

A forest can either consist of a single tree or number of trees that do not share a contiguous namespace but do share a common schema and global catalog. In this arrangement, every tree root domain has a transitive trust relationship with the root domain. A single tree that is not related to any other tree constitutes a forest of one tree. The root domain contains the configuration and schema data for all trees in the forest.

Both a tree and a forest are namespaces, which is a bounded area in which a name can be resolved. Using a common namespace allows you to unify and manage multiple hardware and software environments in your network. There are two types of namespaces:

• Contiguous namespace. The name of the child object in an object hierarchy always contains the name of the parent domain. A tree is a contiguous namespace because the name of any child object in a tree always contains the name of the parent tree.

• Disjointed namespace. The names of a parent object and of a child of the same parent object are not directly related to one another. A forest is a disjointed namespace because all trees in a forest do not share a common naming structure.

4.3.1.2: Organizational Units (OUs)

Active Directory also allows administrators to group domains and child domains with similar administrative and security characteristics into administrative substructures known as organizational units (OUs). OUs are container objects; therefore objects, including other OUs, can be organized within OUs for administrative purposes. A domain usually comprises one or more OUs arranged hierarchically. OUs provide levels of administrative authority for applying Group Policy settings and delegating administrative control. The latter allows an administrator to delegate administrative duties for certain Active Directory objects to nonadministrative users while Group Policy is used to allow administrators to specify Group Policy settings for a site, domain, or organizational unit. Active Directory then enforces these Group Policy settings for all users and computers in the container.

Your OU structure can model the physical organizational, geopolitical, or administrative structure of your company. You can combine objects into a logical hierarchy of OUs that represent:

• Your company's organizational model, in which case it is based on departmental or geographical boundaries; or

• Your company's administrative model, in which case it is based on which administrators are responsible for managing specific users and resources across the network.

To create an OU within a domain or child domain, do the following:

4.3.1.3: Schema

The schema is a framework of definitions that establishes the type of objects available to Active Directory. These definitions are divided into object classes, and the information that describes the object is known as its attributes.

The schema is stored in the Active Directory database file Ntds.dit. Object definitions are stored as individual objects, and can be treated in the same way that other objects are treated. The default schema is created with the first installation of Active Directory. It contains common objects and properties for such items as users, groups, computers, printers, and network devices. It also establishes the default Active Directory structure that is used internally.

Because schema is an extensible component, new object classes may be dynamically added to the current schema and old object classes can be modified. It was not possible to modify or deactivate system classes and attributes under Windows 2000, but it is possible under Windows Server 2003.

By default, the schema is accessible only to the Enterprise Administrators and Schema Admins user groups. Enterprise Administrators and Schema Admins can managed the Active Directory schema through the Active Directory Schema snap-in tool, which becomes available when you install the Administrative Tools pack (adminpak.msi) from the i386 folder on the Windows Server 2003 Installation CD, or the Schema Active Directory Service Interface (SADS). The SADS provides access to four objects and schema object containers. The schema object container attaches definitions to the directory tree. It is typically represented as a child of the directory root. In turn, each instance has a unique individual schema.

The four objects and schema object containers that SADS provides access to are listed in Table 4.1.

Table 4.1: Schema Active Directory Service Interface Objects

Object	Description
Schema	Contains all the information involved in a particular Active Directory schema.
Object Class	Establishes the classification of the object. Object classes include: Name Object identifier (OID) Optional attributes and required attributes Parent object classes Derived classes from secondary or auxiliary classes
Property	Describes the defined properties.
Syntax	Describes first how the properties are defined, then specific options.

The Schema Operations Master domain controller manages the structure and content of the schema. It replicates schema information to the other domain controllers in the forest. Every domain controller loads a copy of the schema in a cache to ensure rapid access to current object and attribute definitions. If changes occur in the schema, the cache is refreshed.

4.3.2: Physical Structure

In its physical structure, Active Directory consists of a database in which objects and their attributes are stored. As it stores objects, the Active Directory database is an object-orientated database. Active Directory relies on the use of the Lightweight Directory Access Protocol (LDAP) to enable access to the objects and attributes in its database. This access is enabled through the Extensible Storage Engine (ESE) and a DNS-based locator system. The Active Directory database consists of tables with rows representing objects, and columns representing attributes of those objects. Windows Server 2003 uses the object-oriented database engine, the ESE that was first introduced with Exchange Server, to manage its object-oriented table structure. In addition, object query is enabled through DNS. Thus, when an LDAP client needs to find a server hosting a directory service, it does so by querying DNS, which in turn makes use of service locator (SRV) records to put pointers in DNS to indicate the names of servers hosting LDAP and Kerberos services.

The physical structure of Active Directory also holds the mechanisms for data communication and replication. This physical structure consists of two sections: the definition of the IP subnet network structural component that constitutes Active Directory sites, and the physical server that stores and replicates Active Directory data known as the domain controller and the related Global Catalog.

4.3.2.1: Sites

The physical network structure of Active Directory is based on a unit known as a site. A site comprises one or more TCP/IP subnets that are connected by high-speed, reliable connections. Many subnets can belong to a single site, but a single subnet cannot span multiple sites. The first site is set up automatically when you install Active Directory on the first domain controller in a forest. By default, this site is called Default-First-Site-Name but it can be renamed.

The primary purpose of a site is to ensure the rapid and economical transmission of data, including efficient directory services replication. The Active Directory physical structure governs when and how replication occurs in both within sites and between sites. The system administrator can use the Active Directory Sites and Services snap-in to manage the topology of replication services.

4.3.2.2: Domain Controllers

A domain controller is a server that contains a copy of Active Directory. All domain controllers are peers and maintain replicated versions of Active Directory for their domains. The domain controller plays an important role in both the logical and physical structures of Active Directory as it organizes all the domain's object data in a logical and hierarchical data store. It also authenticates users, provides responses to queries about network objects, and replicates directory services.

Each Active Directory domain or child domain can contain one or more domain controllers that replicate the directory partition.

4.3.3: Domain Controller Roles

Some domain controllers are assigned specific roles to facilitate performance and to reduce conflict. Windows Server 2003 supports two forms of specialized function: the Global Catalog and Master Operation roles.

4.3.3.1: The Global Catalog

The Global Catalog (GC) performs three important functions:

• It provides data that permits network logon

• It stores the information that is necessary to locate an object in Active Directory

• It contains the access permissions for each object and attribute stored in the global catalog and thus ensures that users can find only objects to which they have been assigned access.

By default, the first domain controller that you create in Active Directory is designated the global catalog server. Thus, in single domain controller environments, Active Directory and the GC reside on the same server. However, in multiple domain controller environments exist, it is recommended that you move the GC to its own dedicated domain controller. In addition, more than one GC server can exist in a domain. Having at least one GC domain controller per site is recommended. You can move the default GC to another domain controller by modifying the NTDS Setting Properties in the Sites and Server Management snap-in. You can also use the Sites and Servers Management snap-in to add additional GC servers.

4.3.3.2: Master Operation Roles

By default, all domain controllers in a domain are equal peers. However, there are certain Active Directory functions that can be performed by only a single domain controller to prevent possible conflict. These functions are called Flexible Single Master Operations (FSMOs). The domain controller assigned a particular FSMO is called a role master.

Some FSMO roles are unique to each domain while others are unique to the forest. There are the five FSMO roles: the PDC Emulator; the RID Master; the Infrastructure Master; the Domain Naming Master; and the Schema Master. The Domain Naming Master role and the Schema Master role are forest-wide roles that apply at the forest level, while the PDC Emulator role; the RID Master role; and the Infrastructure Master role are domain-wide roles that apply at the domain level.

4.3.3.3: PDC Emulator

In the default Windows 2000 mixed domain functional level, Active Directory supports the presence of downlevel Windows NT 4.0 Backup Domain Controllers (BDCs) by emulating a Windows NT 4.0 Primary Domain Controller (PDC) on a Windows 2000 or Windows Server 2003 domain controller. This is

necessary because BDCs will only replicate from a PDC. The Windows 2000 or Windows Server 2003 domain controller that performs this function is the PDC Emulator role master. While in the Windows 2000 mixed domain functional level, objects representing security principals, i.e., users, computers, and groups, can only be created by the PDC Emulator. In addition, when a user changes a password, or an administrator resets a password for a user, the update is replicated to the PDC Emulator. The domain controllers in a domain check with the PDC emulator to see if a user's password has been changed when a user enters an "invalid" password. If the password has been changed, and is in fact valid, the user is allowed to logon.

You can transfer the PDC Emulator master role to another domain controller through the Active Directory Users and Computers snap-in.

4.3.3.4: RID Master

In a Windows domain, all security objects have a security identifier (SID). This SID is a combination of the SID of the domain and a sequential number called the Relative ID (RID), which is supplied by the RID Master. In domains that are in the default Windows 2000 mixed domain functional level, only the PDC Emulator can create security principals, therefore the PDC Emulator and the RID Master roles are held by the same domain controller. This guarantees that the SIDs will be sequential and unique. However, in the Windows 2000 native domain functional level, any domain controller can create security principals. In this type of domain, the RIDs may not be in sequence, but must still be unique. For this reason, only one domain controller can perform the role of the RID Master per domain. The RID Master ensures the uniqueness of the SID by assigning sections of the RID list to the domain controllers when they request it.

You can transfer the RID Master role to another domain controller through the Active Directory Users and Computers snap-in.

4.3.3.5: Infrastructure Master

The domain controller assigned the Infrastructure Master role is responsible for managing group and user references. When you add a user to a group, the user's distinguished name is added to the Member attribute for the group. The User object has a corresponding MemberOf attribute that contains the distinguished names of the groups to which the user belongs. These two attributes are examples of linked attributes. In linked attributes, the primary attribute is termed a forward link and the other attribute is a back-link. Only the forward link can be modified directly. The back-link is calculated. Thus, when a forward link is changed, such as when a new user is added to a group, the user's distinguished name is replicated to all domain controllers hosting a replica of the affected naming context. When a domain controller applies the update, it recalculates the back-link attribute for the affected user object. If the user's distinguished name changes, the system must update all the group objects that have the user as a member as quickly as possible. Updates to the Member attribute for group objects in the same domain as the user with the changed name occur immediately because the domain controller holds both the user object and the group object. But when a user is a member of a group in another domain, a domain controller in the remote domain must be informed about the name change so it can change the Member attribute for any affected groups in that domain. Updates to the remote domain are made by the Infrastructure Master domain controller via multimaster replication. You can transfer the Infrastructure Master role to another domain controller through the Active Directory Users and Computers snap-in.

Except in single-domain controller environments, and an environment where every domain controller retains a copy of the GC, the GC should not be hosted on the Infrastructure Master. The Infrastructure Master compares its data with the GC, therefore may be significant replication impacts and full replication may fail.

4.3.3.6: Domain Naming Master

Active Directory stores pointers to other domains in a special CrossRef object located in a Partitions container in the Configuration naming context. This object contains attributes that describe the distinguished name, DNS name, the flat name, and the name of the Domain naming context along with the kind of trust relationship that binds the domain to the forest. When you create a new domain in an existing forest, the new domain represents a separate naming context and necessitates the creation of a CrossRef object in a Partitions container. Only one domain controller in a forest, the Domain Naming Master, can make changes to the Partitions container. This ensures that two administrators cannot create new domains with identical names during the same replication interval. By default, the Domain Naming Master is the first domain controller in a forest. You can transfer this role to any domain controller in any domain through the Active Directory Domains and Trusts snap-in. However, it recommended that this domain controller reside in the root domain.

4.3.3.7: Schema Master

The schema is a framework of definitions that establishes the type of objects available to Active Directory. The objects in the schema thus define the very structure and identity of Active Directory for a forest. Objects can only be added, modified, or removed from the schema under strictly controlled circumstances. Only one domain controller in the entire forest can update the schema, which is then replicated to other domain controllers in the forest, and that is the Schema Master. The Schema Master role can be transferred to another domain controller through the Active Directory Schema Master snap-in.

4.3.3.8: Seizing a Role Master

If the domain controller hosting a FSMO role master crashes and cannot be recovered, you cannot use the management consoles to transfer roles. As the original role master must be online for the role transfer to be successful. Instead, you must seize the role using the Ntdsutii utility. Once a role master has been seized, you must not reintroduce the original role master back onto the network. This prevents the original role master from passing invalid information or providing a second means of updating controlled structures, such as the Schema or Partition container. The exception is the PDC Emulator. When you bring the original PDC Emulator back online, it will obtain the name of the new PDC Emulator via replication and will cease to function as the PDC Emulator. However, the RID Master is usually placed on the same domain controller as the PDC Emulator. You should not bring the original RID Master back online as this can result in two objects having the same RID, which can cause security problems as well as database consistency errors. Thus, if the RID Master and PDC Emulator are on the same domain controller, you must not reintroduce the original role master back onto the network.

To seizing a FSMO role, do the following:

4.3.4: Renaming Domain Controllers

In a Windows Server 2003 domain, you may rename a Windows Server 2003 domain controller, i.e., change its fully qualified domain name (FQDN) and its NetBIOS name if the domain has been raised to the Windows Server 2003 domain functional level. The rename operation does not change the domain membership of the controller and, thus, does not allow you to move a domain controller to another domain. To move a domain controller to another domain, you must use DCPromo.exe to first demote the domain controller and then uses DCPromo.exe to promote the domain controller with a new domain name.

To rename a domain controller, do the following:

You can also rename a domain controller by using the Netdom command-line utility. The Netdom commandline utility allows you to rename a domain controller by using and alternative name or by replacing the primary name. To rename a domain controller by using an alternative name, you must first rename the domain controller, make the new name the primary name for the domain controller, remove the old name, and then verify that the domain controller has only one name. To perform all four of these functions, you can use the Netdom command with the computername switch. To change the name, specify the old name and the new name. The syntax for this is:

The syntax required to make the new name the primary name for the server is:

The syntax required to remove the old name is:

The syntax required to verify that the domain controller has only one name is:

You must use the renamecomputer switch with the netdom command to rename a domain controller by replacing its primary name. The syntax for this is: