Book Image

Active Directory Administration Cookbook - Second Edition

By : Sander Berkouwer
Book Image

Active Directory Administration Cookbook - Second Edition

By: Sander Berkouwer

Overview of this book

Updated to the Windows Server 2022, this second edition covers effective recipes for Active Directory administration that will help you leverage AD's capabilities for automating network, security, and access management tasks in the Windows infrastructure. Starting with a detailed focus on forests, domains, trusts, schemas, and partitions, this book will help you manage domain controllers, organizational units, and default containers. You'll then explore Active Directory sites management as well as identify and solve replication problems. As you progress, you'll work through recipes that show you how to manage your AD domains as well as user and group objects and computer accounts, expiring group memberships, and Group Managed Service Accounts (gMSAs) with PowerShell. Once you've covered DNS and certificates, you'll work with Group Policy and then focus on federation and security before advancing to Azure Active Directory and how to integrate on-premise Active Directory with Azure AD. Finally, you'll discover how Microsoft Azure AD Connect synchronization works and how to harden Azure AD. By the end of this AD book, you’ll be able to make the most of Active Directory and Azure AD Connect.
Table of Contents (18 chapters)

Using domain controller cloning

The IFM feature for promoting domain controllers leverages the fact that the contents of the Active Directory database and the Active Directory SYSVOL are identical throughout all domain controllers within the domain. The domain controller cloning feature takes this one step further and leverages the fact that all domain controllers are largely identical – not just the Active Directory-related files but all operating system files, most agent installations, information security measures, and most configuration items.

When a domain controller is properly prepared and promoted, it can serve as a template.

Getting ready

The domain controller cloning feature requires the following:

  • A hypervisor platform offering the VM-GenerationID functionality
  • At least one domain controller running Windows Server 2012 or a newer version of Windows Server, promoted to a domain controller, holding the PDC Emulator FSMO role

The domain controller you intend to clone needs to adhere to the following requirements:

  • Running Windows Server 2012 or a newer version of Windows Server
  • Running on top of a VM-GenerationID-capable hypervisor platform
  • Running the latest stable integration components or VMware tools
  • Promoted as a domain controller
  • Not holding the PDC Emulator FSMO role
  • Not holding the RID Master FSMO role

When cloning domain controllers, check for proper Active Directory replication before cloning. This ensures that the domain controllers are up to date with all changes in Active Directory and can communicate the changes involved in adding a domain controller.

How to do it...

There are four steps to cloning a domain controller:

  • Making sure all agents and software packages are cloneable
  • Supplying the information for the new domain controller configuration
  • Adding the domain controller to the Cloneable Domain Controllers group
  • Cloning the domain controller from the hypervisor

Making sure all agents and software packages are cloneable

To successfully clone a domain controller, all agents and software packages that you've installed and configured on the domain controller you intend to clone need to support it.

When you install the Active Directory Domain Services role on a Windows Server 2012 installation, or on any newer version of Windows Server, there is the Get-ADDCCloningExcludedApplicationList PowerShell cmdlet that you can use. When you run this PowerShell cmdlet, it will return the applications and services that Microsoft does not know whether you can successfully clone.

All Microsoft services and add-on packages that ship with Windows Server are tested, so these are already part of the DefaultDCCloneAllowList.xml file. The contents of C:\Windows\System32\DefaultDCCloneAllowList.xml are shown as follows:

Figure 2.13 – Contents of the DefaultDCCloneAllowList.xml file

Figure 2.13 – Contents of the DefaultDCCloneAllowList.xml file

For any other service and/or application, the recommended practice is to ask the vendor whether domain controller cloning is supported. When all services and applications check out, you can run the following line of PowerShell to add them to your organization's CustomDCCloneAllowList.xml file:

Get-ADDCCloningExcludedApplicationList -GenerateXml -Path C:\Windows\NTDS -Force

In the preceding line of Windows PowerShell, the default path for the Active Directory database is supplied. Change it accordingly before running it.

After cloning, the domain controller picks up this file when you store it on removable media or in the same path as the Active Directory database.

Supplying the information for the new domain controller configuration

The new domain controller that is created when an existing domain controller is cloned will need to be different from the existing one. It will need a different hostname, IPv4 address(es), IPv6 address(es), possibly different DNS Server allocations, or a different Active Directory site.

