Using Active Directory - Windows Server 2012 R2 Essentials & Configuration (2014)

Windows Server 2012 R2 Essentials & Configuration (2014)

Chapter 7. Using Active Directory

§ Introducing Active Directory

§ Working with domain structures

§ Working with Active Directory domains

§ Understanding the directory structure

§ Using the Active Directory Recycle Bin

Active Directory Domain Services (AD DS) is an extensible and scalable directory service you can use to efficiently manage network resources. As an administrator, you need to be deeply familiar with how Active Directory technology works, and that’s exactly what this chapter is about. If you haven’t worked with Active Directory technology before, you’ll notice immediately that the technology is fairly advanced and has many features.

Introducing Active Directory

For many years now, Active Directory has been the heart of Windows-based domains. Just about every administrative task you perform affects Active Directory in some way. Active Directory technology is based on standard Internet protocols and is designed to help you clearly define your network’s structure.

Active Directory and DNS

Active Directory uses Domain Name System (DNS). DNS is a standard Internet service that organizes groups of computers into domains. DNS domains are organized into a hierarchical structure. The DNS domain hierarchy is defined on an Internet-wide basis, and the different levels within the hierarchy identify computers, organizational domains, and top-level domains. DNS is also used to map host names to numeric TCP/IP addresses. Through DNS, an Active Directory domain hierarchy can also be defined on an Internet-wide basis, or the domain hierarchy can be separate from the Internet and private.

When you refer to computer resources in a DNS domain, you use a fully qualified domain name (FQDN), such as zeta.microsoft.com. Here, zeta represents the name of an individual computer, microsoft represents the organizational domain, and com is the top-level domain. Top-level domains (TLDs) are at the base of the DNS hierarchy. TLDs are organized geographically by using two-letter country codes, such as CA for Canada; by organization type, such as com for commercial organizations; and by function, such as mil for US military installations.

Normal domains, such as microsoft.com, are also referred to as parent domains because they’re the parents of an organizational structure. You can divide parent domains into subdomains, which you can then use for different offices, divisions, or geographic locations. For example, the FQDN for a computer at the Seattle office for Microsoft could be designated as jacob.seattle.microsoft.com. Here, jacob is the computer name, seattle is the subdomain, and microsoft.com is the parent domain. Another term for a subdomain is a child domain.

DNS is an integral part of Active Directory technology—so much so that you must configure DNS on the network before you can install Active Directory. With Windows Server 2012 R2, you install Active Directory in a two-part process. First, you start the process in Server Manager by tapping or clicking Manage and then clicking Add Roles And Features. This runs the Add Roles And Features Wizard, which you use to specify that you want to add the AD DS role to the server. The wizard installs binaries needed for the role, and the progress of this process is shown on the Installation Progress page.

REAL WORLD

Binaries needed to install roles and features are referred to as payloads. With Windows Server 2012 R2, not only can you uninstall a role or feature, but you also can uninstall and remove the payload for that feature or role by using the –Remove parameter of the Uninstall-WindowsFeature cmdlet.

You can restore a removed payload by using the Install-WindowsFeature cmdlet. By default, payloads are restored via Windows Update. Use the –Source parameter to restore a payload from a WIM mount point. In the following example, you restore the AD DS binaries and all related subfeatures via Windows Update:

install-windowsfeature -name ad-domain-services

-includeallsubfeature

When the installation completes, you start the Active Directory Domain Services Configuration Wizard by tapping or clicking the Promote This Server To A Domain Controller link on the Installation Progress page, and then you use this wizard to configure the role. This wizard replaces Dcpromo.exe, which was used previously for promoting domain controllers. The wizard also will run Adprep.exe to prepare schema as appropriate. If you have not run Adprep.exe separately previously, and you are installing the first domain controller that runs Windows Server 2012 R2 in an existing domain or forest, the wizard will prompt you to supply credentials to run Adprep commands. To prepare a forest, you need to provide credentials for a member of the Enterprise Admins group, the Schema Admins group, and the Domain Admins group in the domain that hosts the schema master. To prepare a domain, you need to provide credentials for a member of the Domain Admins group. If you are installing the first read-only domain controller (RODC) in a forest, you need to provide credentials for a member of the Enterprise Admins group.

If DNS isn’t already installed, you are prompted to install it. If no domain exists, the wizard helps you create a domain and configure Active Directory in the new domain. The wizard can also help you add child domains to existing domain structures. To verify that a domain controller is installed correctly, do the following:

§ Check the Directory Service event log for errors.

§ Ensure that the SYSVOL folder is accessible to clients.

§ Verify that name resolution is working through DNS.

§ Verify the replication of changes to Active Directory.

NOTE

In the rest of this chapter, I’ll use the terms directory and domains to refer to Active Directory and Active Directory domains, respectively, except when I need to distinguish Active Directory structures from DNS or other types of directories.

Keep in mind that when you use Server Manager for Windows Server 2012 R2 and the forest functional level is Windows Server 2003 or higher, any necessary preparations are done automatically when you deploy a domain controller. This means the Configuration Wizard automatically updates the Active Directory schema for the forest and domain so that the schema is compatible with Windows Server 2012 R2 as necessary.

Read-only domain controller deployment

When the domain and forest are operating at the Windows Server 2003 functional level or higher, and your primary domain controller (PDC) emulator for a domain is running Windows Server 2008 or later, you can deploy read-only domain controllers (RODCs). Any domain controller running Windows Server 2008 R2 or later can be configured as an RODC. When you install the DNS Server service on an RODC, the RODC can act as a read-only DNS (RODNS) server. In this configuration, the following conditions are true:

§ The RODC replicates the application directory partitions that DNS uses, including the ForestDNSZones and DomainDNSZones partitions. Clients can query an RODNS server for name resolution. However, the RODNS server does not support client updates directly, because the RODNS server does not register resource records for any Active Directory–integrated zone that it hosts.

