AWS has updated its Security Blog post on IAM Identity Center to include detailed Active Directory migration strategies and automation for permission sets. The addition provides a concrete runbook for moving from one identity source—such as on‑premises Active Directory—to an external SAML 2.0 provider like Okta, and it highlights the operational steps needed to avoid access interruptions during the cutover.
Identity source options and constraints
IAM Identity Center can be linked to a single identity source at any time. The three supported sources are:
- Identity Center Directory – The built‑in store where users and groups are created directly in the service. It requires no external directory.
- Active Directory – Integration with an on‑premises Microsoft AD or an AWS Managed Microsoft AD via AWS Directory Service. Existing AD accounts and group memberships can be reused.
- External IdP – Any SAML 2.0‑compatible provider, for example Okta, Microsoft Entra ID, or Ping Identity. This is the path covered by the migration runbook.
The chosen source becomes the system of record for user and group data used by IAM Identity Center.
Impact on permission and application assignments
Access to AWS resources is granted through two mechanisms:
- Permission set assignments – Users or groups receive a permission set in a specific AWS account. IAM Identity Center automatically creates a role in the target account named
AWSReservedSSO_...to back each assignment. - Application assignments – Users or groups are granted access to AWS‑managed or customer‑managed applications that are integrated with IAM Identity Center.
When the identity source changes, the underlying user and group identifiers may differ, which can break existing assignments. The runbook therefore includes steps to export current permission set mappings, reconcile them with the new source, and re‑apply them to preserve access.
Migration workflow and automation considerations
The updated guidance outlines a repeatable process:
- Export current user, group, and permission set data from the existing source.
- Configure the new identity source (e.g., connect Okta via SAML) and verify synchronization.
- Map legacy AD groups to equivalent groups or attributes in the new IdP.
- Use the provided sample scripts to bulk‑create permission set assignments against the new source.
- Perform a staged cutover, monitoring for authentication failures and confirming that
AWSReservedSSO_...roles appear in each account. - Decommission the old source only after all assignments are verified.
The blog warns that an unplanned cutover can cause a temporary loss of access to AWS accounts and applications until assignments are restored. Automating the export‑transform‑load steps reduces manual error and shortens the window of reduced availability.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Teams responsible for identity and access management should treat the identity source as a single point of truth and plan migrations as a controlled change. Evaluate the current source, inventory permission set assignments, and test the new IdP in a sandbox before production cutover. Leverage the sample automation to synchronize permission sets and verify that the automatically generated AWSReservedSSO_... roles are present in every target account. Finally, monitor login attempts during the transition to catch any residual gaps before decommissioning the legacy directory.