Microsoft Workloads on AWS

Automate disaster recovery for your self-managed Active Directory on AWS

In this blog post, I will show how you can leverage Amazon Web Services (AWS) for disaster recovery (DR) for your self-managed Microsoft Active Directory (AD). I will also provide an automated solution to help you run on-demand, periodic DR tests of your AD infrastructure as part of your larger business continuity strategy.

Introduction

Most corporate organizations use Microsoft AD for identity management across the organization. Customers are often interested in how they can leverage AWS for implementing a DR strategy for their self-managed AD infrastructure. First off, if you are using AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) , the service handles this for you. AWS Managed Microsoft AD takes automatic daily snapshots of your directory, and in the event of a disaster, you can—with a single click of a button—restore your directory from backup and restore your business operations. For more information, see snaphot or restore your directory in the AWS Managed Microsoft AD documentation.

If you are running your self-managed AD on premises or on Amazon Elastic Compute Cloud (Amazon EC2), I will show you how to leverage AWS as DR for your AD. I am also providing you with an automated solution to help you run periodic DR drills of your AD infrastructure as part of your larger business continuity strategy.

Solution overview

Taking regular backups is critical for implementing a DR plan for AD. This proposed solution leverages a combination of encrypted Amazon Elastic Block Store (EBS) volumes and the AWS Backup service to provide robust protection for your AD backup data. You start by backing up system state data (which contains AD data) to a secondary encrypted Amazon EBS volume. You then backup the Amazon EBS volume using AWS Backup, as shown in Figure 1, to further protect the data from incidents like accidental deletion. And, in the event of a disaster, or as part of your regular DR drills, you restore the Amazon EBS volume from AWS Backup and then restore AD from the Amazon EBS volume. I provide a sample AWS Cloudformation template to automate the process. To use this solution for your on-premises AD, you must extend your on-premises AD to AWS, as shown in Figure 1.

Refer to this blog post for steps on extending your self-managed AD to AWS.

Solution architecture diagramFigure 1: Solution architecture.

Walkthrough

Here are the high-level steps to implement the solution:

PROTECT
The solution starts with steps to protect your AD data:

  1. Extend your on-premises AD to AWS by deploying at least 2 domain controllers in different availability zones on AWS, as shown in Figure 1. This step is not required if your self-managed AD is hosted on Amazon EC2.
  2. Create and attach an encrypted Amazon EBS) volume to each domain controller on Amazon EC2.
  3. Run daily system state backups to the attached secondary encrypted volumes.
  4. Configure AWS Backup to take daily snapshots of the secondary Amazon EBS volumes.
  5. Configure AWS Backup to take regular AMI backup of the domain controller instance. Set up the frequency to align with your existing Windows patching maintenance window.

RESTORE
The solution then provides steps required for self-managed AD disaster recovery dry runs on AWS.

  1. Build out an isolated environment: new Amazon Virtual Private Cloud (Amazon VPC) VPC, subnets, NAT Gateways, etc.
  2. Use the domain controller AMI backup to launch an Amazon EC2 instance in the isolated environment.
  3. Restore the Amazon EBS volume containing system state backup from AWS Backup.
  4. Attach the backup volume to the Amazon EC2 instance.
  5. Restore the system state backup from the backup volume.
  6. Perform AD Forest recovery steps.

Prerequisites

The instructions in this post assume that you understand how to create Amazon EC2 instances and how to use Remote Desktop Protocol (RDP) to log in to the instances. For customers running AD on premises, these instructions also assume you have extended your on-premises AD to Amazon EC2. Refer to this blog.

Setup protection for your AD

In this section, you will set up daily backup of your AD data on two levels. First, you will configure an automated daily system state backup to Amazon EBS. A system state backup of a domain controller includes AD data. For more details, refer to the Microsoft documentation.

Next, you will set up an automated daily snapshot of the Amazon EBS volume containing the system state backup using AWS Backup. This is necessary to protect the Amazon EBS volume. Think of this as an offsite copy of your AD backup.

Next, you will set up automated AMI backups of the domain controller instance itself. The AMI ensures you are restoring to the same operating system instance during forest recovery, as recommended by Microsoft. You can align the AMI backup frequency with your monthly Windows patching maintenance window.

STEP 1: Configure daily backup of AD to Amazon EBS.