§ When a client attempts to update its DNS records, the server returns a referral. The client can then attempt to update against the DNS server that is provided in the referral. Through replication in the background, the RODNS server then attempts to retrieve the updated record from the DNS server that made the update. This replication request is only for the changed DNS record. The entire list of data changed in the zone or domain is not replicated during this special request.

The first Windows Server 2008 R2 or later domain controller installed in a forest or domain cannot be an RODC. However, you can configure subsequent domain controllers as read-only.

MORE INFO

The domain and forest must have the correct schema level to support RODCs and must also be prepared to work with RODCs. Previously, in some cases, this required that you prepare the forest and domain schemas for Windows Server and then update the forest schema again for RODCs. When you use Server Manager for Windows Server 2012 R2, and the Windows Server 2003 or higher forest functional level, any necessary preparations are done automatically as part of domain controller (DC) and RODC deployment.

Features introduced with Windows Server 2008 R2

When you are using Windows Server 2008 R2 and later in your enterprise and have deployed these operating systems on all domain controllers throughout the domains in your Active Directory forest, your domains can operate at the Windows Server 2008 R2 or higher domain functional level, and the forest can operate at the Windows Server 2008 R2 or higher forest functional level. These operating levels allow you to take advantage of the many Active Directory enhancements that improve manageability, performance, and supportability, including the following:

§ Active Directory Recycle Bin. Allows administrators to undo the accidental deletion of Active Directory objects in much the same way as they can recover deleted files from the Windows Recycle Bin. For more information, see the “Using the Active Directory Recycle Bin” section later in this chapter.

§ Managed service accounts. Introduces a special type of domain user account for managed services that reduces service outages and other issues by having Windows manage the account password and related service principal names (SPNs) automatically. For more information, see the “Implementing managed accounts” section in Chapter 9

§ Managed virtual accounts. Introduces a special type of local computer account for managed services that provides the ability to access the network by using a computer identity in a domain environment. For more information, see the “Using virtual accounts” section in Chapter 9.

REAL WORLD

Technically, you can use managed service accounts and managed virtual accounts in a mixed-mode domain environment. However, you have to manually manage SPNs for managed service accounts, and the Active Directory schema must be compatible with Windows Server 2008 R2 and higher.

§ Authentication Mechanism Assurance. Improves the authentication process by allowing administrators to control resource access based on whether a user logs on by using a certificate-based logon method. Thus, an administrator can specify that a user has one set of access permissions when logged on by using a smart card and a different set of access permissions when not logged on by using a smart card.

Other improvements don’t require that you raise domain or forest functional levels, but they do require that you use Windows Server 2008 or later. These improvements include the following:

§ Offline domain join. Allows administrators to preprovision computer accounts in the domain to prepare operating systems for deployment. This allows computers to join a domain without having to contact a domain controller.

§ Active Directory module for Windows PowerShell. Provides cmdlets for managing Active Directory when you are working with Windows PowerShell.

§ Active Directory Administrative Center. Provides a task-orientated interface for managing Active Directory. In Server Manager, tap or click Tools, and then tap or click Active Directory Administrative Center.

§ Active Directory Web Services. Introduces a web service interface for Active Directory domains.

These features are discussed in more detail in Chapter 8

Features introduced with Windows Server 2012

Active Directory Domain Service in Windows Server 2012 has many additional features that give administrators more options for implementing and managing Active Directory. Table 7-1 lists key features. At the least, these features require that you update the Active Directory schema in your forests and domains for Windows Server 2012 or later. You also might need to update the domain, forest, or both functional levels to the Windows Server 2012 or Windows Server 20212 R2 operating level.

Table 7-1. Key Active Directory Features for Windows Server 2012

FEATURE

BENEFITS

REQUIREMENTS

Active Directory–based activation

Allows you to use Active Directory to automatically activate clients running Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. Any client connected to the service is activated.

Volume Licensing; Active Directory schema must be updated for at least Windows Server 2012; key is set using Volume Activation server role or command line.

Authentication policies

Allow you to specify access control conditions that restrict the devices that can request Kerberos tickets for user, service, and computer accounts. Applies only to users, computers, managed services accounts, and group managed service accounts.

Accounts must be members of the Protected Users group. Domain controllers must run Windows Server 2012 R2. Windows Server 2012 R2 domain functional level.

Claims-based policy controls

Allow access and audit policies to be defined flexibly.

Claims policy must be enabled for Default Domain Controllers Policy; file servers must run at least Windows Server 2012; domain must have at least one domain controller running Windows Server 2012 or later.

Deferred index creation

Allows deferring of index creation within the directory until UpdateSchemaNow is received or the domain controller is rebooted.

Domain controller must run at least Windows Server 2012.

Enhanced Fine-Grained Password Policy

Allows administrators to use Active Directory Administrative Center for Windows Server 2012 RTM or R2 to create and manage Password Settings objects (PSOs).

Windows Server 2008 or higher domain functional level.

Enhanced Recycle Bin

Allows administrators to recover deleted objects by using Active Directory Administrative Center for Windows Server 2012 RTM or R2.

Domain must have Recycle Bin enabled and Windows Server 2008 R2 or higher forest functional level.

Group Managed Service Accounts

Allow multiple services to share a single managed service account.

Active Directory schema must be updated for at least Windows Server 2012; must have at least one domain controller running Windows Server 2012 or later; services must run on Windows Server 2012 RTM or R2.

Kerberos constrained delegation across domains

Allows managed service accounts to act on behalf of users across domains and forests.

Each affected domain must have at least one domain controller running Windows Server 2012 RTM or R2; front-end server must run Windows Server 2012 RTM or R2; back-end server must run Windows Server 2003 or later; and other additional requirements.

Kerberos with Armoring

Improves domain security; allows a domain-joined client and domain controller to communicate over a protected channel.

Domain controllers must be running Windows Server 2012 RTM or Windows Server 2012 R2; Windows Server 2012 RTM or R2 domain functional level; on clients, enable Require FAST policy; on domain controllers, enable Support CBAC And Kerberos Armoring policy.

Off-premises domain join

