Understanding the Directory Structure

Active Directory has many components and is built on many technologies. Directory data is made available to users and computers through data stores and global catalogs. Although most Active Directory tasks affect the data store, global catalogs are equally important. This is because they're used during logon and for information searches. In fact, if the global catalog is unavailable, normal users can't log on to the domain. The only way to change this behavior is to cache universal group membership locally. As you might expect, there are advantages and disadvantages to caching universal group membership, which I'll discuss in a moment.

You access and distribute Active Directory data using directory access protocols and replication. Directory access protocols allow clients to communicate with computers running Active Directory. Replication is necessary to ensure that updates to data are distributed to domain controllers. Although multimaster replication is the primary technique that you use to distribute updates, some data changes can only be handled by individual domain controllers called operations masters . A new feature of Windows Server 2003, called application directory partitions, also changes the way multimaster replication works.

With application directory partitions, enterprise administrators (those belonging to the Enterprise Admins group) can create replication partitions in the domain forest. These partitions are logical structures used to control replication of data within a domain forest. For example, you could create a partition to strictly control the replication of DNS information within a domain. This would prevent other systems in the domain from replicating DNS information.

Application directory partitions can appear as a child of a domain, a child of another application partition, or a new tree in the domain forest. Replicas of the application directory partition can be made available on any Active Directory domain controller running Windows Server 2003, including global catalogs. Although application directory partitions are useful in large domains and forests, they add overhead in terms of planning, administration, and maintenance.

Exploring the Data Store

The data store contains information about objects such as accounts, shared resources, organizational units, and group policies. Another name for the data store is the directory , which refers to Active Directory itself.

Domain controllers store the directory in a file called Ntds.dit. This file's location is set when Active Directory is installed, and it must be on an NTFS file system drive formatted for use with Windows Server 2003. You can also save directory data separately from the main data store. This is true for group policies, scripts, and other types of public information that's stored on the shared system volume (Sysvol).

Because the data store is a container for objects, the term publish is used when you share directory information. For example, you publish information about a printer by sharing the printer over the network. Similarly, you publish information about a folder by sharing the folder over the network.

Domain controllers replicate most changes to the data store in multimaster fashion. As an administrator for a small or medium- sized organization, you'll rarely need to manage replication of the data store. Replication is handled automatically after all, but you can customize it to meet the needs of large organizations or organizations with special requirements.

Not all directory data is replicated. Instead, only public information that falls into one of these three categories is replicated:

• Domain data

  Contains information about objects within a domain. This includes objects for accounts, shared resources, organizational units, and group policies.

• Configuration data

  Describes the directory's topology. This includes a list of all domains, domain trees, and forests, as well as the locations of the domain controllers and global catalog servers.

• Schema data

  Describes all objects and data types that can be stored in the directory. The default schema provided with Windows Server 2003 describes account objects, shared resource objects, and more. You can extend the default schema by defining new objects and attributes or by adding attributes to existing objects.

Exploring Global Catalogs

When universal group membership isn't cached locally, global catalogs enable network logon by providing universal group membership information when a logon process is initiated. Global catalogs also enable directory searches throughout all the domains in a forest. A domain controller designated as a global catalog stores a full replica of all objects in the directory for its host domain and a partial replica for all other domains in the domain forest.

Note

Partial replicas are used because only certain object properties are needed for logon and search operations. Partial replication also means that less information needs to be circulated on the network, which reduces the amount of network traffic.

By default, the first domain controller installed on a domain is designated as the global catalog. So if there's only one domain controller in the domain, the domain controller and the global catalog are the same server. Otherwise, the global catalog is on the domain controller that you've configured as such. You can also add global catalogs to a domain to help improve response time for logon and search requests . The recommended technique is to have one global catalog per site within a domain.

Domain controllers hosting the global catalog should be well connected to domain controllers acting as infrastructure masters. Infrastructure master is one of the five operations master roles that you can assign to a domain controller. In a domain, the infrastructure master is responsible for updating object references. The infrastructure master does this by comparing its data with that of a global catalog. If the infrastructure master finds outdated data, it requests the updated data from a global catalog. The infrastructure master then replicates the changes to the other domain controllers in the domain. For more information on operations master roles, see the section later in this chapter entitled "Understanding Operations Master Roles."

