Working with Active Directory Domains

  • Article

Although you must configure both Active Directory and DNS on a Windows Server 2008 network, Active Directory domains and DNS domains have different purposes. Active Directory domains help you manage accounts, resources, and security. DNS domains establish a domain hierarchy primarily used for name resolution. Windows Server 2008 uses DNS to map host names, such as zeta.microsoft.com, to numeric TCP/IP addresses, such as 172.16.18.8. To learn more about DNS and DNS domains, see Chapter 20.

Using Windows 2000 and Later Computers with Active Directory

User computers running professional or business editions of Windows 2000, Windows XP, and Windows Vista can make full use of Active Directory. These com-puters access the network as Active Directory clients and have full use of Active Directory features. As clients, these systems can use transitive trust relationships that exist within the domain tree or forest. A transitive trust is one that isn't established explicitly. Rather, the trust is established automatically based on the forest structure and permissions set in the forest. These relationships allow authorized users to access resources in any domain in the forest.

Server computers running Windows 2000 Server, Windows Server 2003, and Windows Server 2008 provide services to other systems and can act as domain controllers or member servers. A domain controller is distinguished from a member server because it runs Active Directory Domain Services. You promote member servers to domain controllers by installing Active Directory Domain Services. You demote domain controllers to member servers by uninstalling Active Directory Domain Services. You use the Add Role and Remove Role Wizards to add or remove Active Directory Domain Services. You promote or demote a server through the Active Directory Installation Wizard (dcpromo.exe).

Domains can have one or more domain controllers. When there are multiple domain controllers, the controllers automatically replicate directory data with one another using a multimaster replication model. This model allows any domain controller to process directory changes and then replicate those changes to other domain controllers.

Because of the multimaster domain structure, all domain controllers have equal responsibility by default. You can, however, give some domain controllers precedence over others for certain tasks, such as specifying a bridgehead server that has priority in replicating directory information to other sites. In addition, some tasks are best performed by a single server. A server that handles this type of task is called an operations master. There are five flexible single master operations (FSMO) roles, and you can assign each to a different domain controller. For more information, see "Understanding Operations Master Roles" on page 212.

All Windows 2000, Windows XP Professional, Windows Vista, Windows Server 2003, and Windows Server 2008 computers that join a domain have computer accounts. Like other resources, computer accounts are stored in Active Directory as objects. You use computer accounts to control access to the network and its resources. A computer accesses a domain using its account, which is authenticated before the computer can access the network.

Real World Domain controllers use Active Directory's global catalog to authenticate both computer and user logons. If the global catalog is unavailable, only members of the Domain Admins group can log on to the domain. This is because the universal group membership information is stored in the global catalog and this information is required for authentication. In Windows Server 2003 and Windows Server 2008, you have the option of caching universal group membership locally, which solves this problem. For more information, see "Understanding the Directory Structure" on page 207.

Working with Domain Functional Levels

All Windows NT, Windows 2000, Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008 computers must have computer accounts before they can join a domain. To support domain structures, Active Directory includes support for several domain functional levels, including:

  • Windows 2000 mixed mode This mode is not recommended for use with Windows Server 2008. You will not be able to use domain controllers running Windows Server 2008, and computers running Windows Server 2008 may have issues when working with domain controllers running Windows NT. Domains operating in this mode can't use many of the latest Active Directory features, including universal groups, group nesting, group type conversion, easy domain controller renaming, update logon timestamps, and Kerberos key distribution center (KDC) key version numbers.
  • Windows 2000 native mode When the domain is operating in Windows 2000 native mode, the directory supports domain controllers running Windows Server 2008, Windows Server 2003, and Windows 2000. Windows NT domain controllers are no longer supported. Domains operating in this mode aren't able to use easy domain controller renaming, update logon timestamps, and Kerberos KDC key version numbers.
  • Windows Server 2003 mode When the domain is operating in Windows Server 2003 mode, the directory supports domain controllers running Windows Server 2008 and Windows Server 2003. Windows NT and Windows 2000 domain controllers are no longer supported. A domain operating in Windows Server 2003 mode can use many Active Directory feature enhancements, including universal groups, group nesting, group type conversion, easy domain controller renaming, update logon timestamps, and Kerberos KDC key version numbers.
  • Windows Server 2008 mode When the domain is operating in Windows Server 2008 mode, the directory supports only Windows Server 2008 domain controllers. Windows NT, Windows 2000, and Windows Server 2003 domain controllers are no longer supported. The good news, however, is that a domain operating in Windows Server 2003 mode can use all the latest Active Directory feature enhancements, including the DFS Replication service for enhanced intersite and intrasite replication.