Allows a computer to be domain-joined over the Internet.

Domain must be Direct Access–enabled, and domain controllers must run Windows Server 2012 RTM or R2.

Protected Users security group

Provides additional protections against authentication threats by requiring accounts that are members of this group to use only Kerberos for authentication.

Domain controllers must run Windows Server 2012 R2. Windows Server 2012 R2 domain functional level.

Relative ID (RID) soft ceiling and warnings

Adds warnings as global RID space is used up. Adds a soft ceiling of 900 million RIDs used that prevents RIDs from being issued until administrator overrides.

A domain controller with RID role must run Windows Server 2012 RTM or R2, and domain controllers must run Windows Server 2012 or later.

Server Manager integration

Allows you to perform all the steps required to deploy local and remote domain controllers.

Windows Server 2012 or later; forest functional level of Windows Server 2003 or higher.

Virtual domain controller cloning

Allows you to safely deploy virtualized replicas of domain controllers. Also helps maintain domain controller state.

A domain controller with the PDC emulator role must run Windows Server 2012 or later, and virtual domain controllers must also run Windows Server 2012 or later.

Working with domain structures

Active Directory provides both logical and physical structures for network components. Logical structures help you organize directory objects and manage network accounts and shared resources. Logical structures include the following:

§ Organizational units. A subgroup of domains that often mirrors the organization’s business or functional structure

§ Domains. A group of computers that share a common directory database

§ Domain trees. One or more domains that share a contiguous namespace

§ Domain forests. One or more domain trees that share common directory information

Physical structures serve to facilitate network communication and to set physical boundaries around network resources. Physical structures that help you map the physical network structure include the following:

§ Subnets. A network group with a specific IP address range and network mask.

§ Sites. One or more subnets. Sites are used to configure directory access and replication.

Understanding domains

An Active Directory domain is simply a group of computers that share a common directory database. Active Directory domain names must be unique. For example, you can’t have two microsoft.com domains, but you can have a parent domain microsoft.com, with the child domains seattle.microsoft.com and ny.microsoft.com. If the domain is part of a private network, the name assigned to a new domain must not conflict with any existing domain name on the private network. If the domain is part of the Internet, the name assigned to a new domain must not conflict with any existing domain name throughout the Internet. To ensure uniqueness on the Internet, you must register the parent domain name before using it. You can register a domain through any designated registrar. You can find a current list of designated registrars at InterNIC (www.internic.net).

Each domain has its own security policies and trust relationships with other domains. Domains can also span more than one physical location, which means that a domain can consist of multiple sites and those sites can have multiple subnets, as shown in Figure 7-1. Within a domain’s directory database, you’ll find objects defining accounts for users, groups, computers, and shared resources such as printers and folders.

Diagram of a network, depicting a wide area network that contains multiple sites and subnets.

Figure 7-1. This network diagram depicts a wide area network (WAN) with multiple sites and subnets.

NOTE

User and group accounts are discussed in Chapter 9. Computer accounts and the various types of computers used in Windows Server domains are discussed in the “Working with Active Directory domains” section later in this chapter.

Domain functions are limited and controlled by the domain functional level. Several domain functional levels are available, including the following:

§ Windows Server 2003. Supports domain controllers running Windows Server 2003 and later

§ Windows Server 2008. Supports domain controllers running Windows Server 2008 and later

§ Windows Server 2008 R2. Supports domain controllers running Windows Server 2008 R2 and later

§ Windows Server 2012. Supports domain controllers running Windows Server 2012 and later

§ Windows Server 2012 R2. Supports domain controllers running Windows Server 2012 R2

For further discussion of domain functional levels, see the “Working with domain functional levels” section later in this chapter.

Understanding domain forests and domain trees

Each Active Directory domain has a DNS domain name, such as microsoft.com. One or more domains sharing the same directory data are referred to as a forest. The domain names within this forest can be noncontiguous or contiguous in the DNS naming hierarchy.

When domains have a contiguous naming structure, they’re said to be in the same domain tree. Figure 7-2 shows an example of a domain tree. In this example, the root domain adatum.com has two child domains: seattle.adatumcom and ny.adatum.com. These domains, in turn, have subdomains. All the domains are part of the same tree because they have the same root domain.

Diagram of a domain in the same tree sharing a contiguous naming structure.

Figure 7-2. Domains in the same tree share a contiguous naming structure.

If the domains in a forest have noncontiguous DNS names, they form separate domain trees within the forest. As shown in Figure 7-3, a domain forest can have one or more domain trees. In this example, the adatum.com and microsoft.com domains form the roots of separate domain trees in the same forest.

Diagram of domains forming separate domain trees in a forest with noncontiguous naming structures.

Figure 7-3. Multiple trees in a forest with noncontiguous naming structures.

You can access domain structures by using Active Directory Domains And Trusts, shown in Figure 7-4. Active Directory Domains And Trusts is a snap-in for the Microsoft Management Console (MMC). You can also start it from the Tools menu in Server Manager. You’ll find separate entries for each root domain. In Figure 7-4, the active domain is cpandl.com.

Screen shot of Active Directory Domains And Trusts, showing an entry for a root domain.

Figure 7-4. Use Active Directory Domains And Trusts to work with domains, domain trees, and domain forests.

Forest functions are limited and controlled by the forest functional level. Several forest functional levels are available, including the ones listed here:

§ Windows Server 2003. Supports domain controllers running Windows Server 2003 and later

§ Windows Server 2008. Supports domain controllers running Windows Server 2008 and later

§ Windows Server 2008 R2. Supports domain controllers running Windows Server 2008 R2 and later

§ Windows Server 2012. Supports domain controllers running Windows Server 2012 and later

§ Windows Server 2012 R2. Supports domain controllers running Windows Server 2012 R2

When all domains within a forest are operating in Windows Server 2003 forest functional level, you’ll notice improvements over earlier implementations in global catalog replication and replication efficiency. Because link values are replicated, you might also notice improved intersite replication. You can deactivate schema class objects and attributes; use dynamic auxiliary classes; rename domains; and create one-way, two-way, and transitive forest trusts.

