Windows 2012: Auto Domain Join using EC2Config and Sysprep
Description
Sysprep is a utility used by Microsoft Windows servers as a way to strip all of an images unique properties such as the server SID, the server name, the event logs, specific drivers, etc.. from an image, allowing you to then bundle the operating system in a way that will allow a new server to be auto configured upon its first boot when instantiated using the bundled image. Sysprep allows a windows server to set properties like the host name, joining an Active Directory domain, and setting other unique properties automatically, on first boot, that usually take configuration time from a systems administrator when a new server is provisioned.
The purpose of this tutorial is to create a Windows based AMI that has been packaged properly using EC2Config combined with the Microsoft Sysprep utility. On instance provisioning, the instance will perform the specified Sysprep tasks, and then automatically join the instance to your organizations Active Directory Domain. Automatically joining a domain in AWS can be accomplished in a variety of ways. The recommended way would be to use Secure Systems Manager (SSM) to automatically join a domain that has been extended via the the use of one of the AWS AD Directory Services or the AWS AD connector. However if your organization doesn't utilize either SSM, AD Directory Services, or the AD Connector proxy then we still can enable the automatic domain join capabilities of Windows by using traditional methods.
Driver Removal
When you run Sysprep with the EC2Config service, the system prevents drivers from being removed because the PersistAllDeviceInstalls setting is set to true in the C:\Program Files\Amazon\Ec2ConfigService\sysprep2008 file by default. This file is later referenced and utilized as the unattend.xml file used during the Sysprep provisioning process.
Pre-Requisites
1. Active AWS Account:
As the purpose of this tutorial is to provide a way for Windows based instance launches to automatically join an Active Directory domain, we will need an active AWS account that we can log into in order to both create a Syspreped Server AMI, as well as test the auto Domain Join upon instance instantiation.
2. Active Directory Domain Controller:
In order to perform the following steps, access to an Active Directory Domain Controller (AD DC) is required. All of the steps outlined in this tutorial will be performed on a standalone Windows server image, that will enable the image to automatically join the Active Directory domain on instance launch.
3. AD Service Account:
The third thing that we will need is a service account that will has been provided rights to perform domain join operations. If a service account already exists, then your ready to go. If there is currently no service user account, or you wish to start with a fresh service user account, then follow the steps outlined here
Secrets Manager Credentials
Because we want to enable our newly provisioned Windows instances to possess the ability to automatically be joined to the domain on launch, and because we don't want to hard code the service account credentials into a file on the image, we are going to store our credentials instead, in the Secrets Manager service. Secrets Manager provides an encrypted store that securely stores credentials or other data, while still allowing authorized resources to easily retrieve those credentials or data easily. In order to store the service account credentials, follow the tutorial found here to store a secret containing a ServiceAccount and Password key with their appropriate values. Once you have created the secret, notate the name you selected for the secret, it will be used in a later step.. In the Secrets Manager Document, the secret name for example was Windows/ServiceAccount/DomainJoin.
Creating an EC2 Role for AD
The next thing we need to do is to create a custom policy, and a new role that we will assign to our Windows EC2 instances that we are launching. The policy that will be included in the role, will simply allow the launched EC2 instance access to the Secrets Manager service which will use later in this tutorial. The Secrets Manager is where we are storing our Active Directory Service Account Credentials as noted in the previous step.
1. Create Custom Secrets Manager Policy:
In order to create a Role that our Windows EC2 instances will use, first we need to construct a custom managed policy that will allow read only access to the Secrets Manager Service. By default the only Secrets Manager policy that AWS provides is a Read/Write Policy. Because we want to be as restrictive as possible, we need to create a custom policy that will allow Read Only access. In order to create the policy, follow the steps outlined in the Creating Policies Tutorial Found Here.. Construct the policy to allow all List and Read operations on the Secrets Manager service.
2. Create Custom EC2 Role:
Now that we have our Policy, Follow the steps outlined in the Creating Roles Tutorial Found Here to create a custom EC2 role that will utilize the policy that we just created. When creating the Role, Choose EC2 as the service, then choose the new custom policy that we created in the last step as the policy to be applied. Finally Review and Create the new Role.
Instantiate Windows 2012 R2
The next step will we will need to perform is to launch a Windows Server 2012R2 or Prior EC2 Instance. This instance will become the base image that we will use to Sysprep and prepare for automatic domain registration upon launch.
1. Log into your AWS account:
Open a browser window and visit the AWS Console Page
2. Locate and navigate to the EC2 Service:
From the top left side of the navigational menu bar, click on the Services menu, and then choose EC2 by either navigating to the 
section of the listed services, or by typing the first few letters of the service name in the search box, and then choosing it from the filtered list.
3. Launch Windows 2012 R2 Instance:
First we need to launch an Instance of using the Windows 2012R2 or Lower AMI. To do this, from the EC2 dashboard click the Launch Instance button. In the AMI selection view, choose an AMI containing Windows Server 2012 or a version prior to 2012R2. For the rest of the settings you can choose whats appropriate and launch the instance.
Windows 2016 Instances:
The process for Windows Server 2016 is slightly different then this process. The tutorial to Sysprep on Windows Server 2016 or later versions can be found here.
Apply Custom Role
Be sure that during the launch process you select the custom Role that we created earlier to be applied to the instance. If you forget to perform this step, then your instance will not be able to retrieve the service account credentials from the Secrets Manager, and the domain join operation will fail. If you forget to select the Role during the creation process, then the role can be added and/or modified post launch from the EC2 dashboard.
DC Security Group
Active Directory requires that the following ports are open to allow DC to DC communication on a domain controller. Ensure that you have a security group set to allow traffic to the required ports from our VPC. To keep things simple, we will construct a single security group that allows access from our local subnet, and ensure that it is applied to our domain controller(s). This will ensure any new computer that we provision in our VPC will be able to connect with Active Directory.
| tcp/25 | SMTP |
| tcp/42 | WINS |
| tcp-udp/53 | DNS (TCP used for Zone Transfers, UDP for standard queries) |
| udp/67 | DHCP |
| tcp-udp/88 | Kerberos |
| udp/123 | NTP |
| tcp/135 | RPC, Replication |
| tcp-udp/137 | NETBIOS |
| udp/138 | DFS, Group Policy |
| tcp/139 | NetLogon, User Authentication |
| tcp-udp/389 | LDAP |
| tcp-udp/445 | SMB, CIFS, SMB2, NetLogin |
| tcp-udp/464 | Kerberos modify password |
| tcp/636 | SLDAP |
| udp/2535 | DHCP |
| tcp/3268-3269 | LDAP, GC, Replication |
| tcp/3389 | RDP |
| tcp/5722 | File Replication |
| tcp/9389 | AD-DS Web, SOAP |
| tcp-udp/49152-65535 | LDAP service Response ports |
Windows RDP Connection Details
Now that we have successfully launched our new Windows Server 2012R2 or prior version of Windows, we need to connect to the instance to configure it, prep it for domain join on instantiation, Sysprep it, and then create an AMI from the image for additional Windows Server provisioning.
1. Select Windows 2012R2 Instance:
Once the instance has been launched, from the EC2 dashboard, select the instance that was just launched from the Windows Server 2012R2 AMI. Once selected, from the Actions menu, choose Connect.
2. Get Password:
Once the Connect To Your Instance modal windows appears, click the button that says Get Password
3. Decrypt Password:
The password that is set on the Administrator account is a hash of the PEM key that was selected when the instance was launched. In order to decrypt the password that is set on the instance, either upload the PEM key used, or copy your private key value and paste it into the dialog box. Once pasted, click the Decrypt Password button.
4. Display Connection Details:
The last modal should display the connection information in its entirety. It also gives you the option of downloading the RDP file that has all of the connection information pre-populated. Once you have copied the details, or downloaded the RDP connection file, click the Close button.
Build your Windows 2012 Image
Now that we have the connection details, we can use our RDP application of choice to initiate a connection to the server. Once connected to the server, install the applications and configurations required for your image. Once the image is updated, with all applications installed and configured, it's time to prepare the image to be sysprepped or bundled for distribution.
1. Check for AWS PowerShell Tools:
One component that will need to be installed for later use is the AWS PowerShell tools. The PowerShell tools are required to make the request for the credentials stored in the Secrets Manager that the domain join process will utilize to perform the domain join. By default if you are using an image based off one of the AWS provided Windows AMI's then the PowerShell tools should be already installed. We can check to ensure that its installed by running the following cmdlet from the Windows PowerShell console:
Get-Module -ListAvailable *AWS*
PowerShell AWS Tools Installation:
If the PowerShell AWS tools are not installed, you can follow the documentation found here to install and set up the AWS PowerShell tools for Windows.
2. Administrator Credentials:
Once we have verified that the AWS PowerShell Tools are correctly installed, we need to devise a strategy around the local Administrative Login. When you sysprep the image, the Administrator password will be changed even if you select the option to keep the configured password. During the EC2Config Sysprep operation the Administrator password is purged on any server version after 2008. In order to ensure that we always have a local administrator account to use to login and troubleshoot the instance, create a new user, and make that user a member of the Administrators group. The Sysprep process will not alter any other local users other than the Administrator User account. Because we are configuring a secondary Administrator we could change the Sysprep configuration to disable the Local Administrator password if we so desired. For now, create a new account, and add that account to the Administrators group. Be sure that the password set on the user is documented somewhere safe in an encrypted format.
3. Configure DNS:
Another thing that we will want to optionally do is to set the server images DNS settings to point its Primary DNS to our Active Directory Domain Controller. This will ensure that when the instance makes the request to join our domain, that it can resolve both the domain name as well as requests for domain service records from our domain. In order to do this, go into the Network Adapter Settings, right click on the primary adapter and select properties, then from the adapter properties, click on Internet Protocol Version 4(TCP/IPv4) and once highlighted, click on the Properties button. Last, in the General tab, leave the top section set to Obtain an IP address automatically, on the bottom, choose the option Use the following DNS server addresses and input the Preferred and Alternate DNS server settings. Unless you are specifying multiple domain controllers, the Alternate DNS server should be pointed to your VPC's default IP of x.x.x.2.
Sysprep DomainJoin Script
Once we have verified that we have the AWS PowerShell tools install, next we need to add a script to our Windows instance image that will be called during the provisioning process when we launch new instances to perform the actual domain join operation.
1. Open the PowerShell Editor:
In order to add our script, lets first open the installed PowerShell Editor, or an editor of your choice. From the start menu, type PowerShell to search for all things powerShell related and from the list of options, choose the PowerShell Integrated Scripting Environment (ISE).
2. Create and Save the DomainJoin Script:
Now that we have the editor open, we can paste our script into the editor and save the file so that its saved on the instance image. Copy the script contents below and paste it into the PowerShell ISE. Once pasted, Save the file as:
C:\Program Files\Amazon\Ec2ConfigService\Scripts\DomainJoin.ps1
# Domain name and the tld. In this example the domain is starfleet.aws $domain_name = "starfleet".ToUpper() $domain_tld = "aws" $secrets_manager_secret_id = "Windows/ServiceAccounts/DomainJoin" # Make a request to the secret manager $secret_manager = Get-SECSecretValue -SecretId $secrets_manager_secret_id # Parse the response and convert the Secret String JSON into an object $secret = $secret_manager.SecretString | ConvertFrom-Json # Construct the domain credentials $username = $domain_name.ToUpper() + "\" + $secret.ServiceAccount $password = $secret.Password | ConvertTo-SecureString -AsPlainText -Force # Set PS credentials $credential = New-Object System.Management.Automation.PSCredential($username,$password) # Get the Instance ID from the metadata store, we will use this as our computer name during domain registration. $instanceID = invoke-restmethod -uri http://169.254.169.254/latest/meta-data/instance-id # Perform the domain join Add-Computer -DomainName "$domain_name.$domain_tld" -NewName "$instanceID" -Credential $credential -Passthru -Verbose -Force -Restart
PowerShell DomainJoin Script:
To see a detailed script explanation of this script and the actions performed within it, please see the Windows DomainJoin PowerShell Script documentation
3. Configure the DomainJoin Script to run on boot:
Next, now that we have the domain join script saved, we need to ensure that it is called during the provisioning phase of our EC2 instance launch. To ensure that the script gets fired off as part of the post Sysprep provisioning phase, locate and open the PostSysprep file located in the C:\Program Files\Amazon\Ec2ConfigService\Scripts directory. This file is called by the C:\Windows\Setup\Scripts\SetupComplete.cmd post sysprep setup. This file can be opened with something simple like notepad. Once opened, add the following command to the very end of the PostSysprep file.
@REM ***************
@REM Runs the Domain Join script to join this box to the Active Directory Domain
powershell.exe -noexit -ExecutionPolicy Bypass "& 'C:\Program Files\Amazon\Ec2ConfigService\Scripts\DomainJoin.ps1'"
PostSysprep file Syntax:
Make sure to double check the path and file name of the DomainJoin Script that we created earlier. If you named the script anything other then DomainJoin.ps1, or if you put it in a different path then C:\Program Files\Amazon\Ec2ConfigService\Scripts\ then update the powershell.exe command statement above accordingly.
Sysprep Using EC2Config
Now that we have the new domain join script and execution command configured, the next step is to bundle the OS for AMI distribution. To do so, first we have to kick off the Sysprep process to strip all of the unique properties of the image and complete the final bundling action.
1. Open the EC2Config Properties Tool:
In order to start the Sysprep process, first we must set a few configuration options in the EC2Config properties tool, that will define how our image is bundled and how Sysprep will operate when launched. From the Windows Start menu, type EC2 and look for the EC2ConfigService Settings application. Once found, launch the settings application so that we can set our EC2Config properties.
2. EC2Config General Properties:
Once the EC2Config Service Property Tool opens, you will see 4 tabs across the top of the tool. General, Image, Storage, and Support. First lets set our General options. First select the User Data property by clicking the check box to enable UserData execution for the next start. This will ensure that we can still utilize usage of User Data scripts post packaging. Also ensure that Wallpaper Information is checked. This option allows the instance information overlay to be displayed on top of the configured wallpaper.
Wallpaper Information:
3. EC2Config Storage:
Next, we are going to skip the Image tab for a min, and go instead to the Storage tab. Choose the Root Volume option to Dynamically extend the OS Partition option. This will ensure that if we launch an instance with a bigger root volume then our image currently has configured(30GB), that the excess storage on the root volume can be utilized by the launched instance. Also ensure that the Initialize Drives default option is also selected. This option will ensure that any extra EBS volumes that are added to an instance launched from this base image will automatically be initialized and mounted on instance provisioning. Another optional setting is Drive Letter Mapping which ensures that Windows maps volumes attached to the instance, to an administrator defined drive letter so that drive letters always contain the same specified volume for every instance launched off of the base AMI. The operation will fail if the drive letter you are attempting to assign is already assigned. To keep things simple, and because we are only creating a base with a single volume, we will not be using this setting for the purpose of this walk through.
4. EC2Config Image:
We don't need to modify any settings in the Support tab, so lets go back to the image tab where we can set our final options and start the Sysprep operation. In this tab, choose the appropriate Administrator Password setting. For this example, because we created a secondary Administrator, and we know that the Keep Existing option will not work because we are running a version of Windows newer then 2008, and we also don't want to store an unencrypted password in the Unattend.xml file, we will choose the Random option. Choosing Random, will tell the image to randomize the password based on the hash of the PEM file that we selected on launch. The password can then be un-encrypted from within the AWS console, just like it was in the Windows RDP Connection Details section above. Once set, click the Shutdown with Sysprep button to start the Sysprep bundling process. Once you click the Shutdown with Sysprep button, a dialog will appear asking you to confirm that you want to start the Sysprep bundling process. Click Yes, and then wait for Sysprep to run through its bundling process.
Administrator Password Setting
If the Specify option is selected for the Administrator Password, the specified password will be stored in the Sysprep answer file in its unencrypted clear text form.
If the Keep Existing option is selected, note that the function will NOT work in Windows 2008 or greater when running Sysprep because Sysprep will wipe the existing local Administrator password.
Windows Sysprep Stages
When you click the Shutdown with Sysprep button and confirm that you want Sysprep to package the image, you will see a command window kick off that shows Windows performing the sysprep bundle operations required to package up the Operating System. The instance will start Sysprep by running the ec2config.exe -sysprep command. This operation will read the content of the BundleConfig.xml file, located in the C:\Program Files\Amazon\Ec2ConfigService\Settings directory. This file includes configurable settings such as AutoSysprep, SetRDPCertificate, SetPasswordAfterSysprep, and PreSysprepRunCmd.
AutoSysprep - Indicates as to if you want to use Sysprep automatically
SetRDPCertificate - Sets a self signed certificate for RDP. This setting is not used with Windows Server 2008 or Windows Server 2012 instances because these operating systems can generate their own certificates
SetPasswordAfterSysprep - Sets a random password on a newly launched instance, encrypts it with the user launch key, and outputs the encrypted password to the console.
PreSysprepRunCmd - Sets the location of the command to run. The default behavior is to run the C:\Program Files\Amazon\Ec2ConfigService\Scripts\BeforeSysprep.cmd file.
Sysprep performs the following steps:
1. Generalize: The tool removes image-specific information and configurations. For example, Sysprep removes the security identifier (SID), the computer name, the event logs, and specific drivers, to name a few. After this phase is completed, the operating system (OS) is ready to create an AMI.
2. Specialize: Plug and Play scans the computer and installs drivers for any detected devices. The tool generates OS requirements like the computer name and SID. Optionally, you can execute commands in this phase.
3. Out-of-Box Experience (OOBE): The system runs an abbreviated version of Windows Setup and asks the user to enter information such as a system language, the time zone, and a registered organization. When you run Sysprep with EC2Config, the answer file automates this phase.
4. Sysprep Drivers NOTE: When you run Sysprep with the EC2Config service, the system prevents drivers from being removed because the PersistAllDeviceInstalls setting is set to true by default.
Create a Sysprep Image AMI
Once completed, your image instance will be in a stopped state. Before we are ready to start launching instances off with this base, we need to create an AMI (Amazon Machine Image).
1. Create Image:
In order to create a usable AMI, navigate back to the EC2 Console in your AWS Account, and from the EC2 dashboard, select the stopped instance. From the Actions Menu, Click on the Image menu option, and from the sub menu, choose Create Image.
2. Name the AMI:
Next, in the modal pop up window, Name the Image, and type an Image description. Once complete Click the Create Image button to begin the AMI creation process.
3. Wait for the AMI to Bake:
Once the Create Image button has been clicked, a confirmation window will pop up. You can click the link in the confirmation window to be brought to the AMI view where you can monitor the process of your AMI creation process. Once the Status of the image changes from pending to available, the AMI is ready to be used to launch new instances.
Provisioning Windows Instances
Once the AMI status changes from pending status to available, we can now test out our new AMI by launching off a new instance using that AMI as the base AMI. To so, from the EC2 dashboard, Click the Launch Instance button to launch a new instance. In the Choose an Amazon Machine Image (AMI) screen, select My AMIs from the left side menu. Then from the list of available AMIs, choose the AMI that we just created and click the Select button. For the rest of the Instance options, select the instance type, and instance details, and launch the instance like any normal instance launch. Be sure that in the Configure Instance Details section, choose the Secrets Manager RO Role that we created in an earlier step to ensure that then newly launched instance can talk to the Secrets Manager Service, in order to get the domain credentials needed to auto join this instance to the domain.
Secrets Manager Access
In order for the automatic Domain Join to work properly, newly provisioned instances of Windows will need to have access to the Secrets Manager Service. Instances MUST either be launched with a public IP, have access to a NAT or IGW, or you must have a Secrets Manager VPC Endpoint configured. There must be a way for Windows to reach the Secrets Manager Service or the Domain Join operation will fail.
Instance Instantiation Time
Note that newly provisioned instances may take 5ish minutes to come on-line fully after provisioning. When the instance launches, it will run through the Sysprep operation, join itself to the domain, and reboot. This process can take a little time to complete normally.
Verify Automatic Domain Join
Once the instance has initialized and come online, it should now run through the Sysprep operation, and then automatically join itself to the domain. We can verify that this operation occurred successfully in 2 different ways.
1. Active Directory Users and Computers Console:
The first is checking Active Directory Users and Computers on one of our Domain Controllers. To do this, first log into your AWS console, and navigate to the EC2 console. Once there, look for the launched instance and note the instance-id. During the Sysprep process, the PowerShell script launched a call to the metadata service and grabbed the instance's instance-id. It used this ID to name the computer in AD on provisioning. Next, RDP into one of your DC's and open the Active Directory Users and Computers console. From the console, navigate to the Computers UO, and look for the noted test instance's ID.
2. Windows Instance:
The second way that we can verify that the domain join occurred successfully would be to attempt to log into the instance using a domain user. Once logged in via a domain user or a local Administrator account, from the start menu, look for computer. Once located, right click and choose Properties
In the properties window of the Computer console, look at the Domain setting to ensure that its joined to the domain, and no longer part of the default Workgroup.
Cleanup
Perform the following steps in order to remove any computers that were automatically joined to the domain.
1. Terminate Windows Instances:
Log into your AWS console, and select any instances that were either used during the setup process outlined in this tutorial, or any other unwanted Windows instances. From the Actions menu, click on Instance State and then from the sub menu, select Terminate.
2. Remove Computer Objects from AD:
In your Active Directory Domain Controller, open Active Directory Users and Computers. From the main console, right click on the Computers OU, and from the list of computer objects, find and select the computer that has been terminated. Right click on the computer object, and from the available context menu, choose Delete. This will delete the object from Active Directory.
3. CleanUp Old Snapshots:
Next, navigate back to the EC2 console and click on Snapshots, browse through the list available Snapshots and select, any outdated or unwanted Snapshots that you want removed. Once selected, from the Actions menu, choose Delete.
4. CleanUp Old AMIs:
The last area we want to look is again in the AWS EC2 console. Navigate to the EC2 console and click on AMIs, browse through the list of available AMIs and select, any outdated or unwanted AMIs that you want removed. Once selected, from the Actions menu, choose Deregister.
Conclusion
By following the steps outlined in this tutorial, we should be all set to start provisioning Windows Instances without the administrative overhead of having to manually join them to our Active Directory domain !! Any new instance that is instantiated should automatically join our Windows Active Directory domain automatically at the time of provisioning.
Additional Resources
No Additional Resources.
Site/Information References
Windows Sysprep with AWS EC2Config Service
Configure a Windows Instance with AWS EC2Config Service
Create a standard AMI using EC2Config Sysprep