Want to learn about your options for running Microsoft Active Directory on AWS? When you move Microsoft workloads to AWS, it is important to consider how to deploy Microsoft Active Directory in support of group policy management, authentication, and authorization. In this session, we discuss options for deploying Microsoft Active Directory to AWS, including AWS Managed Microsoft AD and deploying Active Directory to Windows on Amazon EC2. We cover such topics as how to integrate your on-premises Microsoft Active Directory environment to the cloud and how to leverage SaaS applications, such as Office 365, with the AWS Single Sign-On service.
This AWS managed service provides domain controllers that run on actual Microsoft Windows Server.
The service is compliance audited so it’s eligible to support your PCI, HIPAA, or SOC audited application.
You administer users and configure the directory including password policies, scale-out, and AD trusts.
The Standard Edition offers 1 gigabyte of customer usable storage for objects, and scripts. Enterprise Edition offers 17 gigabytes.
With users in AWS Managed Microsoft AD, you have the option to use Azure AD Connect with pass-through authentication to Azure AD.
This enables your Office 365 users to authenticate with their AWS Managed Microsoft AD credentials.
Click: Advanced organizations can even use Active Directory Federation Service for web applications.
Alternatively you can use AWS Single Sign-on, to enable your users to sign in to the AWS Management Console and a variety of web applications such as Office 365, G-Suite, Box or SalesForce.
In this case, you use Azure AD Connect to sync the users into Azure AD and configure O365 to use AWS SSO as an IdP.
But maybe you have an existing AD deployment in your data center or on EC2 in a VPC.
Click:
With AWS Managed Microsoft AD you can extend that infrastructure with AD trusts to reduce the footprint of AD infrastructure you manage.
Without synchronizing identities, your users can access Amazon applications and get the familiar Windows single-sign-on experience to applications in the AWS Cloud.
Click: In this case, you can use Azure AD Connect to sync your on-premises users into Azure AD. Instead of AD FS, your users can then sign in to O365 and other applications through AWS SSO using their existing on-premises AD credentials.
What I’m covering here is described in more detail in the tutorials you can find in the directory service documentation pages.
First you start in your AWS account.
<Click>will need a VPC in your account.
<Click> You will also need 2 subnets in your VPC that are in different availability zones.
<Click> If you have a corporate datacenter,
<Click> You can optionally link it to your VPC with Amazon Direct Connect or a VPN
<Click> You can also have an existing AD on-premises.
Later I’ll talk about how to use that AD infrastructure with AWS Managed Microsoft AD.
With the network infrastructure in place, you create AWS Managed Microsoft AD.
This creates 2 domain controllers in the same Availability Zones but in a VPC that AWS owns
<Click> These domain controllers get ENIs into your availability zones.
<Click> They also share an AWS security group that filters traffic to and from the DCs.
Because these AWS security groups are in your account, you can tailor them to meet your security requirements.
<Click> However you must use extreme caution. Mistakes can make your directory unusable in ways that AWS cannot identify.
After you create your directory, there are some best practices to follow
<Click> First, you should create DHCP option sets that tell EC2 to use AWS Managed AD for DNS
<Click> Second, you should create a separate AWS Security Group for your EC2 instances. Don’t re-use the security group that is intended for your DCs.
<Click> Next, create an IAM role that has the AmazonEC2RoleForSSM
<Click> You also will need a PEM file with a key pair to use for creating EC2 instances
<Click> Next you create an EC2 Windows instances using the PEM file, and join it to the AWS Managed AD domain.
You will sign into the instance and install the AD Administrative Tools
Once you join your EC2 instance, you can sign in using RDP with the ADMIN credentials for the domain you created
<CLICK> Then using the Server Manager, you will add Group Policy Management, AD DS and AD LDS Tools, and DNS Server Tools
<Click> When finished, you’ll verify that it added these tools to the instance
You will administer users, groups, and other aspects of the directory using the AD Administration tools on the EC2 instance.
You will configure features of the service such as trust configuration and schema changes from the AWS Console or APIs.
In the AD Users and Computers tool, you can open your domain (in this case the example.com domain).
In order to perform operational management of the directory, AWS retains ownership of the domain administrator. This account owns several containers within the root of the forest.
AWS also creates delegates administrative control or an organizational unit of the same name as your domain. Using your ADMIN account, you can add computers, users, groups, and other OUs within your OU.
You can also assign fine grained password policies to groups and users, and perform other normal administrative tasks on objects within your OU.
AD has a number of administrative functions that are frequently performed by the domain administrator, but can be delegated to others.
To enable you to perform those operations, we create a number of security groups that have been delegated rights, and we delegate your ADMIN account the permissions to add your users to these security groups.
You can add users to these groups that you created in AWS Managed AD, or users or groups that come from your existing on-premises AD if you implement a trust. I’ll cover more on that later.
To give you a little better context, I’ll walk through a demo of how to configure AWS Managed Microsoft AD.
<SWITCH Screens>
I’m signed in to my account and I’ve navigated to the AWS Management Console
First I’ll create a directory by going to the Directory Service Console
Switch to the existing directory
Show tour of tabs
Show EC2 seamless domain join
Switch to existing instance
Sign in with example\ADMIN
Show ADUC
One of the unique features of AWS Managed AD is its support for AD Trusts. AWS is the only cloud-provider who can use trusts to preserve the Windows single sign-on experience for your existing on-premises users, in hybrid-IT use cases.
Let’s take a look at how this works.
Lets say you have an existing on-premises deployment of active directory.
<click> In that directory you have all your user accounts and you have joined computers to the domain where you run workloads.
<click> Suppose you want to run some Windows workloads in the AWS cloud and you want the on-premises users to have access to those workloads. However, lets say you don’t want to manage AD infrastructure in the cloud and you want to keep management of the instances in the cloud to be isolated for management purposes.
<click> You could create an Active Directory in the cloud and join those instances to the domain in the AWS Cloud.
<click> You might even create some user accounts in the cloud for people who manage the instances.
To make it possible for the on-premises users to access the resources,
<click> you can create an Active Directory trust from the cloud to your on-premises directory.
<click> With the trust in place, the AWS Cloud becomes the trusting side of the trust, and the on-premises side becomes the trusted side.
<click> The direction of the trust is important because it defines the direction of access.
<click> In this case, the users in the AWS Cloud cannot access any of the resources in the on-premises network because they are not trusted by the on-premises AD.
<click> The users in the on-premises network have potential access to the resources in the trusting AD.
<click> It is only potential access because actual access requires that the trusting side resource administrator must establish permissions that enable the on-premises user to access the resource.
This kind of configuration is often called a resource domain, or a resource forest model.
What is great about a trust is that the user experience of accessing a resource through a trust is the same as accessing a resource in the same domain where the user account is.
You can take advantage of this model with AWS Managed Microsoft AD to migrate Windows workloads into AWS without the burden of managing all the AD infrastructure in the cloud.
Let’s take a look at the options for using a trust with AWS Managed Microsoft AD. (click)
AD is a forest that contains one or more domains.
The top of the forest is the root domain.
<click> The root domain can have child domains that share the same root domain name.
<click> A forest can also contain tree domains that consist of a tree-root and optionally child domains from the tree root.
Tree domains have a completely different root domain name, but they are part of the same forest and have inherent trust properties in the forest.
While AD provides this flexibility, more common patterns today consist of a single root domain forest with no child domains.
<click> AWS Managed AD provides a root domain forest only and does not support child domains.
When you use AWS Managed Microsoft AD as a resource forest, you have different options for how you configure your trust.
<Click> If you use a forest trust, then all users in all domains within the trusted forest have potential access to resources in the AWS Managed Microsoft AD domain.
However, with a forest trust, AWS Managed Microsoft AD does not know how to reach the domain controllers for any tree domains you might have in your on-premises forest. Therefore it is not able to verify the users that come from the tree domain.
AD provides two ways of solving that. One way is to configure Name Suffix Routing. With Name Suffix Routing, you specify the tree-root domain name and a DNS conditional forwarder that knows how to find domain controllers in that tree domain.
Another way is to use External Domain trusts.
With external domain trusts, you can establish a trust between AWS Managed AD and one or more individual domains in your on-premises forest.
These trusts establish trust to just between a two domains.
<click> In this case, AWS Managed AD has just one domain and it can create a trust to the tree-root domain.
In addition, you might not want all users from all child domains to have potential access to resources in your AWS Managed Microsoft AD.
<click> In that case, you can create additional external domain trusts to the root of your forest or child domains of your forest.
In this example, users in the highlighted domains have potential access to resources in the AWS Managed Microsoft AD forest, while users in other domains do not.
You can also combine forest trusts and external domain trusts.
However you should not create a external domain trust to a child domain to which you have a forest trust. This may cause some confusion for AD.
Lets look at how AWS applications and services use trusts in hybrid IT use cases.
<Click> RDS for SQL Server is a more traditional AD applications. It’s an AWS Managed AD service that is accessible via ENIs in your availability zone.
<Click> RDS for SQL can join to the AWS Managed AD domain, and then use Kerberos tickets it receives to authorize access to your data
<Click> With a 1-way trust from AWS Managed AD to your existing AD in your data center, your users in your datacenter can sign-in with their existing credentials and use RDS for SQL Server with a Windows integrated authentication experience.
The second kind of use is from AWS managed cloud-based applications.
<click> User access solutions like AWS SSO, WorkSpaces, and QuickSight by signing in over the Internet.
<click> These solutions use AWS Managed AD to provision users into the application, authenticate the users, and then share between users in the directory.
<click> In order to provision users and to share information with users that are in your datacenter AD, AWS Managed AD needs read access to your datacenter AD. Today, this requires a 2-way trust.
The trust from the datacenter to Managed AD gives Managed AD read access. The trust from Managed AD to the datacenter enables Managed AD to direct authentication to your datacenter.
Another unique capability of AWS Managed AD is how it makes security event logs available for your use.
Of course you can use the Event Viewer from a domain joined EC2 instance. But we also provide 2 other models.
First, we automatically maintain a 1 year window of event logs as part of our PCI compliance. These logs are kept by AWS and are available to you through a support ticket request. This model exists to support compliance audits.
However many companies want to be able to monitor what is going on in their directory in near real time.
As I showed earlier, you can go to the Networking and Security tab to configure log forwarding.
This feature enables you to fully customize the processing of your AWS Managed AD security event logs by forwarding the events to CloudWatch in an account of your choice.
We tried to make the set-up as easy as possible. If you don’t have any Cloudwatch groups, it defaults to creating one.
If you have an existing one, it defaults to using an existing Cloudwatch log group.
When configuring the CloudWatch, we automatically look for and use an existing resource policy that permits us to publish logs. If one doesn’t’ exist, we create a resource policy for you.
Once logging starts, you will have a different stream for each of the Domain Controllers.
This enables you to then use any tools that work with CloudWatch to monitor the security events from your domain controllers. This includes events from your users, as well as events related to any access by AWS operators in the unusual case that we have to sign in to correct an operational problem that automation failed to handle.
Another unique feature of the services is that it is the only managed AD that can be shared across multiple virtual networks.
Directory Sharing enables you to combine the isolation and billing benefits of accounts and VPCs with the benefits of managing access and EC2 Windows instances using a single managed AD.
Let’s dive a little deeper to understand how we changed things when we added this feature.
This slide illustrates how traditional AD applications access managed AD over an IP network path in their single account and single VPC.
<Click> However other AWS Managed applications don’t use an IP path through your network to reach the directory.
<Click> These applications use internal AWS APIs.
<click> The APIs enable the applications to discover DCs, join to the domain, and read the directory. Some of these APIs are also used by EC2, RDS, and WorkSpaces to find the DCs and join to the domain.
Suppose you have a second account and VPC where you have EC2 and you want it to use the directory.
Today you can use VPC peering to connect the second VPC to the VPC where you have AWS Managed AD. With that in place, you can manually join the instance to the domain.
<Click> But what if you want to take advantage of the automatic seamless domain join capability? EC2 needs to talk to an API in the second account.
To address this, we made it possible to share the interface from AWS Managed AD to other accounts within a region.
This solution enables you to create a shared services VPC where you install Managed AD.
<Click> You can then use VPC peering or a VPN to connect any other VPCs you have in the same account. EC2 can then find and use the directory.
<Click> You can then also share the directory to other accounts and connect VPCs from those accounts to the shared services VPC.
<Click> Currently, EC2 takes advantage of this to provide seamless domain join capability from any VPC within a region.
<Click> To share the directory, requires the directory owner to offer the directory to another account and the other account has to accept the offer.
If the directory is in the root account of an AWS Organization, no handshake is required for the acceptance.
If the account is outside of your organization, then the consumer must accept the offer.
There are some nominal charges to share a directory, and those charges go to the consuming account.
The amount of VPC connections you can have are limited by the number of route table entries in your VPCs. This makes it possible to share a single AWS Managed AD with up to about 100 other VPCs across multiple accounts within a region.
That completes the deep dive for today.
We covered what AWS Managed AD is
We went through an overview of the main use cases
I gave an introduction on how to install, administer and configure the directory
We walked through how AD trusts can be used between AWS Managed AD and your existing AD infrastructure with forest and external domain trusts.
We talked about how to use CloudWatch to monitor security events from your AWS Managed AD DCs
And we covered how you can share AWS Managed AD with multiple accounts and VPCs within a single region
I’ve included a set of reference links for you here.
Please remember to complete the session survey in the mobile app. By completing that, you will get access to the presentation when it gets published.