The Windows Server 2008 forest functional level offers incremental improvements over the Windows Server 2003 forest functional level in Active Directory performance and features. When all domains within a forest are operating in this mode, you’ll notice improvements in both intersite and intrasite replication throughout the organization. Domain controllers can also use Distributed File System (DFS) replication rather than file replication service (FRS) replication. In addition, Windows Server 2008 security principals are not created until the PDC emulator operations master in the forest root domain is running Windows Server 2008.

The Windows Server 2008 R2 forest functional level has several additional features. These features include the Active Directory Recycle Bin, managed service accounts, and Authentication Mechanism Assurance.

Although Active Directory for Windows Server 2012 has many enhancements, most of these enhancements require using only Windows Server 2012 domain controllers and schema. The main exception is for Kerberos with Armoring, which requires the Windows Server 2012 domain functional level. Because the key Active Directory enhancements introduced with Windows Server 2012 R2 require the Windows Server 2012 R2 domain functional level, you’ll need to use only Windows Server 2012 R2 domain controllers and schema if you want to take advantage of authentication policies and protected users.

Generally, you cannot lower the forest functional level after you raise it. However, when you raise the forest functional level to Windows Server 2012 or higher, you can lower it. If you are using Windows Server 2012 forest functional level, you can lower it to Windows Server 2008 R2. If you are using Windows Server 2012 R2 forest functional level, you can lower it to Windows Server 2012 or Windows Server 2008 R2. Additionally, with either scenario, if Active Directory Recycle Bin has not been enabled, you can lower the forest functional level to Windows Server 2008. You cannot roll the domain functional level back to Windows Server 2003 or lower.

Understanding organizational units

Organizational units (OUs) are subgroups within domains that often mirror an organization’s functional or business structure. You can also think of OUs as logical containers into which you place accounts, shared resources, and other OUs. For example, you could create OUs named HumanResources, IT, Engineering, and Marketing for the microsoft.com domain. You could later expand this scheme to include child units. Child OUs for Marketing could include OnlineSales, ChannelSales, and PrintSales.

Objects placed in an OU can come only from the parent domain. For example, OUs associated with seattle.microsoft.com can contain objects for this domain only. You can’t add objects from ny.microsoft.com to these containers, but you could create separate OUs to mirror the business structure of seattle.microsoft.com.

OUs are helpful in organizing objects to reflect a business or functional structure. Still, this isn’t the only reason to use OUs. Other reasons include the following:

§ OUs allow you to assign group policies to a small set of resources in a domain without applying the policies to the entire domain. This helps you set and manage group policies at the appropriate level in the enterprise.

§ OUs create smaller, more manageable views of directory objects in a domain. This helps you manage resources more efficiently.

§ OUs allow you to delegate authority and to easily control administrative access to domain resources. This helps you control the scope of administrator privileges in the domain. You could grant user A administrative authority for one OU and not for others. Meanwhile, you could grant user B administrative authority for all OUs in the domain.

OUs are represented as folders in Active Directory Users And Computers, as shown in Figure 7-5. This utility is a snap-in for the MMC, and you can also start it from the Tools menu in Server Manager.

Screen shot of Active Directory Users And Computers, showing users, groups, computers, and organizational units.

Figure 7-5. Use Active Directory Users And Computers to manage users, groups, computers, and organizational units.

Understanding sites and subnets

A site is a group of computers in one or more IP subnets. You use sites to map your network’s physical structure. Site mappings are independent of logical domain structures, so there’s no necessary relationship between a network’s physical structure and its logical domain structure. With Active Directory, you can create multiple sites within a single domain or create a single site that serves multiple domains. The IP address ranges used by a site and the domain namespace also have no connection.

You can think of a subnet as a group of network addresses. Unlike sites, which can have multiple IP address ranges, subnets have a specific IP address range and network mask. Subnet names are shown in the form network/bits-masked, such as 192.168.19.0/24. In this case, the network address 192.168.19.9 and network mask 255.255.255.0 are combined to create the subnet name 192.168.19.0/24.

NOTE

Don’t worry—you don’t need to know how to create a subnet name. In most cases, you enter the network address and the network mask, and then Windows Server generates the subnet name for you.

Computers are assigned to sites based on their location in a subnet or a set of subnets. If computers in subnets can communicate efficiently with one another over the network, they’re said to be well connected. Ideally, sites consist of subnets and computers that are all well connected. If the subnets and computers aren’t well connected, you might need to set up multiple sites. Being well connected gives sites several advantages:

§ When clients log on to a domain, the authentication process first searches for domain controllers that are in the same site as the client. This means that local domain controllers are used first, if possible, which localizes network traffic and can speed up the authentication process.

§ Directory information is replicated more frequently within sites than between sites. This reduces the network traffic load caused by replication while ensuring that local domain controllers get up-to-date information quickly. You can also use site links to customize how directory information is replicated between sites. A domain controller that is designated to perform intersite replication is called a bridgehead server. By designating a bridgehead server to handle replication between sites, you place the bulk of the intersite replication burden on a specific server rather than on any available server in a site.

You access sites and subnets through Active Directory Sites And Services, shown in Figure 7-6. Because this is a snap-in for the MMC, you can add it to any updateable console. You can also open Active Directory Sites And Services from the Tools menu in Server Manager.

A screen shot of Active Directory Sites And Services showing sites and subnets.

Figure 7-6. Use Active Directory Sites And Services to manage sites and subnets.

Working with Active Directory domains

Although you must configure both Active Directory and DNS on a Windows Server 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 that is primarily used for name resolution. Windows Server uses DNS to map host names, such as zeta.microsoft.com, to numeric TCP/IP addresses, such as 172.16.18.8.

Using computers with Active Directory

User computers running professional or business editions of Windows can make full use of Active Directory. These computers 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 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 Features and Remove Role And Features 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 a domain has multiple domain controllers, the controllers automatically replicate directory data with one another by 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 the “Understanding operations master roles” section later in this chapter.