When there's only one domain controller in a domain, you can assign the infrastructure master role and the global catalog to the same domain controller. When there are two or more domain controllers in the domain, however, the global catalog and the infrastructure master must be on separate domain controllers. If they aren't, the infrastructure master won't find data that's out of date and, as a result, will never replicate changes. The only exception is when all domain controllers in the domain host the global catalog. In this case it doesn't matter which domain controller serves as the infrastructure master.

One of the key reasons to configure additional global catalogs in a domain is to ensure that a catalog is available to service logon and directory search requests. Again, if the domain only has one global catalog and the catalog isn't available and there's no local caching of universal group membership, normal users can't log on and you can't search the directory. In this scenario, the only users who can log on to the domain when the global catalog is unavailable are members of the Domain Admins group.

Searches in the global catalog are very efficient. The catalog contains information about objects in all domains in the forest. This allows directory search requests to be resolved in a local domain rather than in a domain in another part of the network. Resolving queries locally reduces the network load and allows for quicker responses in most cases.

Tip

If you notice slow logon or query response times, you might want to configure additional global catalogs. But more global catalogs usually mean more replication data being transferred over the network.

Universal Group Membership Caching

In a large organization it might not be practical to have global catalogs at every office location. Not having global catalogs at every office location presents a problem, however, in the event that a remote office loses connectivity with the main office or a designated branch office where global catalog servers reside: normal users won't be able to log on; only domain admins will be able to log on. The reason for this is that logon requests must be routed over the network to a global catalog server at a different office, and when there's no connectivity, this isn't possible.

As you might expect, there are many ways to resolve this problem. You could make one of the domain controllers at the remote office a global catalog server by following the procedure discussed in the section entitled "Configuring Global Catalogs" in Chapter 7 , "Core Active Directory Administration." The disadvantage is that the designated server or servers will have an additional burden placed on them and might require additional resources. You also have to more carefully manage the up time of the global catalog server.

Another way to resolve this problem is to cache universal group membership locally. Here, any domain controller can resolve logon requests locally without having to go through the global catalog server. This allows for faster logons and makes it much easier to manage server outages: your domain isn't relying on a single server or a group of servers for logons . It also reduces replication traffic. Instead of replicating the entire global catalog periodically over the network, only the universal group membership information in the cache is refreshed. By default, a refresh occurs every eight hours on each domain controller that's caching membership locally.

Universal group membership is site-specific. Remember, a site is a physical directory structure consisting of one or more subnets with a specific IP address range and network mask. The domain controllers running Windows Server 2003 and the global catalog they're contacting must be in the same site. If you have multiple sites, you'll need to configure local caching in each site. Additionally, users in the site must be part of a Windows Server 2003 domain running in Windows Server 2003 forest functional mode. To learn how to configure caching, see the section of Chapter 7 entitled "Configuring Universal Group Membership Caching."

Replication and Active Directory

The three types of information stored in the directory are domain data, schema data, and configuration data.

Domain data is replicated to all domain controllers within a particular domain. Schema and configuration information are replicated to all domains in the domain tree or forest. Additionally, all objects in an individual domain, and a subset of object properties in the domain forest, are replicated to global catalogs.

This means that domain controllers store and replicate schema information for the domain tree or forest, configuration information for all domains in the domain tree or forest, and all directory objects and properties for their respective domains.

Domain controllers hosting a global catalog, however, store and replicate schema information for the forest, configuration information for all domains in the forest, a subset of the properties for all directory objects in the forest that's replicated between servers hosting global catalogs only, and all directory objects and properties for their respective domain.

To get a better understanding of replication, consider the following scenario, where you're installing a new network:

1. You start by installing the first domain controller in domain A. The server is the only domain controller and also hosts the global catalog. No replication occurs because other domain controllers are on the network.

2. You install a second domain controller in domain A. Because there are now two domain controllers, replication begins. To make sure that data is replicated properly, you assign one domain controller as the infrastructure master and the other as the global catalog. The infrastructure master watches for updates to the global catalog and requests updates to changed objects. The two domain controllers also replicate schema and configuration data.

3. You install a third domain controller in domain A. This server isn't a global catalog. The infrastructure master watches for updates to the global catalog, requests updates to changed objects, and then replicates those changes to the third domain controller. The three domain controllers also replicate schema and configuration data.

4. You install a new domain, domain B, and add domain controllers to it. The global catalog hosts in domain A and domain B begin replicating all schema and configuration data, as well as a subset of the domain data in each domain. Replication within domain A continues as previously described. Replication within domain B begins.

Active Directory and LDAP