Using Windows 2000 Native-Mode Operations

After you upgrade the PDC, BDCs, and other Windows NT systems—and if you still have Windows 2000 domain resources—you can change to the Windows 2000 native-mode operations and then use only Windows 2000, Windows Server 2003, and Windows Server 2008 resources in the domain. Once you set the Windows 2000 native-mode operations, however, you can't go back to mixed mode. Because of this, you should use native-mode operations only when you're certain that you don't need the old Windows NT domain structure or Windows NT BDCs.

When you change to Windows 2000 native mode, you'll notice the following:

  • Kerberos v5 becomes the preferred authentication mechanism and NTLM authentication is no longer used.
  • The PDC emulator can no longer synchronize data with any existing Windows NT BDCs.
  • You can't add any Windows NT domain controllers to the domain.

You switch from Windows 2000 mixed-mode to Windows 2000 native-mode operations by raising the domain functional level.

Using Windows Server 2003 Mode Operations

After you've upgraded the Windows NT structures in your organization, you can begin upgrading to Windows Server 2003 domain structures. You do this by upgrading Windows 2000 domain controllers to Windows Server 2003 or Windows Server 2008 domain controllers and then, if desired, you can change the functional level to Windows Server 2003 mode operations.

Before updating Windows 2000 domain controllers, you should prepare the domain for upgrade. To do this, you'll need to update the forest and the domain schema so that they are compatible with Windows Server 2003 domains. A tool called Adprep.exe is provided to automatically perform the update for you. All you need to do is run the tool on the schema operations master in the forest and then on the infrastructure operations master for each domain in the forest. As always, you should test out any procedure in the lab before performing it in an operational environment. On Windows Server 2003 installation media, you'll find Adprep in the i386 subfolder.

Note To determine which server is the current schema operations master for the domain, open a command prompt and type dsquery server --hasfsmo schema. A directory service path string is returned containing the name of the server, such as: "CN=CORPSERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites, CN=Configuration,DC=microsoft,DC=com." This string tells you that the schema operations master is COPRSERVER01 in the microsoft.com domain.

Note To determine which server is the current infrastructure operations master for the domain, start a command prompt and type dsquery server -hasfsmo infr.

After upgrading your servers, you can raise the domain and forest level functionality to take advantage of the latest Active Directory features. If you do this, however, you can use only Windows Server 2003 and Windows Server 2008 resources in the domain and you can't go back to any other mode. Therefore, you should use Windows Server 2003 mode only when you're certain that you don't need old Windows NT domain structures, Windows NT BDCs, or Windows 2000 domain structures.

Using Windows Server 2008 Mode Operations

After you've upgraded the Windows NT and Windows 2000 structures in your organization, you can begin upgrading to Windows Server 2008 domain structures. You do this by upgrading Windows Server 2003 domain controllers to Windows Server 2008 domain controllers and then, if desired, you can change the functional level to Windows Server 2008 mode operations.

Before updating Windows Server 2003 domain controllers, you should prepare the domain for Windows Server 2008. To do this, you'll need to use Adprep.exe to update the forest and the domain schema so that they are compatible with Windows Server 2008 domains:

  1. On the schema operations master in the forest, copy the contents of the Sources\Adprep folder from the Windows Server 20008 installation media to a local folder and then run run adprep /forestprep. If you plan to install any --read only domain controllers, you should also run adprep /rodcprep. You'll need to use an administrator account that is a member of Enterprise Admins, Schema Admins, or Domain Admins in the forest root domain.
  2. On the infrastructure operations master for each domain in the forest, copy the contents of the Sources\Adprep folder from the Windows Server 20008 installation media to a local folder and then run run adprep /domainprep /gpprep. You'll need to use an account that is a member of the Domain Admins group in an applicable domain.

As always, you should test out any procedure in the lab before performing it in an operational environment.

Note To determine which server is the current schema operations master for the domain, start a command prompt and type dsquery server -hasfsmo schema. To determine which server is the current infrastructure operations master for the domain, start a command prompt and type dsquery server -hasfsmo infr.

After upgrading all domain controllers to Windows Server 2008, you can raise the domain and forest level functionality to take advantage of the latest Active Directory features. If you do this, however, you can use only Windows Server 2008 resources in the domain and you can't go back to any other mode. Because of this, you should use Windows Server 2008 mode only when you're certain that you don't need old Windows NT domain structures, Windows NT BDCs, Windows 2000, or Windows Server 2003 domain structures.