Every Windows-based computer that joins a domain has a computer account. 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 by 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 because the universal group membership information is stored in the global catalog, and this information is required for authentication. In Windows Server 2003 and later servers, you have the option of caching universal group membership locally, which solves this problem. For more information, see the “Understanding the directory structure” section later in this chapter.

Working with domain functional levels

To support domain structures, Active Directory includes support for the following domain functional levels:

§ Windows Server 2003 mode. When the domain is operating in Windows Server 2003 mode, the directory supports domain controllers running Windows Server 2003 or later. A domain operating in Windows Server 2003 mode can use universal groups, group nesting, group type conversion, easy domain controller renaming, update logon time stamps, and Kerberos KDC key version numbers.

§ Windows Server 2008 mode. When the domain is operating in Windows Server 2008 mode, the directory supports domain controllers running Windows Server 2008 or later. Domain controllers running Windows Server 2003 are no longer supported. A domain operating in Windows Server 2008 mode can use additional Active Directory features, including the DFS replication service for enhanced intersite and intrasite replication.

§ Windows Server 2008 R2 mode. When the domain is operating in Windows Server 2008 R2 mode, the directory supports domain controllers running Windows Server 2008 R2 or later. Domain controllers running Windows Server 2003 and Windows Server 2008 are no longer supported. A domain operating in Windows Server 2008 R2 mode can use Active Directory Recycle Bin, managed service accounts, Authentication Mechanism Assurance, and other important Active Directory enhancements.

§ Windows Server 2012 mode. When the domain is operating in Windows Server 2012 mode, the directory supports domain controllers running Windows Server 2012 or later. Domain controllers running Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 are no longer supported. Active Directory schema for Windows Server 2012 includes many enhancements, but only the Kerberos with Armoring feature requires this mode.

§ Windows Server 2012 R2 mode. When the domain is operating in Windows Server 2012 R2 mode, the directory supports domain controllers running Windows Server 2012 R2. Domain controllers running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 are no longer supported. Active Directory schema for Windows Server 2012 R2 includes enhancements, but only authenti-cation policies and protected users require this mode.

Generally, you cannot lower the domain functional level after you raise it. However, when you raise the domain functional level to Windows Server 2008 R2 or higher, and the forest functional level is Windows Server 2008 or lower, you have the option of rolling the domain functional level back to Windows Server 2008 or Windows Server 2008 R2. You cannot roll the domain functional level back to Windows Server 2003 or lower.

Using the Windows Server 2003 functional level

Every domain in your enterprise should be operating at the Windows Server 2003 functional level or higher, if possible, which will ensure computers in your domains can take advantage of many of the most recent enhancements to Active Directory. After you decommission Windows NT structures and upgrade the Windows 2000 structures in your organization, 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 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 any procedure in a lab before performing it in a production environment.

On the Windows Server 2003 installation media, you’ll find Adprep and related files in the i386 subfolder. Follow these steps to perform the upgrade:

1. On the schema operations master in the forest, run <cdrom>:\support\adprep\adprep.exe /forestprep. You 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, run <cdrom>:\support\adprep\adprep.exe /domainprep. You need to use an account that is a member of the Domain Admins group in an applicable domain.

NOTE

To determine which server is the current schema operations master for the domain, open a command prompt and enter 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 CORPSERVER01 in the microsoft.com domain.

NOTE

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

REAL WORLD

Generally, anything you can enter at a command prompt can be entered at the Windows PowerShell prompt, too. This is possible because Windows PowerShell looks for external commands and utilities as part of its normal processing. As long as the external command or utility is found in a directory specified by the PATH environment variable, the command or utility is run as appropriate. However, keep in mind that the Windows PowerShell execution order could affect whether a command runs as expected. For Windows PowerShell, the execution order is 1) alternate built-in or profile-defined aliases, 2) built-in or profile-defined functions, 3) cmdlets or language keywords, 4) scripts with the .ps1 extension, and 5) external commands, utilities, and files. Thus, if any element in steps 1 through 4 of the execution order has the same name as a command, that element will run instead of the expected command.

After upgrading your servers, you can raise the domain and forest functionality to take advantage of the additional Active Directory features of the Windows Server 2003 functional level. Keep in mind that after you upgrade, you can use only Windows Server 2003 and later resources in the domain, and you can’t go back to any other mode. You should use Windows Server 2003 mode only when you’re certain that you don’t need Windows NT domain structures, backup domain controllers (BDCs) running Windows NT, or Windows 2000 domain structures.

Using the Windows Server 2008 functional level

After you upgrade the Windows 2000 and Windows Server 2003 structures in your organization, 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 need to use Adprep.exe to update the forest and the domain schema so that they are compatible with Windows Server 2008 domains. Follow these steps:

1. On the schema operations master in the forest, copy the contents of the Sources\Adprep folder from the Windows Server 2008 installation media to a local folder, and then run adprep /forestprep. If you plan to install any read-only domain controllers, you should also run adprep /rodcprep. You 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 2008 installation media to a local folder, and then run adprep /domainprep. You need to use an account that is a member of the Domain Admins group in an applicable domain.

3. If you haven’t previously run adprep /domainprep /gpprep in each domain, you need to manually perform this task. Server Manager for Windows Server 2012 R2 will not prepare Group Policy for you. Note that Group Policy needs to be prepared only the first time you deploy domain controllers running Windows Server 2003 SP1 or later. Running adprep /gpprep modifies the access control entries (ACEs) for all Group Policy Object (GPO) folders in the SYSVOL directory to grant read access to all enterprise domain controllers. This level of access is required to support Resultant Set of Policy (RSoP) for site-based policy and causes the NT File Replication Service (NTFRS) to resend all GPOs to all domain controllers.

As always, you should test any procedure in a lab before performing it in a production environment.

NOTE

