Active Directory

Domain controllers

Domain controllers (DCs) are the heart of Active Directory. Their primary role is to host the Active Directory database, stored in the ntds.dit file. Given their importance, you should limit who can sign on locally to a domain controller.

Deployment

Although the wizard for deploying a domain controller has been updated from what it looked like back in Windows Server 2008 R2, the process is still functionally the same. You choose whether you want to

• Add a domain controller to an existing domain

• Add a new domain to an existing forest

• Add a new forest

To deploy a domain controller, perform the following steps:

1. Using Add Roles and Features in Server Manager, add the Active Directory Domain services role. You need to add this role, shown in Figure 4-4, before you can promote a server to function as a domain controller.

   

   Figure 4-4 Add the Active Directory Domain Services role

2. Once the role files are installed, you’ll be able to promote the server to function as a domain controller. You can do this from the Server Manager console by selecting the notification icon and then clicking Promote this server to a domain controller, as shown in Figure 4-5.

   

   Figure 4-5 Promote this server to a domain controller in Server Manager

3. On the Deployment Configuration page of the Active Directory Domain Services Configuration Wizard, you’ll be asked whether you want to add a domain controller to an existing domain, add a new domain to an existing forest, or add a new forest. To add a domain controller to an existing domain, you’ll need to have the credentials of a member of the Domain Admins group. To add a new domain to an existing forest, you’ll need an account that is a member of the Enterprise Admins group. You can specify this account on the Deployment Configuration page, as shown in Figure 4-6.

   

   Figure 4-6 Deployment Configuration

If you’re adding a domain controller to an existing domain, have the computer domain joined before promoting it. When you add a new domain to an existing forest, choose between adding a child domain or a tree domain. When you add a tree domain, you create a new namespace within an existing forest. For example, you can create the Adatum.com domain in the existing contoso.com forest. Contoso.com remains the root domain of the forest.

Microsoft’s recommendation is that you use a registered root domain name, such as Contoso.com for the domain name, rather than a nonexternally resolvable domain name like contoso.internal. Having a registered externally resolvable domain name simplifies the process when configuring synchronization with Azure AD Connect.

Windows Server supports split DNS, which means that you can configure zones so that a subset of records is resolvable for clients on external networks. Many organizations still use non-resolvable domain names, and you should only take the Microsoft advice into account if you’re deploying a new forest or reconfiguring a domain in preparation for synchronizing with Entra in Azure.

When you add a new child domain to an existing forest, you specify the parent domain. For example, you could add the australia.contoso.com child domain to the contoso.com domain. After you’ve done that, you can add the victoria.australia.contoso.com child domain to the australia.contoso.com parent domain. Adding a child domain requires Enterprise Administrator credentials in the forest.

Domain controllers can also host the DNS service and function as global catalog servers. In Windows Server environments, DNS is almost always hosted on domain controllers. You’ll learn more about DNS configuration and options in Chapter 5, “DNS, DHCP, and IPAM.” Global Catalog servers are covered later in this chapter.

When deploying a domain controller in an environment with multiple sites configured, you can select which site you want the domain controller to belong to. You can change this after deployment using the Active Directory Sites And Services console.

Generally, the default paths for the Database folder, log files folder, and SYSVOL folder are appropriate. The primary reasons to alter this location are for performance reasons or if you have concerns about the amount of storage available on the volume that hosts the Windows Server operating system.

Directory Services Restore Mode passwords

Directory Services Restore Mode (DSRM) allows you to perform an authoritative restore of deleted objects from the Active Directory database. You must perform an authoritative restore of deleted items because if you don’t, the restored item is deleted the next time the AD database synchronizes with other domain controllers, where the item is marked as deleted. Authoritative restores are covered later in this chapter. You configure the Directory Services Restore Mode password on the Domain Controller Options page of the Active Directory Domain Services Configuration Wizard, as shown in Figure 4-7. You can use Windows LAPs, covered in Chapter 12, “Hardening Windows Server,” to centrally manage Directory Services Restore Mode Passwords and ensure they’re unique for each domain controller.

In the event that you forget the DSRM password and you are not using Windows LAPs to manage them, you can reset it by running ntdsutil.exe from an elevated command prompt and entering the following command at the ntdsutil.exe prompt, at which point you are prompted to enter a new DSRM password:

Reset password on server null

Advanced installation options

One of the advanced installation options for domain controllers is to install from media. Installing from media gives you the option of prepopulating the AD DS database for a new DC from a backup of an existing DC’s AD DS database, rather than having that database populated through synchronization from other domain controllers in your organization. This is very useful when you need to deploy a DC at a remote location that has limited WAN connectivity and you don’t want to flood the WAN link with AD DS database synchronization traffic during domain controller deployment. Instead, you ship a backup of the AD DS database to the remote site, and that backup is used to perform the initial AD DS database population. After the newly installed DC connects to other domain controllers, it performs a synchronization, bringing the database up to date with a much smaller synchronization than what would be required when synchronizing from scratch.

