When an interviewer asks how you manage hybrid identity, they’re not just testing your AWS knowledge. They want to know if you understand the bigger picture: real companies don’t live entirely in the cloud. They have on-premises Active Directory, legacy apps, and thousands of users who need seamless access to AWS without juggling separate credentials for every account.
This post covers exactly how to answer that question. You’ll learn how AWS SSO Active Directory integration works in practice, what to choose between AD Connector and Managed Microsoft AD, and the five things you need to get right to make it work in production.
Quick Answer: Hybrid Identity Components at a Glance
| Component | What It Does | When You Need It |
|---|---|---|
| AWS Managed Microsoft AD | Full AD domain inside AWS, supports two-way trust | Windows workloads, domain-join EC2 instances |
| AD Connector | Authentication proxy to on-prem AD, no data sync | When AD must stay on-premises |
| IAM Identity Center (SSO) | Central login portal for all AWS accounts and apps | Every multi-account environment |
| SCIM Provisioning | Auto-syncs users and groups from identity source | Any org with more than ~20 users |
| Permission Sets | Define role-level access per account | Every IAM Identity Center setup |
What Is AWS IAM Identity Center?
AWS IAM Identity Center is the service that handles single sign-on access across all your AWS accounts and business applications. It was called AWS SSO until 2022, and AWS SSO Active Directory integration is still the phrase most engineers search for and use in conversation. Either term is acceptable in an interview, though knowing the current name signals you stay current with AWS.
The core idea is simple: users authenticate once through a centralised portal and get access to whichever AWS accounts they’re authorised to use, based on their group membership. No separate IAM users per account, no shared passwords, no credential sprawl.
Your identity source can be IAM Identity Center’s own built-in directory, an external IdP like Okta or Azure AD connected via SAML 2.0, or Active Directory. For most enterprise environments, Active Directory is the identity source, and that’s what makes hybrid identity the interesting design challenge.
What Is Active Directory and Why Does It Matter?
Active Directory (AD) is Microsoft’s directory service. Most enterprises use it to manage users, groups, computers, and group policies on-premises. When those companies move workloads to AWS, they don’t abandon AD overnight. The users, groups, and roles defined in AD represent years of access control work. AWS needs to respect that.
AWS SSO Active Directory is the solution to this problem: your user lives in on-premises AD, but they need access to AWS accounts. The job is getting those two systems to talk cleanly, without duplicating users or creating a second identity lifecycle to manage.
AWS SSO Active Directory: 5 Proven Integration Steps
1. Choose Your Directory Type
The first decision is where your Active Directory lives and how AWS will connect to it. AWS Directory Service gives you two practical options.
AD Connector acts as a proxy. It forwards authentication requests to your on-premises AD without syncing or storing any directory data inside AWS. Use this when your security team requires that user data never leaves the data centre. The trade-off is a dependency on your VPN or Direct Connect connection. If that link goes down, authentication stops working.
AWS Managed Microsoft AD creates a fully managed Microsoft AD domain inside AWS, with an optional two-way trust back to your on-premises domain. This is the right choice when you’re running Windows workloads in AWS that need domain join, or when you need Group Policy applied to EC2 instances. It costs more (roughly $100+ per month per directory), but it’s self-contained and not dependent on on-prem connectivity.
I’ve seen teams default to AD Connector because it’s simpler to justify to the security team, then run into problems when they start spinning up Windows EC2 instances that need domain join. Think about your workload requirements before committing to a directory type.
2. Connect IAM Identity Center to Active Directory
Once your directory is set up, connect it to IAM Identity Center to complete the AWS SSO Active Directory link. In the console, go to IAM Identity Center → Settings → Identity source → Change identity source and select Active Directory. Choose your directory from the dropdown.
After this connection, IAM Identity Center can read users and groups from AD. One thing to note: users are not automatically synced at this point. You’ll either assign them manually (fine for small teams) or set up SCIM provisioning to handle it automatically, which is what step 3 covers.
3. Configure SCIM Provisioning
SCIM (System for Cross-domain Identity Management) is the protocol that keeps your users and groups in sync between your identity source and IAM Identity Center. Without it, you’re adding and removing users manually every time someone joins or leaves the company. That breaks down fast.
For external IdPs like Okta or Azure AD, SCIM is configured on the IdP side. IAM Identity Center provides a SCIM endpoint URL and a bearer token, and the IdP pushes user and group changes automatically.
For AWS Managed Microsoft AD, group sync happens directly inside IAM Identity Center once you assign groups. The key thing to get right in interviews: SCIM syncs identities, not passwords. Authentication still happens against the original directory. The credentials never touch AWS.
4. Create Permission Sets and Assign Groups
Permission sets define what an authenticated user can do inside a specific AWS account. Think of them as IAM role templates managed from a central place. You create a permission set (for example, “ReadOnly”, “DeveloperAccess”, or “NetworkAdmin”) and then assign an AD group to that permission set for a target account.
Behind the scenes, IAM Identity Center creates an IAM role in the target account. When a user logs in through the portal and selects that account, they assume the role that matches their permission set. They never need permanent IAM credentials or an IAM user in that account.
For a multi-account AWS environment, this is how you avoid creating hundreds of IAM users scattered across accounts. One identity in AD, mapped to the right permission sets, gives access to dozens of accounts cleanly and consistently.
5. Monitor, Audit, and Harden
The last step is ongoing. Use AWS CloudTrail to log all sign-in events and role assumptions from IAM Identity Center. The service also has built-in access reports under the console that show you which users accessed which accounts and when.
For high availability, deploy your AD Connector or Managed Microsoft AD across at least two Availability Zones. A single-AZ directory is a quiet single point of failure. Everything looks fine until a zone goes down and no one can authenticate. Enable MFA in IAM Identity Center for an additional layer, especially for accounts with privileged access.
AD Connector vs AWS Managed Microsoft AD: Which One?
| Factor | AD Connector | AWS Managed Microsoft AD |
|---|---|---|
| User data location | Stays on-premises | Replicated into AWS |
| Domain-join EC2 | Not supported | Full support |
| Two-way trust with on-prem | No | Yes |
| VPN/Direct Connect dependency | Yes | No |
| Group Policy in AWS | No | Yes |
| Cost | Lower | Higher (~$100+/month) |
| Best for | Auth proxy, strict data residency | Full Windows workloads in AWS |
Example Interview Answer
Here’s how to structure your answer in about 90 seconds. Watch this mock interview response for delivery style, then use the template below:
“For hybrid identity, I’d start by evaluating the directory setup. If the Active Directory needs to stay on-premises for data residency reasons, I’d use AD Connector as a proxy to IAM Identity Center. If we’re running Windows workloads in AWS that need domain join or Group Policy, I’d set up AWS Managed Microsoft AD with a two-way trust back to the on-prem domain.
Once the directory is connected to IAM Identity Center, I’d define permission sets based on job functions: read-only, developer access, and admin. Then I’d assign AD groups to those permission sets for the relevant accounts. SCIM provisioning handles the automatic sync of users and groups, so access is granted and revoked in near real-time as people join or leave teams.
The end result: users log in once through the IAM Identity Center portal, see the accounts they’re allowed into, and assume the appropriate role. IT manages access through AD groups they already maintain. No separate IAM users across accounts, no credential sharing, full CloudTrail audit trail.”
Common Mistakes to Avoid
Using AD Connector when your workloads need domain join. AD Connector handles authentication only. If your EC2 instances need to join a Windows domain, AD Connector won’t work. You need AWS Managed Microsoft AD for that.
Skipping SCIM provisioning. Manual user assignment works for a proof of concept. In any real environment with turnover, it becomes a security liability. Users who left the company can retain access until someone notices. Set up SCIM from day one.
Single-AZ directory deployment. Putting your AD Connector or Managed AD in one Availability Zone means a zone failure takes down authentication for everyone. Always deploy across two AZs minimum, same as any other critical infrastructure.
Creating over-broad permission sets. One “AdminAccess” permission set assigned to everyone is a common shortcut that makes audits painful and blast radius enormous. Keep permission sets aligned to job functions and apply least privilege. It also makes it easier to revoke access precisely when someone changes roles.
Confusing IAM roles with permission sets. Permission sets live in IAM Identity Center and are deployed as IAM roles in each target account. They’re not the same thing, and mixing them up in an interview answer signals a shallow understanding. If you’re working with container workloads across multiple accounts, this distinction matters for how task roles and human access are separated.
Key Takeaway
AWS SSO Active Directory integration comes down to four decisions: pick the right directory type for your data residency and workload requirements, connect it to IAM Identity Center, set up SCIM to automate user lifecycle, and define permission sets that map AD groups to appropriate access per account. Get those four pieces right and you have an identity setup that scales, audits cleanly, and doesn’t require a separate user store inside AWS.