To determine which server is the current schema operations master for the domain, start a command prompt and enter dsquery server -hasfsmo schema. To determine which server is the current infrastructure operations master for the domain, start a command prompt and enter 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 additional Active Directory features. If you do this, you can use only Windows Server 2008 or later resources in the domain and you can’t go back to any other mode. You should use Windows Server 2008 mode only when you’re certain that you don’t need Windows NT domain structures, Windows NT BDCs, or Windows 2000 or Windows Server 2003 domain structures.

Using the Windows Server 2008 R2 functional level

Windows Server 2008 R2 and later run only on 64-bit hardware. You’ll likely need to install Windows Server 2008 R2 and later on new hardware rather than hardware designed for earlier releases of Windows Server.

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

1. On the schema operations master in the forest, copy the contents of the Support\Adprep folder from the Windows Server 2008 R2 installation media to a local folder, and then run adprep /forestprep. If you plan to install any read-only domain controllers, you should also run adprep /rodcprep. You 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 Support\Adprep folder from the Windows Server 2008 R2 installation media to a local folder, and then run adprep /domainprep. You need to use an account that is a member of the Domain Admins group in an applicable domain.

As always, you should test any procedure in a lab before performing it in a production environment.

NOTE

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

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

Using the Windows Server 2012 functional level

Windows Server 2012 runs only on 64-bit hardware. Unlike earlier releases of Windows Server, the domain and forest preparations required for updating Active Directory schema don’t need to be performed manually. Instead, when you use Server Manager for Windows Server 2012, and the forest functional level is Windows Server 2003 or higher, any necessary preparations are done automatically when you deploy a domain controller running Windows Server 2012. This means the Configuration Wizard automatically updates forest and domain schema.

You also have the option of manually preparing for Windows Server 2012. To do this, you can use Adprep.exe to update the forest and the domain schema so that they are compatible with Windows Server 2012 domains. The steps are similar to those discussed in the previous section.

After upgrading all domain controllers to Windows Server 2012, you can raise the domain and forest level functionality to take advantage of the latest Active Directory features. If you do this, you can use only Windows Server 2012 resources in the domain.

Using the Windows Server 2012 R2 functional level

Windows Server 2012 R2 runs only on 64-bit hardware. As with Windows Server 2012 RTM, the domain and forest preparations required for updating Active Directory schema don’t need to be performed manually. Instead, when you use Server Manager for Windows Server 2012 R2, and the forest functional level is Windows Server 2003 or higher, any necessary preparations are done automatically when you deploy a domain controller running Windows Server 2012 R2. This means the Configuration Wizard automatically updates forest and domain schema.

As with Windows Server 2012 RTM, you also have the option of manually preparing for Windows Server 2012 R2. After upgrading all domain controllers to Windows Server 2012 R2, you can raise the domain and forest level functionality to take advantage of the latest Active Directory features. If you do this, you can use only Windows Server 2012 R2 resources in the domain.

Raising or lowering domain and forest functionality

Domains operating in a Windows Server 2003 or higher functional level can use universal groups, group nesting, group type conversion, update logon time stamps, and Kerberos KDC key version numbers. In this mode or higher, administrators can do the following:

§ Rename domain controllers without having to demote them first.

§ Rename domains running on Windows Server 2003 or higher 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.

As compared to earlier implementations, forests operating in a Windows Server 2003 or higher functional level have better global catalog replication and intrasite and intersite replication efficiency, in addition to 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 while information is being replicated around the network. Sometimes the entire upgrade process can take 15 minutes or longer. During this time, you might experience delayed responsiveness when communicating with servers and higher latency on the network, so you might want to schedule the upgrade outside 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. Open Active Directory Domains And Trusts. In the console tree, press and hold or right-click the domain you want to work with, and then tap or click Raise Domain Functional Level. The current domain name and functional level are displayed in the Raise Domain Functional Level dialog box.

2. To change the domain functionality, select the new domain functional level from the list provided, and then tap or click Raise.

3. Tap or click OK. The new domain functional level is 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. Open Active Directory Domains And Trusts. In the console tree, press and hold or right-click the Active Directory Domains And Trusts node, and then tap or click Raise Forest Functional Level. The current forest name and functional level are displayed in the Raise Forest Functional Level dialog box.

2. To change the forest functionality, select the new forest functional level by using the list provided, and then tap or click Raise.

3. Tap or click OK. The new forest functional level is replicated to each domain controller in each domain in the forest. This operation can take some time in a large organization.

Another way to raise domain or forest functional level is to use Active Directory Administrative Center. This tool is available as an option on the Tools menu in Server Manager. Follow these steps to raise the domain functional level:

1. In Active Directory Administrative Center, the local domain is opened for management by default. If you want to work with a different domain, tap or click Manage, and then tap or click Add Navigation Nodes. In the Add Navigation Nodes dialog box, select the domain you want to work with, and then tap or click OK.

2. Select the domain you want to work with by tapping or clicking it in the left pane. In the Tasks pane, tap or click Raise The Domain Functional Level. The current domain name and functional level are displayed in the Raise Domain Functional Level dialog box.

3. To change the domain functionality, select the new domain functional level by using the list provided, and then tap or click Raise.

4. Tap or click OK. The new domain functional level is replicated to each domain controller in the domain. This operation can take some time in a large organization.

Follow these steps to raise the forest functional level:

1. In Active Directory Administrative Center, select the domain you want to work with by tapping or clicking it in the left pane. In the Tasks pane, tap or click Raise The Forest Functional Level. The current forest name and functional level are displayed in the Raise Forest Functional Level dialog box.

2. To change the forest functionality, select the new forest functional level by using the list provided, and then tap or click Raise.

3. Tap or click OK. The new forest functional level is replicated to each domain controller in each domain in the forest. This operation can take some time in a large organization.

