AWS Directory Service – Simple AD
April 16, 2018Just because you’ve started moving workloads into the cloud, doesn’t mean you can forget about Microsoft Active Directory. Many customers simply stand up their own domain controllers on EC2 instances to provide domain services. But if you’re moving to AWS, there are also some great services you can take advantage of to provide similar functionality. This post focuses on Simple AD is based on Samba4 and handles a subset of the features that the Microsoft AD type Directory Service provides. This service still allows you to use Kerberos authentication and manage users and computers as well as provide DNS services. One of the major differences between this service and Microsoft AD is that you can’t create a trust relationship with your existing domain, so if you need that functionality look at Microsoft AD instead. Simple AD gives you a great way to quickly stand up new domains and cut down on the things you need to manage such as OS patches, etc.
Deploy
To deploy Simple AD within your existing AWS VPCs, go to the Directory Service from the services menu.
When the Directory Service page opens up you’ll see several options available to you, but here we’ll stick with Simple AD. Locate Simple AD and click the “Set up directory” link.
First, enter a Directory DNS. This is a FQDN for your environment. I use “hollow.local” for my on-prem domain so I like to use something like sbx1.hollow.local for my sandbox cloud environment. You can optionally provide a NetBIOS name if necessary. Next, enter an administrator password. This will be your domain admin password and you’ll need this later to configure the infrastructure.
Next select a size. Simple AD comes in two sizes and the main difference is the number of objects the directory can manage. Small can handle about 500 users or 2000 objects and Large supports up to 5000 users or 20,000 objects. If you need more than this, consider Microsoft AD instead of Simple AD.
Lastly, select the VPC that a pair of domain controllers will be deployed in, and then select which subnets they should live in. Private subnets make a good location for this as most people I know don’t allow access to their domain controllers from over the Internet. Click the “Next” button.
The next screen shows you a review before you deploy. If it looks good, click the “Create Simple AD” button for the magic to happen in the background.
Once done you’ll get a status message that the directory is being created.
If you aren’t all about deploying this through the console, Simple AD can be deployed through CloudFormation so you can have even more Infrastructure as Code (IaC). Here is a quick snippet for doing the steps above through a CloudFormation Template in JSON format.
{ "AWSTemplateFormatVersion" : "2010-09-09", "Description": "Simple AD Service", "Parameters" : { "SimpleADPW" : { "Type": "String" }, "subnetID1": { "Description": "Subnet ID to provision instance in", "Type": "AWS::EC2::Subnet::Id", "Default": "" }, "subnetID2": { "Description": "Subnet ID to provision instance in", "Type": "AWS::EC2::Subnet::Id", "Default": "" }, "VPC": { "Description": "The VPC to deploy resources into", "Type": "AWS::EC2::VPC::Id", "Default": "" }, "DirectoryName" : { "Description" : "Unique Name for Directory", "Type": "String" }, "ADSize" : { "Description" : "AD Directory Size", "Type" : "String", "AllowedValues": [ "Small", "Large" ] } }, "Resources": { "myDirectory" : { "Type" : "AWS::DirectoryService::SimpleAD", "Properties" : { "Name" : { "Ref" : "DirectoryName"}, "Password" : { "Ref" : "SimpleADPW" }, "VpcSettings" : { "SubnetIds" : [ { "Ref" : "subnetID1" }, { "Ref" : "subnetID2" } ], "VpcId" : { "Ref" : "VPC" } }, "Size" : { "Ref" : "ADSize"} } } } }
Whichever deployment method you choose, it will take a bit to deploy but when done you’ll see a new directory listed in your portal. Select the directory that was created and you’ll see some information needed for the rest of this post. Specifically, you’ll want to take note of the DNS Address listed in the details page for the following section.
Modify DHCP Option Sets
You’ve deployed your domain controllers, but your clients will need to be reconfigured to use these two domain controllers for their DNS resolution. To provide this for the entire VPC, we’ll want to create a new DHCP Option Set and assign it to the VPC or VPCs that will use these Domain Controllers. Go to your VPC menu in the console and find the DHCP Options Set link. Create a new option set with the Domain name and DNS servers from your new Simple AD servers that we just created.
Once you’ve created the options set you’ll need to associate it with your VPC(s) so that new addresses are handed out with the appropriate settings. NOTE: You can only have one DHCP option set associated with at VPC at a time. To assign the new Option Set, select the VPC from the VPC mentu and click the actions button, then select the Edit DHCP Options Set link. You’ll then have a drop down to select your preferred option set.
As you can see my options set is applied to my VPC now.
Configure Roles
Before we start deploying member servers, we’ll need to create a role in the IAM console. This role will allow Simple Systems Manager (SSM or Systems Manager for short) the permission to join new EC2 instances to the new domain. To create this role, go to the IAM console and click on Roles. Click the “Create role” button.
When the create role window opens up select “AWS service” and then select EC2 under the service that will use the role. Click the “Next:permissions” button to continue.
In the permissions screen search for AmazonEC2RoleforSSM and select it. Click the “Next:Review” button.
Review the screen and give the role a name before click the “Create role” button.
Configure Management Hosts
You’re ready to go, but there isn’t an interface within the AWS console for you to create new users, groups etc like you normally would with Active Directory. This is a normal AD setup though so to manage our AD infrastructure we need to deploy a member server and then install our AD tools on it. So first, lets install a new member server that is joined to our new domain.
Deploy a new EC2 instance with a Windows server 2016 operating system on it as you normally would. But take notice that the console has a pair of subtle changes that need to be set as we deploy. In step 3 – Configure Instance you’ll see that we need to select the “Domain join directory” setting which should show as our new domain. Also, in the IAM role we need to select the role we created in the previous section. This is critical so that the machine can be joined to the domain as its deployed. Finish deploying your server.
Once the server has been deployed, it will restart to join the domain so wait a bit before trying to login to it. When its finished being deployed, connect to the instance over Remote Desktop and login with a domain user account. Up to this point the only user that has been created is “administrator” and the password you specified. Login to the member server and install the Lightweight Directory Service tools from Server Manager.
After the tools are installed, you’ll see your Active Directory tools like you’re accustomed to seeing. If you look in Active Directory Users and Computers (ADUC) you’ll notice some interesting things. Under the Domain Controllers Folder, two DCs will be listed in this folder for the Simple AD servers. These are the two DCs deployed for you through the AWS service.
Also, if you look in your Computers folder under aws, your member server will be listed.
Use Simple AD to Authenticate to the AWS Management Console
You can use Simple AD to do more things in AWS such as use your new domain to authenticate to the console. This limits the number of IAM users needed to be crated in the AWS console and hopefully helps to protect the environment even further.
First, we create an endpoint so that the AWS services can access the new directory. Enter a name for the endpoint and click the “Create Access URL”.
Click Continue to proceed with creating an endpoint. Note that you can’t change it later. Click Continue.
There are other services integrated with Simple AD but for this example, we’ll just use the Management Console. Navigate back to your directory service details and look towards the bottom of the screen under AWS apps & services. Click the AWS Management Console. When the new window opens click the “Enable Access” button.
Before the users and groups within AD can login to the console with their AD credentials, another Role needs to be created to provide access to the console. Go to the IAM console again and create another role. This time when you create a new role, choose the Directory Service as the service that will use the role.
You don’t need to assign any additional permissions (at this time) since we’re only demonstrating that this role can be used to authenticate. If you plan to use this role for users to have permissions to use anything in the console, those permissions need to be added. On the last step, give the role a name.
Once you’ve created the role, go back to your directory and click the Management Console Access link.
From here you’ll see a section for Users and Groups to Roles. A single Role will be listed which is what was just built in the previous few steps. Click the role to assign users from your Simple AD domain.
In the Add Users and Groups to Role window type a name. I added a new AD user for my own account in this example.
When done you’ll see your user(s) added to the directory.
Now, if you go to your endpoint URL (hint, the link is located next to the Management Console in your directory) you’ll be taken to a login page. Enter the Username and Password of the user that you added, and you’ve used your new Microsoft AD service and your directory store for the AWS Management Console.
Summary
You should have a working Simple AD service up and running in your AWS account and can now manage users in much the same way you’ve always managed them in AD. Now that you’ve got your domain working correctly, you can go about building all those apps you’ve been dying to get to in your cloud. And now they’ll have an authentication method that is secure and familiar to you but won’t have to worry about those pesky servers being patched, and managed. Happy coding!
[…] Simple AD – Simple AD is an option that provides a subset of Microsoft Active Directory services and is based on Samba 4. This service deploys a pair of domain controllers, with DNS, in a VPC across a pair of subnets for availability. The solution allows you to use this new directory as a Kerberos authentication source, but be aware that this solution doesn’t allow you to create a trust relationship with your existing domain if you have one. Think of this if you plan to setup a new domain for your AWS servers to belong to, but will still be managed separate from your on-premises domain. Simple AD has two sizes where a small directory can handle around 500 users / 2000 objects and a large size can manage 5000 / 20,000 objects. […]
Hi,
Great article.. I have Microsoft AD on my environment and It’s already configured to users from AD to have access to my AWS console. Something that I’m looking for is how can I execute all the necessary steps to add AD users/groups to my AWS IAM role thru API or cloudformation script. Do you have any idea how to do that?
Best Regards,
Swall Gemellaro
I have one Simple AD configured in a primary AWS account and a few Windows EC2 instances are joined to this Simple AD. I want to migrate my primary account Windows instances which are joined to the Simple AD of the primary AWS account to my secondary AWS account and need to join those instances with the Simple AD instance in the secondary account.
To do that I have created AMIs of the servers in the primary AWS account and shared the AMIs of the servers to my secondary AWS account.
After creating an instance from the shared AMI in the secondary account I am not able to login into the instance and not able to unjoin the instance from my primary Simple AD domain controller.
Please suggest me how to unjoin the instance from the primary domain controller in my secondary AWS account.
N.B I am not able to unjoin the instance in my primary AWS account those are production servers. Please suggest me is there any way I can unjoin the instance in secondary AWS account and joined the instance with the new domain controller.
Thanks for posting this Eric. However I am running into a problem during the “Configure Management Hosts” steps. When I access the Active Directory tool the “sbx1.hollow.local” folder does not show. When I attempt to change the domain to “sbx.hollow.local” I get the following error: “The domain “sbx1.hollow.local” could not be found because: The user name or password is incorrect” Any advice? Thanks again
That looks like your user/password is wrong. Also, note that sbx.hollow.local is used in MY lab. You should change your DNS to match your environment.
Thanks for the reply Eric.
I was making the mistake of logging in with the local admin user instead of the admin user for AD.
Eric, greate article!
I’m trying to to set up a similar network. My hangup is that I already have 30+ ec2 instances and a handful of RDS instances in my vpc. Some are in 10.0.1.0 and some are in 10.0.2.0 subnets for context. And I need AD to connect powerbi gateway to Analysis Services for more context!
I am not sure what will happen with dns resolution when I switch the dhcp option set for the domain (let’s call it xyz.local). Will the existing ec2 instances continue to resolve dns correctly? Do you have any insight on this?