Complete the following steps to configure an automated daily system state backup of AD to Amazon EBS.

  1. Create an encrypted Amazon EBS volume.
  2. Attach the Amazon EBS volume to one of the domain controllers on Amazon EC2.
  3. Make the Amazon EBS volume available for Windows.
  4. Follow the steps in this documentation to set up an automated system state backup to the Amazon EBS volume. Alternatively, you can set this up using the script below. This script creates a scheduled task that runs a system state backup to the secondary Amazon EBS volume at 1:00 A.M. daily. In my example, the drive letter of the backup Amazon EBS volume is “d:”. It also creates a second scheduled task that runs at start-up and uses EC2Launch to fix the route to the EC2 metadata service. Properly configuring the route to EC2 metadata is required when a custom Windows AMI is used to launch an instance in a different subnet/VPC. This ensures that when you launch an instance from the domain controller custom AMI during the restore process, the instance will be managed by AWS Systems Manager for the automation. It also sets the AmazonProvidedDNS as the forwarder to enable proper name resolution.
#Install Window Server Backup Feature
Install-WindowsFeature Windows-Server-Backup 

# Create new folder to store the backup script
New-Item -Path C:\AD_Disaster_Recovery_Scripts\ -ItemType Directory -Force

# Create and save the backup script to the folder
@'
# Configure Backup Parameters
$Policy = New-WBPolicy
$BackupLocation = New-WBBackupTarget -VolumePath D:
Add-WBSystemState $Policy
Add-WBBackupTarget -Policy $Policy -Target $BackupLocation
Set-WBVssBackupOptions -Policy $Policy -VssCopyBackup

Write-output "Start System State Backup job"
Try {
    Start-WBBackup -Policy $Policy -Async -Force
}   Catch [System.Exception] {
    write-output "unable to start system state backup"
}

# Check running backup job.
Get-WBJob
'@ | Set-Content -Path "C:\AD_Disaster_Recovery_Scripts\SystemStateBackup.ps1"

# Create Scheduled Task to run the backup script at regular intervals.
$taskAction = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "C:\AD_Disaster_Recovery_Scripts\SystemStateBackup.ps1"
$taskTrigger = New-ScheduledTaskTrigger -Daily -At 1am
$taskName = "SystemStateBackup"
$description = "Performs system state backup every day at 1am"

# Register the scheduled task"
Register-ScheduledTask -TaskName $taskName -Action $taskAction -Trigger $taskTrigger -Description $description -User "System" -RunLevel "Highest"
write-output "Scheduled Task name SystemStateBackup created" 


# Adding route to EC2 meta-data service if OS is 2016 or 2019
@'
$OSVersion = (Get-WmiObject -class Win32_OperatingSystem).Caption
if ($OSVersion -match "2016" -or $OSVersion -match "2019") {

try {
    Import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1; Add-Routes
    Write-Output "successfully added route to EC2 metadata service"
    }catch [System.Exception] {
    Write-Output "Unable to added route to EC2 metadata service"
    Write-Output ($Error[0].Exception)
    }
}

Write-Output "Setting DNS as authoritative for the domain"                                                 
try {
    Get-NetAdapter | Select-Object InterfaceAlias , InterfaceIndex
    $IntIndex = Get-NetAdapter | where {$_.ifDesc -notlike "TAP*"} | foreach InterfaceIndex | select -First 1
    Set-DnsClientServerAddress -InterfaceIndex $IntIndex -ResetServerAddresses
    Set-DnsClientServerAddress -InterfaceIndex $IntIndex -ServerAddresses ("127.0.0.1")
    Write-Output "Successfully set DNS as authorative for the domain"
} catch [System.Exception] {
    Write-Output "unable set current server as authoritaive DNS server for the domain"
    Write-Output ($Error[0].Exception)
}
                      
Write-Log "Setting DNS forwarder to AmazonProvidedDNS"
try {
    Set-DnsServerForwarder -IPAddress "169.254.169.253" -PassThru
    Write-Output "Successfully set DNS forwarder to Amazon Provided DNS"      
}  Catch [System.Exception] {
    Write-Output "Unable to set DNS forwarder to Amazon Provided DNS"
    Write-Output ($Error[0].Exception)
}

'@ | Set-Content -Path "C:\AD_Disaster_Recovery_Scripts\addroutes.ps1"

# Create a new task action
$taskAction = New-ScheduledTaskAction `
    -Execute 'C:\Windows\System32\cmd.exe' `
    -Argument '/C C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Unrestricted -File "C:\AD_Disaster_Recovery_Scripts\addroutes.ps1"'

# Create a new trigger at startup
$taskTrigger = New-ScheduledTaskTrigger -AtStartup


# The name of your scheduled task.
$taskName = "AddEC2Routes"

# Describe the scheduled task.
$description = "Fix Windows Route table to access the EC2 metadata when using custom Windows AMI to create a instance in a new subnet."

# Register the scheduled task
Register-ScheduledTask `
    -TaskName $taskName `
    -Action $taskAction `
    -Trigger $taskTrigger `
    -Description $description `
    -User "System" `
    -RunLevel "Highest"