Generally, you cannot lower the forest or domain functional level after you raise it. However, there are specific exceptions as discussed previously in this chapter. Keep in mind that if you enabled the Active Directory Recycle Bin, you won’t be able to lower the forest functional level.

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, standard 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 by 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 you use to distribute updates, some changes to data can be handled only by individual domain controllers called operations masters. A feature of Windows Server 2008 or later 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 the 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 or later, including global catalog servers. 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, OUs, 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 should be on an NTFS file system drive formatted for use with Windows Server 2008 or later. 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).

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. Administrators for small or medium-size organizations 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 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, and also 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 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 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. 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 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 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 updated data from a global catalog. The infrastructure master then replicates the changes to the other domain controllers in the domain. For more information about operations master roles, see the “Understanding operations master roles” section later in this chapter.

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 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, standard users can’t log on, and those who are logged on 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 means more replication data being transferred over the network.

Universal group membership caching

In a large organization, having global catalogs at every office location might not be practical. 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. If this occurs, standard users won’t be able to log on; only members of Domain Admins will be able to log on. This happens because logon requests must be routed over the network to a global catalog server at a different office, and this isn’t possible with no connectivity.

As you might expect, you can resolve this problem in many ways. You can make one of the domain controllers at the remote office a global catalog server by following the procedure discussed in the “Configuring global catalogs” section in Chapter 8. The disadvantage of this approach is that the designated server or servers will have an additional burden placed on them and might require additional resources. You also have to manage more carefully 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 a global catalog server. This allows for faster logons and makes managing server outages much easier because 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 caching 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 and the global catalog they’re contacting must be in the same site. If you have multiple sites, you need to configure local caching in each site. Additionally, users in the site must be part of a Windows domain running in a Windows Server 2003 or higher functional mode. To learn how to configure caching, see the “Configuring universal group membership caching” section in Chapter 8.

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

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

§ Schema information for the forest

§ Configuration information for all domains in the forest

§ A subset of the properties between global catalogs

§ All directory objects and properties for their 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 no 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 in addition to 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 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 Interfaces (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 create and manage 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, and you can assign these roles 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 enter 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 enterdsquery server -hasfsmo name.

These forestwide roles must be unique in the forest. This means that 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 allocated by the relative ID (RID) master. To determine which server is the current relative ID master for the domain, start a command prompt and enter dsquery server -hasfsmo rid.

§ PDC emulator. When you use mixed-mode 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 BDCs. The PDC emulator is the default time server and, as such, also performs time synchronization in a domain. To determine which server is the current PDC emulator for the domain, start a command prompt and enter 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 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 enter dsquery server -hasfsmo infr.

These domainwide roles must be unique in each domain. This means that 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 child domain or a root domain in a new tree, the first domain controller in the new domain is automatically assigned operations master roles, too. 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. In this case, you make one domain controller the operations master and designate the second as your standby operations master. The standby operations master can then be used if the primary one 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 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 also usually want the RID master and PDC emulator to be on the same server. But you can separate these roles if necessary. For example, on a large network where peak loads are causing performance problems, you probably want to place the RID 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 earlier in this chapter for details.

Using the Active Directory Recycle Bin

When your Active Directory forest is operating in the Windows Server 2008 R2 or higher mode, you can use the Active Directory Recycle Bin. The Active Directory Recycle Bin adds an easy-to-use recovery feature for Active Directory objects. When you enable this feature, all link-valued and nonlink-valued attributes of a deleted object are preserved, allowing you to restore the object to the same state it was in before it was deleted. You can also recover objects from the recycle bin without having to initiate an authoritative restore. This differs substantially from the previously available technique, which used an authoritative restore to recover deleted objects from the Deleted Objects container. Previously, when you deleted an object, most of its non-link-valued attributes were cleared and all of its link-valued attributes were removed, which meant that although you could recover a deleted object, the object was not restored to its previous state.

Preparing schema for the Recycle Bin

Before you can make the Recycle Bin available, you must update Active Directory schema with the required Recycle Bin attributes. You do this by preparing the forest and domain for the Windows Server 2008 R2 functional level or higher. When you do this, the schema is updated, and then every object in the forest is also updated with the Recycle Bin attributes. This process is irreversible after it is started.

After you prepare Active Directory, you need to upgrade all domain controllers in your Active Directory forest to Windows Server 2008 R2 or higher and then raise the domain and forest functional levels to the Windows Server 2008 R2 level or higher. Optionally, you can update Active Directory schema in your forests and domains for Windows Server 2012 or later to enable the enhanced Recycle Bin.

After these operations, you can enable and access the Recycle Bin. When Recycle Bin has been enabled, it cannot be disabled. Now when an Active Directory object is deleted, the object is put in a state referred to as logically deleted and moved to the Deleted Objects container, shown inFigure 7-7. Also, its distinguished name is altered. A deleted object remains in the Deleted Objects container for the period of time set in the deleted object lifetime value, which is 180 days by default.

REAL WORLD

The msDS-deletedObjectLifetime attribute replaces the tombstoneLifetime attribute. However, when msDS-deletedObjectLifetime is set to $null, the lifetime value comes from the tombstoneLifetime. If the tombstoneLifetime is also set to $null, the default value is 180 days.

Screen shot of the Active Directory Administrative Center, showing objects that have been deleted, and whose deleted object lifetime has not expired, in the Deleted Objects container.

Figure 7-7. Deleted objects remain in the Deleted Objects container for the deleted object lifetime value.

Recovering deleted objects

If you elect not to use the Recycle Bin, you can still recover deleted objects from the Deleted Objects container by using an authoritative restore and other techniques I’ll discuss in this section. The procedure has not changed from previous releases of Windows Server. What has changed, however, is that the objects are restored to their previous state with all link-valued and non-link-valued attributes preserved. To perform an authoritative restore, the domain controller must be in Directory Services Restore Mode.

Rather than using an authoritative restore and taking a domain controller offline, you can recover deleted objects by using the Ldp.exe administration tool or the Active Directory cmdlets for Windows PowerShell. If you updated the Active Directory schema in your forests and domains for Windows Server 2012 or later, you also can enable the enhanced Recycle Bin, which allows you to recover deleted objects by using Active Directory Administrative Center.

Keep in mind that Active Directory blocks access to an object for a short while after the object is deleted. During this time, Active Directory processes the object’s link-value table to maintain referential integrity on the linked attribute’s values. Active Directory then permits access to the deleted object.

Using Ldp.exe for basic recovery

You can use Ldp.exe to display the Deleted Objects container and recover a deleted object by following these steps:

1. Type Ldp.exe in the Everywhere search box, and then press Enter.

2. On the Options menu, tap or click Controls. In the Controls dialog box, select Return Deleted Objects in the Load Predefined list, and then tap or click OK.

3. Bind to the server that hosts the forest root domain by choosing Bind from the Connection menu. Select the Bind type, and then tap or click OK.

4. On the View menu, tap or click Tree. In the Tree View dialog box, use the BaseDN list to select the appropriate forest root domain name, such as DC=Cpandl,DC=Com, and then tap or click OK.

5. In the console tree, double-tap or double-click the root distinguished name, and then locate the CN=Deleted Objects container.

6. Locate and press and hold or right-click the Active Directory object you want to restore, and then tap or click Modify. This displays the Modify dialog box.

7. In the Edit Entry Attribute box, type isDeleted. Do not enter anything in the Values box.

8. Under Operation, tap or click Delete, and then tap or click Enter.

9. In the Edit Entry Attribute box, type distinguishedName. In Values, type the original distinguished name of this Active Directory object.

10.Under Operation, tap or click Replace. Select the Extended check box, tap or click Enter, and then tap or click Run.

Using Windows PowerShell for basic and advanced recovery

The Active Directory cmdlets for Windows PowerShell allow you to recover deleted objects by using scripts or by entering commands at a Windows PowerShell prompt. You use Get-ADObject to retrieve the object or objects you want to restore, pass that object or objects to Restore-ADObject, and then Restore-ADObject restores the object or objects to the directory database.

To use the Active Directory cmdlets for recovery, you need to open an elevated, administrator Windows PowerShell prompt by pressing and holding or right-clicking the Windows PowerShell entry on the menu, and then tapping or clicking Run As Administrator. The basic syntax for recovering an object is as follows:

Get-ADObject -Filter {ObjectId} -IncludeDeletedObjects | Restore-ADObject

ObjectId is a filter value that identifies the object you want to restore. For example, you could restore a deleted user account by display name or SAM account name, as shown in these examples:

Get-ADObject -Filter {DisplayName -eq "Rich Tuppy"}

-IncludeDeletedObjects | Restore-ADObject

Get-ADObject -Filter {SamAccountName -eq "richt"} –IncludeDeletedObjects

| Restore-ADObject

Note that nested objects must be recovered from the highest level of the deleted hierarchy to a live parent container. For example, if you accidentally deleted an OU and all its related accounts, you need to restore the OU before you can restore the related accounts.

The basic syntax for restoring container objects such as an OU is as follows:

Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=ContainerID)"

