This chapter covers AWS Directory Service options, specifically AD Connector and AWS Managed Microsoft AD, which are critical for integrating AWS resources with existing Active Directory environments. For the SAA-C03 exam, this topic appears in roughly 5-8% of questions, often in scenarios requiring identity federation, single sign-on, or domain-joined EC2 instances. Understanding the differences, use cases, and limitations of each option is essential for designing secure, hybrid architectures.
Jump to a section
Imagine a company with its own private telephone exchange (PBX) that manages all internal extensions and external calls. Now, that company wants to use a cloud-based phone service but still keep its existing internal directory and call routing rules. AD Connector is like a gateway that connects the company's existing PBX to the cloud service: users dial the same extensions, the PBX still handles internal calls, but the cloud service provides a unified dial tone and features like voicemail-to-email. The cloud service doesn't replace the PBX; it just acts as a proxy. In contrast, AWS Managed Microsoft AD is like moving the entire PBX into the cloud—the company no longer manages the physical hardware, but the internal directory (extensions, routing) is now hosted by the cloud provider. With Managed AD, all authentication and authorization happen in the cloud, and there's no need for an on-premises directory. AD Connector never stores user credentials; it simply forwards authentication requests to your on-premises Active Directory. Managed AD stores everything in the AWS cloud. So, if your company wants to keep using its own PBX but also wants cloud features, use AD Connector. If you want to completely outsource directory management, use Managed AD.
What is AWS Directory Service?
AWS Directory Service provides managed directory services in the AWS cloud. It offers three main options: AWS Managed Microsoft AD (also called Microsoft AD), AD Connector, and Simple AD. For the SAA-C03 exam, the focus is on the first two, as Simple AD is a low-cost alternative based on Samba 4 and not a full Microsoft AD replacement.
AWS Managed Microsoft AD
AWS Managed Microsoft AD is a fully managed, highly available Microsoft Active Directory service in the AWS cloud. It is built on actual Microsoft Windows Server and provides the standard AD features: Kerberos authentication, LDAP, Group Policy, and trust relationships with on-premises AD. You can create a new AD forest in AWS or extend your on-premises AD by establishing a forest trust.
How it works: - AWS deploys at least two domain controllers across two Availability Zones in a VPC. - You can join EC2 instances, RDS databases, and other AWS services to the domain. - It supports Kerberos-based single sign-on (SSO) for applications. - You can establish a one-way or two-way forest trust with on-premises AD, allowing users from either side to authenticate across the trust. - AWS manages the domain controllers, including backups, software updates, and replication.
Key components: - Directory ID: A unique identifier for the directory (e.g., d-1234567890). - DNS: AWS Managed AD automatically provides DNS resolution for the directory domain. - NetBIOS name: Short domain name (e.g., CORP). - Administrator password: You set the password for the Admin account during creation. - Trust relationships: Can be one-way (incoming or outgoing) or two-way.
Configuration example:
To create a trust from on-premises to AWS Managed AD:
1. Create the trust in AWS Directory Service console.
2. Create a corresponding trust in on-premises AD.
3. Ensure network connectivity (VPC VPN or Direct Connect) and DNS resolution.
4. Verify trust using nltest /dsgetdc:<domain>.
Exam note: AWS Managed AD supports up to 5,000 users by default with the Standard edition, and up to 500,000 with the Enterprise edition. It also supports Group Managed Service Accounts (gMSAs) for application services.
AD Connector
AD Connector is a directory gateway that proxies authentication requests from AWS services to your on-premises Active Directory. It does not store any user data or credentials; it simply forwards requests to your existing AD domain controllers.
How it works: - AD Connector runs as a service in your VPC, typically with two endpoints across two AZs. - It uses service accounts (with read-only privileges) to bind to your on-premises AD. - When an AWS service (e.g., WorkSpaces, QuickSight, or an EC2 instance joined via AD Connector) needs to authenticate a user, it sends the request to AD Connector, which then forwards it to the on-premises AD over a VPN or Direct Connect. - AD Connector caches credentials temporarily to improve performance (default cache TTL is 15 minutes). - It supports Kerberos and NTLM authentication.
Key components: - Service account credentials: You provide a username and password for a domain user that has permissions to read the directory. - DNS: AD Connector uses the DNS servers you specify for your on-premises domain. - Security groups: You need to allow outbound traffic to your on-premises AD domain controllers (TCP/UDP 53 for DNS, TCP 88 for Kerberos, TCP 389 for LDAP, etc.).
Configuration example: To set up AD Connector: 1. In the AWS Directory Service console, choose "AD Connector." 2. Specify the VPC, subnets, and the DNS IP addresses of your on-premises AD. 3. Provide the service account credentials (e.g., CORP\svc-aws). 4. Configure security groups to allow traffic from AD Connector to on-premises AD. 5. Once created, you can join EC2 instances to the domain using the AD Connector directory ID.
Exam note: AD Connector cannot be used to create new users or groups; it only proxies authentication. It also does not support Group Policy application or LDAP writes. It is ideal when you want to use your existing on-premises AD without syncing or migrating data to the cloud.
Comparison of Features
| Feature | AWS Managed AD | AD Connector | |---------|----------------|--------------| | Directory data stored in AWS | Yes | No (proxy only) | | Supports new users/groups | Yes | No | | Group Policy | Yes | No | | Forest trust | Yes | No | | LDAP writes | Yes | No | | Supports EC2 domain join | Yes | Yes | | Supports RDS SQL Server | Yes | Yes | | Supports WorkSpaces | Yes | Yes | | Supports QuickSight | Yes | Yes | | Requires VPN/Direct Connect | No (if standalone) | Yes | | User limit | 5,000 (Standard) / 500,000 (Enterprise) | Unlimited (depends on on-premises AD) |
When to Use Each
Use AWS Managed Microsoft AD when:
You need a standalone AD in the cloud for new applications.
You want to extend your on-premises AD via trust but avoid latency.
You need Group Policy or LDAP writes in AWS.
You want to offload AD management to AWS.
Use AD Connector when:
You already have an on-premises AD and want to keep it as the authoritative identity store.
You need to provide SSO for AWS applications without syncing users.
You have a large existing user base and don't want to manage a separate directory.
You need to maintain strict control over user credentials.
Interaction with Other AWS Services
Both options can integrate with: - Amazon WorkSpaces: Domain-join virtual desktops. - Amazon QuickSight: User authentication for BI dashboards. - AWS Single Sign-On (SSO): Federate access to multiple AWS accounts. - Amazon RDS for SQL Server: Use Windows Authentication. - Amazon EC2: Domain-join instances for centralized management.
For EC2 domain join, you can use AWS Systems Manager or run a PowerShell script via User Data. The directory ID is used as the join parameter.
Exam Trap: Simple AD
Simple AD is a low-cost directory based on Samba 4. It supports basic AD features but NOT:
Trust relationships with on-premises AD.
Group Policy.
Kerberos constrained delegation.
Integration with RDS SQL Server (Windows Authentication).
Integration with WorkSpaces (only for certain regions).
The exam often presents Simple AD as a trick answer when the requirement is to extend on-premises AD or use advanced features. Always check if the scenario requires trust or Group Policy.
1. Assess Requirements
Identify whether you need to extend an existing on-premises AD or create a new standalone directory. If extending, determine if you need a forest trust (Managed AD) or just authentication proxy (AD Connector). Also consider user count: Managed AD Standard supports up to 5,000 users; Enterprise up to 500,000. AD Connector has no user limit but depends on on-premises capacity.
2. Network Connectivity
For AD Connector, establish a VPN or Direct Connect between your VPC and on-premises network. Ensure DNS resolution: on-premises DNS must be reachable from the VPC. For Managed AD with trust, similar connectivity is required. For standalone Managed AD, no on-premises connectivity is needed.
3. Create Directory Service
In the AWS Directory Service console, choose either 'AWS Managed Microsoft AD' or 'AD Connector'. For Managed AD, specify edition (Standard/Enterprise), directory DNS name, NetBIOS name, VPC, and subnets. For AD Connector, provide VPC, subnets, on-premises DNS IPs, and service account credentials.
4. Configure Security Groups
For AD Connector, create a security group that allows outbound traffic to on-premises AD domain controllers on required ports: TCP/UDP 53 (DNS), TCP 88 (Kerberos), TCP 389 (LDAP), TCP 445 (SMB), TCP 464 (Kerberos change password), and UDP 123 (NTP). For Managed AD, AWS manages the security groups automatically.
5. Join AWS Resources to Domain
Use the directory ID to join EC2 instances, RDS instances, or WorkSpaces. For EC2, you can use AWS Systems Manager or User Data script: `powershell Add-Computer -DomainName "corp.example.com" -Credential (Get-Credential) -Restart`. For RDS SQL Server, enable Windows Authentication and specify the directory ID.
6. Verify Functionality
Test authentication by logging into a domain-joined EC2 instance with on-premises credentials. For Managed AD with trust, verify trust using `nltest /trusted_domains`. For AD Connector, check that authentication requests are proxied correctly. Monitor CloudWatch logs for errors.
Scenario 1: Enterprise SSO for AWS WorkSpaces
A large enterprise with 10,000 on-premises AD users wants to deploy Amazon WorkSpaces for remote employees. They need users to log in with their existing corporate credentials without syncing passwords to the cloud. The solution is AD Connector: it proxies authentication from WorkSpaces to the on-premises AD over a VPN. The IT team deploys two AD Connector endpoints in a VPC connected via AWS Direct Connect. They configure a service account with read-only access. Users can now launch WorkSpaces and log in with their domain credentials. Performance is acceptable because the VPN has low latency. A common mistake is to use Simple AD, which cannot integrate with on-premises AD, forcing users to create new accounts.
Scenario 2: Isolated Development Environment
A startup is building a new application on AWS and needs Active Directory for authentication but has no on-premises infrastructure. They choose AWS Managed Microsoft AD (Standard edition) to create a new directory from scratch. They join EC2 instances to the domain, enable Group Policy to enforce security settings, and use RDS SQL Server with Windows Authentication. The directory is fully managed by AWS, eliminating the need for dedicated AD administrators. They later decide to sync some users from their parent company's on-premises AD using a one-way forest trust. This allows their corporate users to access the dev environment without duplicate accounts. A common mistake is to use AD Connector instead, which requires on-premises AD and cannot create new users.
Scenario 3: Merger and Acquisition Integration
Company A acquires Company B, which uses on-premises AD. Company A already has AWS Managed AD with a forest trust to its own on-premises AD. To integrate Company B's users, they establish a second forest trust between AWS Managed AD and Company B's on-premises AD. This allows users from both companies to access shared AWS resources. AD Connector would not be suitable because it cannot support multiple trusts or act as a hub. Misconfiguration of trust directions can lead to authentication failures—a common issue when trust is one-way but two-way is needed.
The SAA-C03 exam tests this topic under Domain 1: Secure Architectures (Objective 1.1: Design secure access to AWS resources). Key areas include:
Choosing between AD Connector and Managed AD based on requirements. The exam presents scenarios with requirements like: "must use existing on-premises AD without syncing passwords" -> AD Connector. "Need to create new users in the cloud" -> Managed AD. "Need Group Policy" -> Managed AD. "Need trust with on-premises AD" -> Managed AD.
2. Common wrong answers: - Simple AD when the requirement involves trust, Group Policy, or RDS SQL Server Windows Authentication. Candidates choose it because it's cheaper, but it lacks these features. - AD Connector when the scenario requires creating new users or groups. Candidates mistakenly think AD Connector can manage users, but it's a proxy only. - AWS Managed AD when the requirement is to keep all data on-premises and only proxy authentication. Candidates over-engineer with a full directory. - Cognito or STS when the scenario is about Active Directory integration. These are for web identity federation, not enterprise AD.
3. Specific numbers and terms: - Standard edition: up to 5,000 users; Enterprise: up to 500,000. - AD Connector does not store credentials; it caches them for 15 minutes default. - Ports: 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), 464 (Kerberos change), 123 (NTP). - Trust types: one-way incoming, one-way outgoing, two-way.
4. Edge cases: - AD Connector requires network connectivity to on-premises AD; if the VPN goes down, authentication fails. - Managed AD can be used standalone or with trust; if trust is broken, on-premises users cannot authenticate. - Simple AD cannot be used with RDS SQL Server Windows Authentication; this is a frequent exam trap.
5. Eliminating wrong answers: - If the question mentions "Group Policy" -> eliminate Simple AD and AD Connector. - If the question mentions "on-premises AD" and "no data stored in AWS" -> eliminate Managed AD and Simple AD. - If the question mentions "create new users" -> eliminate AD Connector. - If the question mentions "forest trust" -> only Managed AD supports it.
Always check the key phrase: "proxy", "extend existing", "new forest", "standalone".
AD Connector is a proxy; it does not store credentials or directory data.
AWS Managed Microsoft AD is a full AD with support for Group Policy, trusts, and LDAP writes.
Simple AD is a low-cost alternative but lacks trust, Group Policy, and RDS SQL Server support.
For scenarios requiring extension of on-premises AD without syncing, use AD Connector.
For scenarios requiring a new standalone directory or forest trust, use AWS Managed AD.
AD Connector requires network connectivity (VPN/Direct Connect) to on-premises AD.
AWS Managed AD can be deployed with or without trust to on-premises AD.
The default cache TTL for AD Connector is 15 minutes.
Ports required: 53, 88, 389, 445, 464, 123 for AD Connector to on-premises AD.
AWS Managed AD supports up to 5,000 users with Standard edition, 500,000 with Enterprise.
RDS SQL Server Windows Authentication requires AWS Managed AD (not AD Connector or Simple AD).
These come up on the exam all the time. Here's how to tell them apart.
AD Connector
Proxies authentication to on-premises AD; no directory data stored in AWS.
Cannot create new users or groups; all management remains on-premises.
Does not support Group Policy or LDAP writes.
Requires VPN/Direct Connect to on-premises network.
No user limit; depends on on-premises AD capacity.
AWS Managed Microsoft AD
Fully managed AD in AWS; stores directory data in cloud.
Can create new users, groups, and OUs; supports Group Policy.
Supports forest trusts with on-premises AD.
Can operate standalone without on-premises connectivity.
User limits: 5,000 (Standard) or 500,000 (Enterprise).
Mistake
AD Connector can create and manage users in the cloud.
Correct
AD Connector is a proxy only; it does not store any directory data. All user management must be done on-premises.
Mistake
AWS Managed Microsoft AD requires a VPN to on-premises AD.
Correct
Managed AD can operate standalone without any on-premises connectivity. VPN is only needed if you want to establish a trust with on-premises AD.
Mistake
Simple AD supports forest trusts with on-premises Active Directory.
Correct
Simple AD is based on Samba 4 and does not support trust relationships. It is a standalone directory only.
Mistake
AD Connector supports Group Policy.
Correct
AD Connector does not support Group Policy because it does not process LDAP writes. Group Policy requires a full AD instance like Managed AD.
Mistake
You can join EC2 instances to a domain using Simple AD.
Correct
Simple AD supports domain join for EC2 instances, but it does not support advanced features like trust, Group Policy, or RDS SQL Server Windows Authentication.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AD Connector is a proxy that forwards authentication requests to your on-premises Active Directory; it does not store any directory data. AWS Managed Microsoft AD is a fully managed, standalone Active Directory in the cloud that can optionally establish trusts with on-premises AD. Use AD Connector when you want to keep your on-premises AD as the authoritative identity store. Use Managed AD when you need a new directory or want to extend your on-premises AD with advanced features like Group Policy.
Yes, AD Connector can be used with RDS SQL Server for Windows Authentication. However, note that AD Connector only proxies authentication; the actual user and group management must be done on-premises. For RDS SQL Server, you need to enable Windows Authentication and specify the directory ID of AD Connector.
No, AD Connector does not support Group Policy. Group Policy requires a full Active Directory instance that can process LDAP writes. AWS Managed Microsoft AD supports Group Policy.
No, AD Connector does not support forest trusts. It is a proxy, not a directory. Forest trusts are only supported by AWS Managed Microsoft AD.
If the network connection is lost, AD Connector cannot proxy authentication requests, and users will be unable to authenticate. To mitigate, use redundant VPN connections or Direct Connect with failover. Also, AD Connector caches credentials for up to 15 minutes by default, so recently authenticated users may still be able to access resources during brief outages.
Simple AD is cheaper but lacks many features required for enterprise use, such as forest trusts, Group Policy, and support for RDS SQL Server Windows Authentication. It is suitable for small, standalone directories. For production enterprise scenarios, use AWS Managed AD.
Yes, AWS Managed AD can be deployed as a standalone directory in the cloud without any on-premises connectivity. You can create users, groups, and policies directly in the AWS directory. It is fully managed by AWS.
You've just covered AWS Directory Service: AD Connector vs Managed AD — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?