In this post, we are going to deep dive Active Directory on AWS. If you want to know Difference Between Azure AD vs Active Directory (AD) and AWS Directory Service you can first check my blog.
We are going to discuss deployment patterns and deploying, operating and securing Active Directory on AWS. Active Directory (AD) is a directory service for a broad range of directory-based identity-related services. Domain Controller is in charge of centralized domain management. It stores information about members of the domain, including devices and users, verifies their credentials and defines their access rights. It authenticates and authorizes all users and devices in a domain. Assigning and enforcing security and group policies for all devices and users in the domain and establishes a framework to deploy other related services: Certificate Services, Active Directory Federation Services, Lightweight Directory Services and Rights Management Services.
Let’s see why customers deploy Active Directory:
· Windows workloads whether on premises or in the cloud usually requires active directory.
· Whether on cloud or on premises, latency is important and most applications require Active Directory to be close to where the applications are. Active Directory is a critical service that resiliency in Active Directory architecture important therefore, you don’t want to rely on network all the time.
· You may have lots of AWS resources and services to manage and you want to leverage your existing Active Directory groups and users that you already have to control access to the AWS resources and services.
· There are many application cannot do federation and utilize Kerberos constraint delegation with Active Directory. Some of these applications can be front ended by SAML or claims but do Kerberos Constraint Delegation against active directory such as SharePoint. If you want to know more about Kerberos Constraint Delegation with protocol transition please have a look at my post in this link.
Let’s look at what are the choices for running Active Directory on AWS:
1. Self-managed AD, Deploying Active Directory on Amazon EC2 instances. In this case, customer deploy and manage active directory infrastructure and data within active directory.
2. AWS managed AD, this is AWS service offering where AWS manages infrastructure and customers are responsible managing the data within active directory.
In this post, we are going to look at multiple architectural patterns that use both of these methods. Lets discuss why we should choose one over the other and how to choose between these two options:
Let’s look at the first one Self-Managed AD: so why to deploy Active Directory on ec2 and manage it:
· Want to extend the existing forest/domain to AWS: AWS Managed AD does not support extending your existing domain. AWS Manage AD is a separate domain from your existing domain.
· Need for domain/enterprise admin privilege: AWS Managed AD does not give you domain/enterprise admin privileges. Instead, you will have delegated rights on an OU, which we will discuss later in this post.
· Extend existing users, groups, OUs, and GPOs: If you want to use them in AWS and existing domain. It is only possible with Active Directory on ec2.
· Single unified environment between on premises and AWS cloud: If you don’t want to have 2 separated environments you need to deploy Active Directory on ec2. This is the only way to have existing domain extended and your existing domain available for applications no matter where they are located.
Let’s look at second one AWS managed AD as a resource domain: so why to choose AWS Managed AD option and what are some of the requirements that drive this option:
· Want to minimize AD infrastructure operational management in the cloud: if you don’t want to manage ad infrastructure, don’t want to manage domain, don’t want to patch them on a monthly basis, don’t want to back them up and manage the availability of the domain controllers. AWS manage the entire basic infrastructure and you are only responsible for the Active Directory data.
· Allow delegation of cloud AD management to a separate team while maintaining control of user identity: if you want to delegate the cloud Active Directory to a different team than the central Active Directory who maintain the basic user identity. You can set up a trust to use both those directories.
· Need delineation between on premises and AWS environments: if you want a clear delineation between what is on premises and what is in AWS cloud. You can achieve this by using AWS managed ad because it automatically becomes a separate domain. You can then choose whether you need to have one or two way trust or no trust at all. Keeping them completely separate.
· Need native integration with AWS enterprise applications and services ( e.g Amazon RDS, Amazon FSx, AWS Single Sign On, AWS Workdocs, AWS Workmail, AWS Workspaces etc.): if you need native integration with AWS enterprise applications and services then you can choose AWS managed AD.
Lets have a look of the key features of AWS managed AD:
· Windows Server 2012 R2 domain controllers operates at the 2012 R2 functional level.
· Minimum of 2 DCs each in a different Availability Zone (AZ): add more DCs as needed
· Standalone or connected to your Active Directory with trusts
· AWS enterprise apps and services native integration: EC2 seamless domain join, RDS for SQL Server authentication, authorization Amazon WorkSpaces, Amazon QuickSight Enterprise Edition, Amazon Chime Plus/Pro provisioning, and authentication, AWS Single Sign-on etc.
· Group policy, Active Directory Trust support
· High availability and daily snapshots
· AWS is the domain admin and you get an OU and delegated admin over the OU. Conservative delegated permissions to your OU admin account: Application enablement limits some apps, Some admin functions are not available
· Amazon responsibilities — operate, Multi-AZ deploy, patch monitor, domain controller recovery, snapshot, and restore
· Your responsibilities — administer, Administration through AD console and other AD tools, Administer users, groups, GPOs, other Active Directory content
· AWS Managed Microsoft AD is available in two editions: Standard and Enterprise.
Standard Edition: AWS Managed Microsoft AD (Standard Edition) is optimized to be a primary directory for small and midsize businesses with up to 5,000 employees. It provides you 1GB storage capacity to support up to 30,000* directory objects, such as users, groups, and computers. Enterprise Edition: AWS Managed Microsoft AD (Enterprise Edition) is designed to support enterprise organizations with up to 500,000* directory objects with 17 GB of storage.
Lets deep dive in typical deployment patterns:
1. Extending on-premises AD domain to AWS on Amazon EC2
In the architecture above, there is a corporate data center on the left and we are running our own domain controllers on the right. As you can see a single AWS region, where there is web, application, database servers and domain controllers. In this architecture, we install Active Directory on ec2 instances and make them domain controller of the same domain that is running on corporate datacenter. Network connectivity for the initial ad replication and ongoing replication is required. We can choose AWS Direct Connect or VPN network to connect the two networks. How things would work in this architecture? We are running web, application and database servers in a single region, in single VPC and in multi availability zones. This is same domain as corporate datacenter therefore; we define sites and services in active directory so member servers detect domain controllers based on these sites and services. VPC in the AWS region defined as a site with appropriate availability zone subnets associated like the example below.
Therefore, domain controllers in this AWS region and AWS region VPC as your site with the appropriate subnets the web, application and database servers will use the local Active Directory controllers for all authentication, group policy and for all the Active Directory traffic. The red dotted line is the ad replication that happens between all domain controllers in Active Directory environment. AD replication continues and happens no matter where your domain controllers are whether corporate datacenter or on AWS. When a remote admin wants to log into one of these web servers. Remote admin will authenticate first login to the workstation and authentication will be at the local domain controller in the corporate ad. Because they belong to the same site but when remote admin user RDP into a web server that authentication occurs to the domain controller in the AWS because of the sites and services. This design unify the environment to have the same ous, group policies, user and computer objects and run your workload on AWS just like another datacenter or another site.
2. Using AWS Managed AD as a resource Domain
In the second architecture above, we are using AWS managed AD as a resource domain. Resource domain is where you keep your resource objects in a different domain from where your user/identity objects are. Therefore, in the second architecture on the left corporate data center where user/identity domain is located and its domain controllers running there. This is where identities are. Therefore, a remote admin user account located here. On the right web, application and database servers but these computer objects are located in the AWS managed AD as a resource domain. Which is a different domain compared to the active directory on the corporate domain. So, if you have service accounts that you need for these applications they will be located in the AWS Managed AD as a resource. The red line represents the one-way trust rather than a replication. Because there is no replication in a trust model. In this architecture, we are showing a one-way trust where AWS managed ad as a resource is trusting on-premises corporate user/identity Active Directory but not vice versa. This architecture allows using the user identity from corporate on-premises Active Directory and login to any servers/resources on running on AWS managed AD without the data being replicated. In this architecture if the user who is remote admin wants to rdp to a server he would first log in to workstation and that authentication occur locally on the on premises ad and that is local. However, when he RDP into the web server that authentication still goes back to the on-premises ad because user/identity object does not exist in AWS managed ad. Because of the way this works a robust network connectivity between on-premises and AWS region required. This needs to happen in real time therefore running AWS direct connect and VPN both with two tunnels and in a redundant way highly recommended and needed. When there is no redundancy and If there is a failover or issue with a single Direct Connect, or single VPN tunnel the application continue to run without network connectivity. Because the computer objects and service accounts are located in AWS managed ad. However remote admin or users/identities at the on premise ad won’t be able to log into web, application, database servers if there is no network connectivity.
3. Multi regional Active Directory Deployment on ec2 self-managed AD
Let’s expand this concept to more than one region. Many customers do not just operate in one region. They operate in multiple region because they have a need to be close to the users or they have a need for DR etc. How this expansion will affect on the architecture? In the architecture above extending Active Directory you would treat each region as an Active Directory site and you would place domain controllers in multiple subnet and multiple AZ in each of the regions. The domain on premises end on both aws regions is company.local domain. Because we are extending the same domain into multiple in aws regions and all the domain controllers on AWS and on-premises, contain all of the replicated data for single domain. Network connectivity is required for replication traffic.
4. Multi regional Active Directory Deployment on AWS managed AD
Lets look at aws managed to ad architecture. In this architecture, there are two different domains in each region. Because, aws managed ad is a regional service. Which means that today you cannot extend aws managed ad domain across a region boundary. So using aws managed ad as a resource domain in more than one region requires deploying a domain in each region.
In the architecture above in Region 1 domain is na.company.local and Region 2 domain is eu.company.local. These are two separate aws managed ad as resource domains. They have a one-way trust back to the company.onprem user/identity domain. Because of this architecture, you get a delineation between objects that are regional. Member servers in Region 1 will be member of na.company.local and members servers in Region 2 will be member of eu.company.local.
When administrator is logging in to workstation authentication occurs locally at on premise domain and when administrator rdp into Region 1 or Region 2 servers, authentication needs to happen at on premise domain. All service accounts and computer objects needs to reside in respective Region 1 and Region 2 Resource domains. Because authentication needs to occur real time network connectivity is very important. Network connectivity needs to have highly available Direct Connect and VPN architecture.
5. Internet name resolution from the DCs
Let us have a look at internet name resolution. Many customers use their domain controllers as also DNS servers. However also some customers use in different appliance or Route 53 DNS. Lets deep dive on How Internet Name Resolution works for these architectures.
· Internet name resolution if you are using Domain Controllers for DNS
In this architecture, multiple VPCs on the right and then a shared services VPC on the left. AWS recommendation for running Active Directory is to centralize Active Directory within a region in a single VPC. AWS recommends this way from a security perspective, which we will discuss later in this post. However, you may have multiple VPCs for business units or for applications and then you can have domain controllers in a centralized VPC. It does not have to be two domain controllers you can deploy any number of domain controllers. Does not matter if it is AWS managed ad or self-managed ad on ec2. You can determine how many domain controllers you need to support your workloads. In this example above, they are all pointing to the domain controllers for DNS. However, domain controllers need to access the Internet for resolving internet names.
· First way you can do is point the domain controllers to Route 53 .2 resolvers. Route 53 .2 resolvers are available with each VPC. You can point Domain Controllers to Route 53 .2 resolvers which will resolve internet queries for you. This is the preferred method. In the link you can reach AWS blog about Route 53 .2 resolvers.
· Second way you can do is running your own DNS servers or appliances in public subnets that allows recurring queries to be resolved without the domain controllers reaching out to the Internet. This is the second preferred method.
· Third way you can do is using a nat gateway in front of DCs. Because domain controllers are not in public subnet and should not be in public subnet. Domain controllers can get to the Internet to resolve names by putting them behind the nat gateway that is in a public subnet.
Out of these three methods the most preferred way is using Route 53 .2 resolvers. The second preferred way is deploying your own DNS servers or appliances in public subnets. But don’t forget to take care of availability, scalability and security of these DNS servers or appliances. For example, think about how to mitigate DNS DDOS attacks. It is better to avoid nat gateway method for the domain controllers, which are still reaching out to an endpoint on the internet directly. Because there can be DNS vulnerabilities and there is a chance that domain controllers to be exposed to those vulnerabilities. Whereas in either Route53 .2 resolver case or the DNS servers in public subnet case you are exposing that DNS servers or Route 53 to the Internet but the domain controllers never making a direct connection to any name servers on the internet.
6. AWS Account Structure
Let’s dive in to AWS account structure. How to deal with deploying Active Directory to support many business units and applications. In previous section, we mention AWS recommends centralizing Active Directory to a single VPC per region. Then which account structure that VPC should be in? AWS has landing zone solution and AWS control tower offering to govern and deploy multi account strategy in AWS environments. These AWS services that assist managing multiple accounts and splitting roles between all the AWS accounts. So we can scale AWS resources without worrying about account and separation of duties.
AWS established account structure for Active Directory. In the diagram above, there is an AWS master account, which is a master of organization. There a security account, Shared services account and a logging account. Things like guard duty or security tools are located in security account and the logs of all our accounts is go in Logs archive account. Therefore, Active Directory account can be a shared services account or a dedicated account for Active Directory. We should separate Active Directory from everything else especially the business units. Because that way it allows to manage them centrally and control access to that easily. We will go deep dive security in the future sections of this post.
7. Active Directory Security Best Practices on AWS
Lets have a look into Active Directory security best practices on AWS.
· Centralize AD in a single AWS account. It’s easier to control access in a separate account rather than trying to control access to AD from many people in a number of accounts where your business units are operating.
· Restrict access to EC2/EBS/Directory services. Only limited number authorized people should have rights to manage control access to active directory and snapshot ebs volume or access to ebs volume of the Active Directory. Only limited number authorized people should have rights to start, stop or terminate a domain controller.
· Restrict Security Groups to allow only AD ports from required networks. Security groups helps filter traffic to allow only AD ports (Authentication, Replication, Trust etc.) that are required from the required networks.
· Encrypt EBS volumes for data encryption and LDAPS for transit. Encrypt EBS volumes by using AWS KMS and if necessary HSM and turn on LDAPs so your authentication traffic is encrypted even within VPC. If you are using kms to encrypt EBS volume consider using a separate master key for Active Directory. Because that allows you to control access easily to who needs access to that master key and keep that control of separation of who can decrypt that EBS volumes and snapshots that are encrypted with this customer master key.
· Security logs are the best source of information for activities occurring on your identity store. Monitor security logs for anomalies and set up alerts for key security events. You can push security logs to Cloudwatch and set alerts.
· Perform AD administrative tasks from a management server. This increases security and auditability on who is performing what tasks.
8. AWS Managed Microsoft AD security
Lets have a look at AWS managed Microsoft AD security:
· AWS Managed AD is single tenant. Your DCs only contain your data.
· Most management tasks automated and taken care by AWS. AWS has process for support engineers when human touch is required. They will have limited just in time access and least privilege access. They do not have admin access.
· Domain controller, security logs delivered to Amazon CloudWatch Logs.
· Delegated admin access given using predefined users, groups, and OUs.
· Use management server for admin tasks; cannot RDP to domain controllers
· AWS Managed AD will use Route 53 (.2 resolver) for internet bound queries
· EBS volumes are encrypted by default using AWS KMS. All snapshots are encrypted and stored securely
· AWS Managed AD supports LDAPS.
In the table below, you can find AWS Shared responsibility model for AWS Managed active directory.
9. Sharing Active Directory
AWS Managed Microsoft AD integrates tightly with AWS Organizations to allow seamless directory sharing across multiple AWS accounts. You can share a single directory with other trusted AWS accounts within the same organization or share the directory with other AWS accounts that are outside your organization. You can also share your directory when your AWS account is not currently a member of an organization. With AWS Managed Microsoft AD, you can share a single directory for multiple use cases. For example, you can share a directory to authenticate and authorize access for .NET applications, Amazon RDS for SQL Server with Windows Authentication enabled, and Amazon Chime for messaging and video conferencing. The following diagram shows some of the use cases for your AWS Managed Microsoft AD directory. These include the ability to grant your users access to external cloud applications and allow your on-premises AD users to manage and have access to resources in the AWS Cloud.
You can use AWS Managed Microsoft AD for either of the following business use cases:
1. Sign In to AWS Applications and Services with AD Credentials
2. Manage Amazon EC2 Instances
3. Provide Directory Services to AD-Aware Workloads
4. SSO to Office 365 and Other Cloud Applications
5. Establish trust with On-Premises AD to the AWS Cloud
6. Share Your Directory to Seamlessly Join Amazon EC2 Instances to a Domain Across AWS Accounts