Server Core

As the reduced attack surface area of Server Core deployments makes it more secure, domain controllers—which don’t have a GUI dependency—are one of several perfect workloads for Server Core deployments. Microsoft recommends deploying domain controllers using the Server Core deployment option and managing those servers remotely.

To configure a computer running Server Core as a domain controller, you can

1. Remotely connect to the server using the Server Manager console.

2. Run the Add Roles And Features Wizard to remotely install the Active Directory binaries on the server.

3. Run the Active Directory Domain Services Configuration Wizard to promote the computer to a domain controller.

You can also use Windows Admin Center to deploy the AD DS feature, but at the time this book was written, you couldn’t configure the feature once it was deployed. As an alternative to using the wizard or console, you can run the following PowerShell commands, either locally or remotely, to install the AD DS binaries and promote the server to a domain controller:

In addition to running this set of commands, you also need to specify a Directory Service Restore Mode password before the computer running Server Core completes the domain controller promotion process. You’ll need to use the Install-ADDSForest cmdlet if you’re installing the first domain in a new forest, as shown here:

Virtualized domain controllers

Domain controllers can be run on supported virtualization platforms, including the latest version of VMware and Hyper-V. With the Production Checkpoints feature available in Windows Server 2019 and later Hyper-V, domain controllers can be restored from a checkpoint without causing problems. Microsoft recommends that you run virtualized domain controllers as shielded VMs on a guarded virtualization fabric because this will minimize the chance that a nefarious or compromised virtualization administrator account could be used to access the contents of the DC VM. You can learn more about production checkpoints, shielded VMs, and guarded fabrics in Chapter 6, “Hyper-V.”

Global catalog servers

Global catalog servers host a full copy of all objects stored in their host directory and a partial, read-only copy of all other objects in other domains in the same forest. They’re used when it’s necessary to perform a check of other objects in the forest, such as when a check is performed of a universal group’s membership, which could contain members from other domains in the forest.

You can use the Active Directory Sites And Services console to configure a server to function as a global catalog server by right-clicking the NTDS settings of the server. Alternatively, you can run the Set-ADObject cmdlet. For example, to configure the DC MEL-DC1 in the Melbourne-Site site as a global catalog server, run the following command:

Decommissioning a domain controller

In some circumstances, you want to remove an existing domain controller from your domain. When you do this, you want to ensure that all traces of the domain controller are removed from Active Directory and DNS. To demote a domain controller when the domain controller is accessible and online, perform the following steps:

1. Ensure that the server you want to demote hosts no FSMO roles. You’ll learn how to locate and transfer these roles later in the chapter.

2. In Server Manager, go to Manage and then select Remove Roles and Features.

3. Select the server you want to demote and click Next.

4. On the Remove Server Roles screen, uncheck Active Directory Domain Services (AD DS) and choose Remove Features.

5. The wizard will prompt you to demote the domain controller. Click on Demote This Domain Controller as shown in Figure 4-8.

   

   Figure 4-8 Configuring Domain Controller options

6. On the credentials page, provide the credentials. You don’t need to use the Force The Removal Of This Domain Controller option unless the server is unable to contact the domain or this is the last domain controller in the domain or forest.

7. You’ll be promoted on the Warnings page with a checkbox to proceed with removal, and you can’t choose Next until you select this option.

8. On the Password page, you’ll be asked to provide a password for the default local Administrator account. Unless the domain controller was the last in the domain or forest, the computer will still be domain-joined after the operation.

9. On the Review Options page, you’ll be able to click Demote. The server will be restarted automatically upon completion. You can then remove the Active Directory Domain Services role files.

If you can’t gracefully remove a domain controller because it’s offline, forcibly seize any FSMO roles and then delete the domain controller’s computer account using Active Directory users and computers. Deleting the account will remove the domain controller’s metadata from Active Directory and DNS.

To remove server metadata using ntdsutil, issue the following command, where <ServerName> is the distinguished name of the domain controller whose metadata you want to remove from Active Directory:

Read Only Domain Controllers

Read Only Domain Controllers (RODC) are a special type of domain controller. They host a read-only copy of the AD DS database. Rather than storing the passwords for all users in the domain, RODCs only store the passwords of a specific set of accounts that you configure. The first domain controller in a new domain or forest cannot be an RODC.

The justification for RODCs is that DCs sometimes need to be located in places where servers have poor physical security and might be stolen. For example, many organizations had branch offices where servers were located under someone’s desk. A good rule of thumb is that you should consider a location insecure if it is accessible to anyone other than IT. If a janitor can pull out a computer’s power cord to power a vacuum cleaner, the computer isn’t in a secure location.

If a server that hosts a domain controller is stolen, the best practice is to reset the account passwords that might have been compromised because it’s possible, with the correct tools, to extract passwords from the AD DS database if you have direct access to it. If an ordinary DC is stolen, you would, in theory, need to reset the passwords of every account in the domain because you could never be sure that someone hadn’t gained access to the Active Directory database and found a way to extract the passwords of people in your organization.