Microsoft provides a way to supply this information through the DCCloneConfig.xml file. Again, after cloning, the domain controller picks up this file when you store it on removable media or in the same path as the Active Directory database.

If no DCCloneConfig.xml file is supplied, the new domain controller will boot into Directory Services Restore Mode.

If an empty DCCloneConfig.xml file is supplied, the new domain controller will be assigned the following:

  • IP addresses through DHCP
  • An automatically assigned hostname
  • The same Active Directory site as the source domain controller

If a specific hostname, Active Directory site, or IP address is needed, look at the parameters you can specify for New-ADDCCloningConfig, such as the -SiteName, -CloneComputerName, and -Static -IPv4Address parameters.

A sample PowerShell one-liner to create a new domain controller with the name DC04 in the Active Directory site named RemoteLocation with the correct IPv4 information would look like the following:

New-ADDCCloneConfigFile -CloneComputerName "DC04" -SiteName RemoteLocation -Static -IPv4Address "10.0.1.3" -IPv4SubnetMask "255.255.255.0" -IPv4DefaultGateway "10.0.1.1" -IPv4DNSResolver "10.0.0.2"   

Change the values for the -SiteName, -CloneComputerName, -Static, -IPv4Address, -IPv4SubnetMask, -IPv4DefaultGateway, and -IPv4DNSResolver parameters for parameters that make sense for your environment.

Adding the domain controller to the Cloneable Domain Controllers group

In large organizations, the team responsible for managing Active Directory is usually a different team from the one managing the hypervisor platform. Through the integration components and/or VMware tools, the latter team might configure domain controllers for cloning and clone them, adding to the management burden of the Active Directory management team.

Therefore, the Active Directory team must explicitly allow a domain controller to be cloned in Active Directory. The mechanism to do so is to add source domain controllers to the Cloneable Domain Controllers group.

The following line of PowerShell accomplishes this for a source domain controller named DC03 in the lucernpub.com Active Directory domain:

Add-ADGroupMember "Cloneable Domain Controllers" "CN=DC03,OU=Domain Controllers,DC=LucernPub,DC=com"

Replace the distinguishedName value of DC03 with the distinguishedName value of the domain controller you want to add to the Cloneable Domain Controllers group.

Cloning the domain controller from the hypervisor

Now, the hypervisor platform team can clone the source domain controller.

As an Active Directory administrator, shut down the domain controller you intend to clone. After cloning has been successful, remove the source domain controller from the Cloneable Domain Controllers group and start it again as one of the domain controllers for the domain, or leave it off and allow it to be cloned repeatedly for a maximum period of 60 to 180 days, depending on the current tombstone lifetime period settings.

How it works...

Domain controller cloning leverages the VM-GenerationID feature found in most modern hypervisor platforms. Through the specifications that Microsoft wrote for this feature, this ID is stored in every virtual machine's RAM and only changes under certain circumstances. These circumstances are the following:

  • When a virtual machine's hard disk is attached to a different virtual machine
  • When a previous snapshot for a virtual machine is applied

Active Directory Domain Services is the first server role to take advantage of the VM-GenerationID feature to do the following:

  • Increase the integrity of the contents of the Active Directory database and the Active Directory SYSVOL by employing virtualization safeguards
  • Clone a perfectly prepared domain controller using domain controller cloning

By storing the 128-bit value for the VM-GenerationID in RAM in the Active Directory database, and the domain controller checking the value stored in the database with the value in RAM before each major action, the domain controller can sense when a snapshot is applied or when the hard disk is reused.

Important Note

As the VM-GenerationID feature is a hypervisor platform feature, a domain controller cannot sense when a snapshot is applied or when the hard disk is reused when these actions originate from the storage fabric or otherwise outside of the hypervisor platform.

When a hard disk is reused and the domain controller is properly prepared to be cloned, domain controller cloning creates a perfect clone of the source domain controller.

Domain controller cloning only allows cloning of fully writable domain controllers. It does not apply to read-only domain controllers.

See also

Use the information in the Determining whether a virtual domain controller has a VM-GenerationID recipe to see whether the hypervisor platform supports domain controller cloning.

Refer to the Modifying the tombstone lifetime period recipe in Chapter 16, Hardening Azure AD, to find out whether domain controllers can be cloned for 60 or 180 days.