IAM Identity Center Integration with Active Directory

This page covers connecting an existing on-premises Active Directory to AWS IAM Identity Center (formerly AWS Single Sign-On) so that employees reach every account in the organisation with their existing credentials.

Choose the integration model first

There are three ways to do it, and the choice determines everything that follows. It is decided before any of the implementation steps below, because the wrong one is discovered at the provisioning step and is expensive to unwind.

Model	Identity source	Provisioning	Suits
A. Active Directory as the identity source	AWS Managed Microsoft AD, or AD Connector to the on-premises directory	Handled by Directory Service; no SCIM involved	An existing AD with no cloud identity provider in front of it
B. External SAML provider with SCIM	Microsoft Entra ID, Okta, Ping or another SCIM-capable provider sitting in front of AD	Automatic, via SCIM	An organisation that already federates through a cloud identity provider
C. External SAML provider without SCIM	AD FS, Shibboleth, F5	Manual, in the IAM Identity Center console	AD FS environments where the provider cannot be changed

AD FS has no SCIM client. AWS names AD FS, Shibboleth and F5 specifically as providers that either do not support SCIM or implement it incompatibly, and states that users and groups must be provisioned manually in those cases. Any plan that has AD FS pushing users into IAM Identity Center over SCIM will not work.

flowchart TB subgraph OnPrem["On-premises"] AD[Active Directory] Users[End users] Users -->|1. Authenticate| AD end subgraph AWS["AWS Cloud"] subgraph OrgAccount["Organizations management account"] IAMIdentity[IAM Identity Center] end subgraph Accounts["Member accounts"] Account1[Account 1] Account2[Account 2] AccountN[Account N] end end AD -->|"2. Identity source: AD Connector or AWS Managed Microsoft AD (model A)"| IAMIdentity AD -->|"2. SAML federation, plus SCIM if the provider supports it (models B and C)"| IAMIdentity IAMIdentity -->|3. Permission sets| Account1 IAMIdentity -->|3. Permission sets| Account2 IAMIdentity -->|3. Permission sets| AccountN Users -->|4. Access portal sign-in| IAMIdentity

Prerequisites

• AWS Organizations with all features enabled
• An existing on-premises Active Directory
• Network connectivity from AWS to the domain controllers — AWS Site-to-Site VPN or AWS Direct Connect — for models A and C
• Administrative access to both the Organizations management account and Active Directory
• A valid TLS certificate for the federation endpoint, where an external SAML provider is used
• A decision on the integration model above, recorded before implementation begins

Implementation

1. Prepare Active Directory

Create the security groups that will map to AWS access levels, and name them according to the attribute-based access control strategy the organisation intends to use. Group names are awkward to change once permission sets and assignments reference them.

For models B and C, install and configure the federation service — AD FS on Windows Server, or the equivalent for the chosen provider — with a service account holding the appropriate permissions and a valid TLS certificate.

2. Enable IAM Identity Center

1. Open the IAM Identity Center console in the Organizations management account.
2. Enable the service and select the Region it will run in. This is difficult to change later; choose the Region the organisation actually operates in.
3. Optionally delegate administration to a dedicated identity account so that day-to-day management does not require the management account.

3. Connect the identity source

Model A — Active Directory as the identity source. Create an AD Connector (or an AWS Managed Microsoft AD with a trust to the on-premises forest) in the same Region as IAM Identity Center, then select Active Directory as the identity source and choose that directory. Users and groups appear from the directory; there is no synchronisation to configure and no SCIM endpoint.

Models B and C — external identity provider. Select External identity provider as the identity source, download the AWS service provider metadata file, and import it into the provider as a relying party. Configure the claim rules the provider will send:

• NameID — must match the attribute mapped to Username
• Email
• Given name
• Family name
• Groups
• Any additional attributes the ABAC strategy requires

Export the provider’s federation metadata XML and import it into IAM Identity Center.

4. Provision users and groups

Model A. Nothing to do. Users and groups are read from the directory.

Model B. Enable automatic provisioning in IAM Identity Center, which generates a SCIM endpoint URL and an access token, and configure both in the identity provider’s provisioning settings. Set the filtering rules so that only the intended users and groups are pushed, and verify the first synchronisation before going further. Note that the access token expires after one year and must be rotated. See SCIM.

Model C. Create the users and groups by hand in the IAM Identity Center console, with usernames identical to those in the provider. Groups do not have to mirror the provider’s groups, but the mapping has to be documented, and a joiner/leaver process has to cover the manual step — this is the model’s principal cost and the reason to prefer A or B.

5. Configure access

1. Define the ABAC strategy. Decide which attributes drive access, and how AD groups map to AWS permissions.
2. Create permission sets for the common job functions, using AWS managed policies where they fit and customer managed or inline policies where they do not.
3. Assign permission sets to groups, per account. One group can hold different permission sets in different accounts — administrator in development, read-only in production.

Monitoring

• CloudWatch metrics and alarms on failed authentications
• Alarms on SCIM synchronisation failures for model B — a stalled synchronisation is silent otherwise, and looks exactly like nobody having joined or left
• Regular review of who holds which permission set in which account
• CloudTrail logging enabled organisation-wide, aggregated to the log archive account

Maintenance

• Review and prune permission sets; they accumulate
• Audit group memberships against the access they confer
• Renew TLS certificates before they expire, and patch the federation servers
• Rotate the SCIM access token before its one-year expiry
• Back up the federation configuration and certificates, and document the steps to rebuild them

Troubleshooting

SAML authentication fails

• Check certificate expiry at both ends
• Verify the claim rules, particularly NameID
• Confirm the metadata on each side is the current version

SCIM synchronisation fails or stalls (model B)

• Confirm the access token has not expired
• Check for users missing a required attribute — first name, last name, username or display name — since one bad user can fail a batch
• Look for multi-valued attributes, which are not supported
• Confirm the users and groups are assigned to the application representing the connection

Access is denied after a successful sign-in

• Confirm group membership and the permission set assignment for that specific account
• Check the ABAC conditions in the permission set policies
• Check whether a service control policy above the account denies the action

Practice

• Manage permission sets as code and review changes like any other infrastructure change
• Enforce MFA at the identity provider, with phishing-resistant factors where possible
• Keep production access narrow, and let the deployment pipeline rather than a person hold the write permissions
• Review access on a schedule, and treat every long-lived exception as a finding
• Rehearse the failure case: how people reach AWS if the identity provider is unavailable, and who holds the break-glass credentials