The Lightweight Directory Access Protocol (LDAP) is a standard Internet communications protocol for TCP/IP networks. LDAP is designed specifically for accessing directory services with the least amount of overhead. LDAP also defines operations that can be used to query and modify directory information.

Active Directory clients use LDAP to communicate with computers running Active Directory whenever they log on to the network or search for shared resources. You can also use LDAP to manage Active Directory.

LDAP is an open standard that many other directory services can use. This makes interdirectory communications easier and provides a clearer migration path from other directory services to Active Directory. You can also use Active Directory Service Interface (ADSI) to enhance interoperability. ADSI supports the standard application programming interfaces (APIs) for LDAP that are specified in Internet standard Request For Comments (RFC) 1823. You can use ADSI with Windows Script Host to script objects in Active Directory.

Understanding Operations Master Roles

Operations master roles accomplish tasks that are impractical to perform in multimaster fashion. Five different operations master roles are defined; you can assign them to one or more domain controllers. Although certain roles can be assigned only once in a domain forest, other roles must be defined once in each domain.

Every Active Directory forest must have the following roles:

• Schema master

  Controls updates and modifications to directory schema. To update directory schema, you must have access to the schema master. To determine which server is the current schema master for the domain, start a command prompt and type dsquery server -hasfsmo schema .

• Domain naming master

  Controls the addition or removal of domains in the forest. To add or remove domains, you must have access to the domain naming master. To determine which server is the current domain naming master for the domain, start a command prompt and type dsquery server -hasfsmo name .

These forest-wide roles must be unique in the forest. This means you can assign only one schema master and domain naming master in a forest.

Every Active Directory domain must have the following roles:

• Relative ID master

  Allocates relative IDs to domain controllers. Whenever you create a user , group, or computer object, domain controllers assign a unique security ID to the related object. The security ID consists of the domain's security ID prefix and a unique relative ID, which was allocated by the relative ID master. To determine which server is the current relative ID master for the domain, start a command prompt and type dsquery server -hasfsmo rid .

• PDC emulator

  When using mixed or interim mode operations, the PDC emulator acts as a Windows NT PDC. Its job is to authenticate Windows NT logons, process password changes, and replicate updates to the BDCs. To determine which server is the current PDC emulator master for the domain, start a command prompt and type dsquery server -hasfsmo pdc .

• Infrastructure master

  Updates object references by comparing its directory data with that of a global catalog. If the data is outdated, the infrastructure master requests the updated data from a global catalog and then replicates the changes to the other domain controllers in the domain. To determine which server is the current infrastructure operations master for the domain, start a command prompt and type dsquery server -hasfsmo infr .

These domain-wide roles must be unique in each domain. This means you can assign only one relative ID master, PDC emulator, and infrastructure master in each domain.

Operations master roles are assigned automatically in most cases, but you can reassign them. When you install a new network, the first domain controller in the first domain is assigned all the operations master roles. If you later create a new child domain or a root domain in a new tree, the first domain controller in the new domain is automatically assigned operations master roles as well. In a new domain forest, the domain controller is assigned all operations master roles. If the new domain is in the same forest, the assigned roles are relative ID master, PDC emulator, and infrastructure master. The schema master and domain naming master roles remain in the first domain in the forest.

When a domain has only one domain controller, that computer handles all the operations master roles. If you're working with a single site, the default operations master locations should be sufficient. As you add domain controllers and domains, however, you'll probably want to move the operations master roles to other domain controllers.

When a domain has two or more domain controllers, you should configure two domain controllers to handle operations master roles. Here, you would make one domain controller the operations master and the second the standby operations master. The standby operations master is then used if the primary fails. Be sure that the domain controllers are direct replication partners and are well connected.

As the domain structure grows, you might want to split up the operations master roles and place them on separate domain controllers. This can improve the responsiveness of the operations masters. Pay particular attention to the current responsibilities of the domain controller you plan to use.

Best Practices

Two roles that shouldn't be separated are schema master and domain naming master. Always assign these roles to the same server. For the most efficient operations, you'll usually want the relative ID master and PDC emulator to be on the same server as well. But you can separate these roles if necessary. For example, on a large network where peak loads are causing performance problems, you would probably want to place the relative ID master and PDC emulator on separate domain controllers. Additionally, you usually shouldn't place the infrastructure master on a domain controller hosting a global catalog. See the "Exploring Global Catalogs" section of this chapter for details.