With shielded VMs and shielded fabrics, it’s possible to run a DC in a manner where the VM itself is protected by encryption. In the event that the host server is stolen, the AD DS database cannot be recovered because the contents of the virtualization server’s storage are encrypted using BitLocker.

Passwords on RODCs

One of the most important steps in configuring an RODC is limiting which passwords can be replicated down to the server from a writable domain controller. The default configuration of an RODC has it store almost everything from Active Directory except for user and computer account passwords. In the event that a user or computer account needs to be authenticated against Active Directory, the RODC acts as a proxy for a writable Windows Server DC. The authentication occurs, but it depends on the WAN link to be functional because if you could host a writable DC locally, you wouldn’t need the RODC.

Although you can configure an RODC to not cache any passwords locally, you can configure an RODC to cache the passwords of select staff working at a branch office to speed their login. Caching passwords also allows branch office users to log in if the WAN link fails. If the WAN link fails and the user’s credentials are not cached, the user is simply unable to log in to the domain.

You configure which accounts can authenticate using the RODC by using the Password Replication Policy, as shown in Figure 4-9. By default, only members of the Allowed RODC Password Replication group can use the RODC to authenticate. This is only the case if the user account is not a member of the Account Operators, Administrators, Backup Operators, Server Operators, or Denied RODC Password Replication Group groups.

RODC partial attribute set

You can configure Active Directory so that only specific attributes on AD DS objects are replicated to an RODC. You would do this because some applications are configured to store sensitive data, such as passwords or encryption keys, as attributes for an object. If you add these sensitive attributes to the filtered attributes set, you can ensure that this information will not be replicated and stored on an RODC.

It’s not possible to add system-critical attributes to the RODC filtered attribute set. Attributes that cannot be added to the filtered attribute set are those required for AD DS, the Local Security Authority (LSA), Security Accounts Manager (SAM), and Microsoft-specific security services providers to be able to function correctly. You mark an attribute as confidential by removing the Read permission for that attribute for the Authenticated Users group.

RODC local administrators

Because you deploy RODCs as a security measure, they are almost always placed at branch office sites. Because resources at branch office sites are often sparse, it’s also likely that you’ll co-locate other services on the server hosting the RODC role. For example, a server that functions as an RODC can also function as a file server, DNS server, DHCP server, and local intranet server.

You can allow a user without Domain Admin privileges to deploy an RODC if you have pre-created an RODC account and added it to the appropriate Active Directory Domain Services site, and the user is a member of the local Administrators group on the computer. You can perform this task in PowerShell or the Active Directory Administrative Center.

If the computer hosting the RODC role also needs to host other roles, you might need to grant administrator access to a user who works at the branch office (but who is not a member of your organization’s usual IT staff) in case your normal remote administration techniques don’t work. RODCs differ from normal domain controllers in that you can grant local administrator access without having to make the user a member of the Domain Admins group.

To configure a user to function as a local administrator on the computer that hosts the RODC role, edit the properties of the RODC’s computer account and configure a security group for the Managed By setting.

In Chapter 12, you learn about Just Enough Administration, a technology that you could use to allow a user to perform remote administrative tasks on an RODC without being made an RODC local administrator.

Decommissioning an RODC

If you suspect that an RODC has been compromised, you can delete the RODC’s account from the Domain Controllers container in Active Directory Users And Computers. When you do this, you get the option of resetting all passwords for user and computer accounts that were cached on the RODC, as well as the option of exporting a list of all potentially compromised accounts.

Virtual domain controller cloning

Windows Server supports virtual domain controller cloning. Rather than redeploying domain controllers from scratch each time you need one, domain controller cloning allows you to take an existing virtual machine, make a copy of it, and deploy that copy.

Virtual domain controller cloning has the following prerequisites:

• Hypervisor must support VM-Generation ID. The version of Hyper-V included with all supported versions of Windows supports this technology, as do the most recent versions of VMware.

• The source domain controller needs to be running Windows Server 2012 or later.

• The domain controller that hosts the PDC Emulator role must be online and contactable by the cloned DC. The computer that hosts the PDC Emulator role must also be running Windows Server 2012 or later.

• The source DC must be a member of the Cloneable Domain Controllers group.

You also need to create the DCCloneConfig.xml file. You can do this by using the New-ADDCCloneConfig cmdlet in PowerShell. When running this cmdlet, you need to specify the cloned DC’s IPv4 address information and the site the cloned DC is deployed to. For example, to create the clone configuration file for a clone DC that has the IP address 10.10.10.42 with the subnet mask 255.255.255.0, default gateway of 10.10.10.1, DNS server address of 10.10.10.10, and site name MEL-SITE, issue this command:

After the clone configuration file is created, you import the VM using this file and specify a copy of the source DC’s exported virtual hard disk.