Write-Output "Scheduled Task name AddEC2Routes created"

Note: Microsoft recommends a daily backup up of at least two writeable domain controllers in each domain of your AD infrastructure.

STEP 2: Protect the Amazon EBS volume and domain controller instance using AWS Backup

To protect the volume containing AD data that you configured in step 1, set up AWS Backup to take snapshots of that volume at regular intervals. This step is critical to ensure that you have multiple copies of the backup volume. AWS Backup is a fully managed service that makes it easy to centralize and automate data protection across AWS services, in the cloud, and on premises. Next, you will also create AMI backups of the domain controller instance itself. An AMI backup of the instance ensures that we are restoring to the same operating system instance when performing the restore operation. During the restore process, we will first launch an Amazon EC2 instance from the AMI backup, run a system state restore, and then perform additional AD recovery operations.

Complete the following steps to schedule snapshots of the Amazon EBS volume containing system state data and AMI backup of the domain controller instance using AWS Backup:

  1. Navigate to the AWS Backup console and select Backup Plans.
  2. Select Create Backup Plan and select Build a new plan, as shown in Figure 2.
  3. Enter a name each for Backup plan name and Backup rule name.
  4. For Backup frequency, select Daily, and for Retention, select a value.Note that the value you select should not be more than the tombstone lifetime. A backup that is older than the tombstone lifetime is invalid and cannot be used to restore AD. See Microsoft documentation for details. Also, when setting the backup time, take into consideration the daily system state backup time you set in step 1. You want the system state backup to complete before AWS Backup starts the snapshot backup of the Amazon EBS volume. In my example, I have set up system state backup to occur at 1:00 A.M. and AWS Backup to run at 5:00 A.M.
  5. For Copy to Destination, select your desired AWS Region if you would like to create cross-region or cross-account copies of your recovery points.
  6. Click Create plan.

    Screenshot of creating a new AWS Backup Plan
    Figure 2: Create a new AWS Backup Plan

     

  7. Select Backup plans and select the plan you just created.
  8. Select Assign resources, provide a Resource assignment name, and select Include specific resource types
  9. Under Select specific resource types, select EBS and then select the EBS volume containing the system state data.
  10. Select Assign resources.
  11. Next, repeat steps 1 to 6 above to create a second AWS backup plan to take AMI backups of the domain controller instance. For the frequency, select monthly and align it with your existing schedule for applying Windows patches to the domain controller. For example, if you have an existing schedule to install Windows patches on your domain controllers on the 4th Saturday of each month, then you can specify 4th Sunday of each month within AWS Backup. This ensures that the AMI contains the patches released for that month. However, if you use an backup AMI of a previous month during the AD restore/dry run process, remember to install the missing Windows patches to the instance as necessary.
  12. After creating the AMI Backup plan, select the plan, select Assign Resources, select Include specific resource types, select Select specific resource types, select EC2 and then select the domain controller EC2 instance.

 You have now completed the steps for backing up your AD data.

Running DR drills for your AD.

As part of your AD DR strategy, you should carry out regular DR drills. This helps verify that the backups are viable and ensures that you are prepared in the event of a disaster. This section walks through the steps to restore AD from backup.

 STEP 1: Restore Amazon EBS containing AD data from AWS Backup

In this step, you will restore from AWS Backup the Amazon EBS snapshot you backed up previously that contains the system state backup. When you restore an Amazon EBS snapshot, AWS Backup creates a new Amazon EBS volume that you can attach to your Amazon EC2 instance. You will use the restored volume to recover AD for your DR drill.

Complete the following steps to restore the Amazon EBS volume that contains the system state data from AWS Backup:

  1. Open the AWS Backup console and in the navigation pane, select Protected Resources.
  2. Select the volume ID, select a Recovery point ID, and select Restore
  3. On the Restore backup page, select an availability zone and then select Restore backup, as shown in Figure 3. Make a note of the availability zone you selected, as you will need this in the next step. In my example, I have opted to restore the volume to us-east-1a.

Screenshot of restoring EBS Volume containing AD data from AWS Backup
Figure 3: Restore EBS Volume containing AD data from AWS Backup

STEP 2: Recover AD forest in an isolated environment

With the Amazon EBS volume restored from AWS Backup, you then need the domain controller backup AMI to use for the restore process. Follow these steps to locate the AMI backups of the domain controller you previously setup using AWS Backup:

  1.  Navigate to the Amazon EC2 console and select AMIs from the left navigation bar.
  2. Locate and make a note of the domain controller AMI you want to use for the restore procedure. The AMI name of an AMI taken by AWS Backup begins with “AwsBackup_<instanceID>”.

