How To Manually Join an EC2 Instance to a Cloud Directory Service
Brien Posey explains how joining a cloud-based directory service is very similar to joining an on-premises Active Directory forest.
Those who wish to create a cloud-based Active Directory environment within Amazon Web Services (AWS) don't have to manually create domain controllers in the cloud. Instead, Amazon has its own cloud-native Microsoft directory service. As I've explained in a previous blog post, setting up an AWS directory service is a relatively simple process, and you can even seamlessly join new virtual machine instances to the directory service as a part of the instance-creation process. But what about your existing VM instances?
Joining a cloud-based directory service is very similar to joining an on-premises Active Directory forest. In fact, the requirements for doing so are essentially identical. For starters, the VM instance that you plan to join to the AD domain will need to be running a guest OS that supports being domain-joined. Second, the VM instance will require a path of communication to the AD environment. Finally, the instance that you are domain joining will need DNS name resolution capabilities within the AD environment.
The initial requirement, the one stipulating a compatible guest OS, is kind of a non-issue. Almost all modern Windows OSes can be domain-joined (the notable exceptions being Home Edition and Windows 10 S).
The second requirement is that the guest OS will need to be able to communicate with the AD environment. Meeting this requirement is easier than it sounds. When you deploy the Directory Service, AWS asks you to pick a Virtual Private Cloud (VPC) and two subnets, as shown in Figure 1. Any VM instance residing on the same VPC and subnet should have no trouble communicating with the Directory Service.
The third requirement is that your VM instance needs to be able to perform DNS name resolution within the AD environment. To accomplish this, log into the AWS console, and go to the Directory Service dashboard. Next, click on your Directory Service. As you can see in Figure 2, the primary and secondary DNS servers used by the Directory Service are listed within the Details section. Be sure to make a note of these DNS servers.
Once you've written down the IP addresses of the DNS servers, log into the VM instance that you plan to join to the Directory Service, and then reconfigure its networking properties through the Windows Control Panel. By default, the instance is configured to get its IP address and its DNS server configuration from a DHCP server. You will need to hard code the DNS server addresses in the instance's TCP/IP configuration (it's OK to continue to use a dynamically assigned IP address).
Once you've pointed Windows to the correct DNS servers, go ahead and close out the Control Panel. The last thing you'll need to do is perform the actual domain join. This process works similarly to what you're probably used to, but with one caveat.
As you may recall, when you set up the Directory Service, you had to provide AWS with some basic information, some of which is shown in Figure 3. You'll need to use this information to complete the domain join.
When you attempt to join Windows to the Directory Service, you'll be asked the name of the directory that you wish to join. You'll need to use the name that you entered into the Directory DNS field, shown in Figure 3.
Assuming that Windows is able to successfully resolve the domain name, you'll then be asked for a set of administrative credentials. As you'd probably expect, you'll need to use the password that you supplied in Figure 3. What you might not expect, is that you won't be able to use the domain Administrator account. AWS blocks the Administrator account, and requires you to instead use an account named Admin.
After entering your credentials, the instance will be domain-joined.
About the Author
Brien Posey is a 21-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.