–IncludeDeletedObjects | Restore-ADObject

ContainerID is a filter value that identifies the container object you want to restore. For example, you could restore the Corporate Services OU, as shown in this example:

Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=Corporate_Services)"

–IncludeDeletedObjects | Restore-ADObject

If the OU contains accounts you also want to restore, you can now restore the accounts by using the technique discussed previously, or you can restore all accounts at the same time. The basic syntax requires that you establish a search base and associate the accounts with their last known parent, as shown here:

Get-ADObject -SearchBase "CN=Deleted Objects,ForestRootDN" -Filter {lastKnownParent -eq "ContainerCN,ForestRootDN"} -IncludeDeletedObjects |

Restore-ADObject

ForestRootDN is the distinguished name of the forest root domain, such as DC=Cpandl,DC=Com, and ContainerCN is the common name of the container, such as OU=Corporate_Services or CN=Users. The following example restores all the accounts that were in the Corporate Services OU when it was deleted:

Get-ADObject -SearchBase "CN=Deleted Objects,DC=Cpandl,DC=com" –Filter

{lastKnownParent -eq "OU=Corporate_Services,DC=Cpandl,DC=com"}

-IncludeDeletedObjects | Restore-ADObject

Using the enhanced Recycle Bin for recovery

The enhanced Recycle Bin makes recovering deleted objects as easy as pointing and clicking or tapping and holding. After you updated the Active Directory schema in your forests and domains for Windows Server 2012 or later, you enable the enhanced Recycle Bin for use by following these steps:

1. In Active Directory Administrative Center, the local domain is opened for management by default. If you want to work with a different domain, tap or click Manage, and then tap or click Add Navigation Nodes. In the Add Navigation Nodes dialog box, select the domain you want to work with, and then tap or click OK.

2. Select the domain you want to work with by tapping or clicking it in the left pane. In the Tasks pane, tap or click Enable Recycle Bin, and then tap or click OK in the confirmation dialog box.

3. Active Directory will begin replicating the change to all domain controllers in the forest. After the change is replicated, the enhanced Recycle Bin will be available for use. If you then tap or click Refresh in Active Directory Administrative Center, you’ll notice that a Deleted Object container is now available for domains that use the enhanced Recycle Bin.

Keep in mind that the enhanced Recycle Bin is a forestwide option. When you enable this option in one domain of a forest, Active Directory replicates the change to all domain controllers in all domains of the forest.

With the enhanced Recycle Bin enabled, you can recover deleted objects with ease. In Active Directory Administrative Center, domains using the enhanced Recycle Bin will have a Deleted Object container. In this container, a list of deleted objects is displayed. As discussed previously, deleted objects remain in this container for the deleted object lifetime value, which is 180 days by default.

Each deleted object is listed by name, when it was deleted, the last known parent, and the type. When you select a deleted object by tapping or clicking it, you can use the options in the Tasks pane to work with it. The Restore option restores the object to its original container. For example, if the object was deleted from the Users container, it is restored to this container.

The Restore To option restores the object to an alternate container within its original domain or to a different domain within the current forest. Specify the alternate container in the Restore To dialog box. For example, if the object was deleted from the Users container in the tech.cpandl.com domain, you could restore it to the Devs OU in the eng.cpandl.com domain.