Now, with the Amazon EBS volume containing system state data and the backup AMI of the domain controller obtained from AWS Backup, you are now ready to recover AD. During a DR drill, restore AD to an isolated environment so your production environment is not impacted. To restore AD in isolation, you will create a new VPC, use the backup AMI to launch a new Amazon EC2 instance onto the VPC, attach the restored Amazon EBS volume to the Amazon EC2 instance, and perform system state recovery from the attached volume to the instance. You will then need to perform a series of AD forest recovery actions to complete the AD recovery process. See the Microsoft documentation for more details. This process can be time consuming, especially if you are going to be carrying out regular DR drills for your AD environment.

To make this faster and easier, I have provided an AWS CloudFormation template that you can deploy on-demand to build out the isolated environment, run the system state recovery, and performs the forest recovery actions automatically.

The Cloudformation template does the following:

    1. Builds out an isolated networking environment – new VPC, subnets, NAT gateways, IGW, etc.
    2. Uses the specified backup AMI to launch an instance in the isolated environment
    3. Attaches and restores system state data from the backup EBS volume specified in the template
    4. Performs an authoritative restore of SYSVOL. For more information, refer to the Microsoft documentation.
    5. Seizes the FSMO roles.
    6. Uses the ntdsutil.exe command-line tool to perform AD metadata cleanup of all domain controllers in the AD database, except for the one on which the command is being run.
    7. Removes all DNS records containing any of the other deleted domain controllers.
    8. Configures the Windows Time service.

Complete the following steps to deploy the AWS CloudFormation template to restore your AD in the isolated environment:

  1. Download the CloudFormation template.
  2. Navigate to the AWS CloudFormation console.
  3. For Create Stack, select With new resources (standard).
  4. For Template source, select Upload a template file. Select Choose file, select the template you downloaded in step 1, and select Next.
  5. On the Specify stack details page, the template pre-populates most of the entries. Enter the Volume ID of the Amazon EBS volume and the domain controller backup AMI you restored from AWS Backup. When specifying an availability zone for subnet 1, make sure it matches the availability of the Amazon EBS volume you noted in the previous section, as shown in Fig 4. This ensures the domain controller instance can mount the restored EBS volume. Complete the other details and select Next.

Note: I tested and recommend using instances based on the AWS Nitro System. Also, the automation uses the latest version of system state backup on the attached Amazon EBS volume. To use a different system state backup version, restore a different version from AWS Backup as outlined in step 1.

CloudFormation template parameters
Figure 4: CloudFormation template parameters

  1. On the Configure stack options page, select Next
  2. On the Review stack name page, check the box next to I acknowledge that AWS CloudFormation might create IAM resources with custom names and select Submit.
  3. When the AWS CloudFormation stack creation is complete, open the AWS Systems Manager Automation console and wait for the automation to complete the System State restore operation.
  4. Update the security group of the bastion Amazon EC2 instance to allow your IP address and logon with RDP. From the bastion instance, log on to the restored domain controller instance using RDP and open Event Viewer.
  5. Review the DFS Replication event logs for Event ID 4602 which shows SYSVOL replication has been initialized. You should review the other logs and carry out additional tests to confirm the health of your restored domain controller. Figure 5 shows a screenshot of the DFS logs in my restored domain controller. For more information, see AD Forest Recovery – Verify Replication.

.

DFS Replication log showing SYSVOL initialization on restored DC
Figure 5. DFS Replication log showing SYSVOL initialization on restored DC

Note: Carry out additional checks to verify the health of the restored Domain Controller after the forest restore. For more information, refer to the Microsoft documentation.

  1. You may then deploy new additional domain controllers for your domain as needed.

 

Cleanup

To delete the resources created by the AWS CloudFormation template, go to the AWS CloudFormation console. Select the stack you created, and then select Delete.

Conclusion

Active Directory is increasingly a target for ransomware attacks and implementing a DR strategy for your AD infrastructure is critical more than ever before. In this blog post, I showed you how you can use AWS to implement a DR solution for your self-managed AD infrastructure. And with the CloudFormation template I provided, you can periodically run drills for your AD with little effort and without impact on production.

On a final note, you can offload the undifferentiated heavy lifting of managing AD DR by migrating to AWS Managed Microsoft AD. AWS Managed Microsoft AD provides you with a simple, fully managed directory services experience so you can focus on your business and your customers.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.

TAGS: ,
Tekena Orugbani

Tekena Orugbani

Tekena is a Sr. Specialist Solutions Architect at Amazon Web Services based in Virginia. Tekena joined AWS in 2017 and focuses on helping customers architect, migrate and modernize their Microsoft workloads on the AWS Cloud. Outside work, Tekena enjoys hanging out with his family and watching soccer.