Raising Domain and Forest Functionality

Domains operating in Windows Server 2003 or higher functional level can use many enhancements for Active Directory domains, including universal groups, group nesting, group type conversion, update logon timestamps, and Kerberos KDC key version numbers. In this mode administrators will also be able to do the following:

  • Rename domain controllers without having to demote them first
  • Rename domains running on Windows Server 2008 domain controllers
  • Create extended two-way trusts between two forests
  • Restructure domains in the domain hierarchy by renaming them and putting them at different levels
  • Take advantage of replication enhancements for individual group members and global catalogs

Forests operating in Windows Server 2003 or higher functional level can use the many enhancements for Active Directory forests, which means improved global catalog replication and intrasite and intersite replication efficiency, as well as the ability to establish one-way, two-way, and transitive forest trusts.

Real World The domain and forest upgrade process can generate a lot of network traffic as information is being replicated around the network. Sometimes the entire upgrade process can take 15 minutes or longer to complete. During this time you might experience delayed responsiveness when communicating with servers and higher latency on the network. You therefore might want to schedule the upgrade outside of normal business hours. It's also a good idea to thoroughly test compatibility with existing applications (especially legacy applications) before performing this operation.

You can raise the domain level functionality by following these steps:

  1. Click Start, choose Administrative Tools, and then select Active Directory Domains And Trusts.
  2. Right-click the domain you want to work within the console tree and then select Raise Domain Functional Level.
  3. The current domain name and functional level are displayed in the Raise Domain Functional Level dialog box.
  4. To change the domain functionality, select the new domain functional level from the selection list provided and then click Raise. However, you can't reverse this action. Consider the implications carefully before you do this.
  5. When you click OK, the new domain functional level will be replicated to each domain controller in the domain. This operation can take some time in a large organization.

You can raise the forest level functionality by following these steps:

  1. Click Start, choose Administrative Tools, and then select Active Directory Domains And Trusts.
  2. Right-click the Active Directory Domains And Trusts node in the console tree and then select Raise Forest Functional Level.
  3. The current forest name and functional level are displayed in the Raise Forest Functional Level dialog box.
  4. To change the forest functionality, select the new forest functional level using the selection list provided and then click Raise. However, you can't reverse this action. Consider the implications carefully before you do this.
  5. When you click OK, the new forest functional level will be replicated to each domain controller in each domain in the forest. This operation can take some time in a large organization.

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 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, caching universal group membership has advantages and disadvantages, 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 be handled only by individual domain controllers called operations masters. A new feature of Windows Server 2008 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, thereby preventing other systems in the domain from replicating DNS information.

An application directory partition 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 2008, 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 2008. 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 stored on the shared system volume (Sysvol).

Because the data store is a container for objects, sharing directory information is called publishing. 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, 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 the following three categories is replicated:

  • Domain dataContains information about objects within a domain. This includes objects for accounts, shared resources, organizational units, and group policies.
  • Configuration dataDescribes 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 dataDescribes all objects and data types that can be stored in the directory. The default schema provided with Windows Server 2008 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, reducing the amount of network traffic.

By default, the first domain controller installed on a domain is designated as the global catalog. So if only one domain controller is 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. The role of 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 "Understanding Operations Master Roles" on page 212.

When only one domain controller is in a domain, you can assign the infrastructure master role and the global catalog to the same domain controller. When two or more domain controllers are 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 out-of-date data 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 has only 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, if 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. This is because logon requests must be routed over the network to a global catalog server at a different office; with no connectivity, this isn't possible.

As you might expect, you can resolve this problem in many ways. You could make one of the domain controllers at the remote office a global catalog server by following the procedure discussed in "Configuring Global Catalogs" on page 235. 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 managing server outages much easier: your domain isn't relying on a single server or a group of servers for logons. This solution 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 2008 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 2008 domain running in Windows Server 2008 forest functional mode. To learn how to configure caching, see "Configuring Universal Group Membership Caching" on page 236.

Replication and Active Directory

Regardless of whether you use FRS or DFS replication, 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 data are replicated to all domains in the domain tree or forest. In addition, 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 the following:

  • Schema information for the domain tree or forest
  • Configuration information for all domains in the domain tree or forest
  • 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, in which you're installing a new network:

  1. 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. 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, 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. 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. 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 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 one 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 you use 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, one PDC emulator, and one infrastructure master in each domain.

Operations master roles are usually assigned automatically, 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 you should not separate 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 "Exploring Global Catalogs" on page 209 for details.

< Back     

 

 

© Microsoft. All Rights Reserved.