IAM Identity Center preserva identidades ao trocar fonte vinda do Active Directory

IAM Identity Center preserva identidades ao trocar fonte vinda do Active Directory

Desde 20 de outubro de 2026, usuários, grupos e permissões sobrevivem à migração do Active Directory para Okta, Microsoft Entra ID ou o diretório nativo do Identity Center.

O que muda no fluxo de migração

A AWS anunciou em 20 de outubro de 2026 que o IAM Identity Center passa a preservar identidades e atribuições quando a conta troca a fonte de identidade a partir do Active Directory. A mudança vale tanto para migrar rumo a um IdP externo, como Okta ou Microsoft Entra ID, quanto para migrar rumo ao diretório nativo do próprio Identity Center. Antes do anúncio, essa troca exigia recriar manualmente usuários, grupos, memberships, permission set assignments e application assignments no destino.

Por que a recriação manual doía

Quem administra uma conta AWS organizacional conhece o custo dessa recriação. Cada usuário e grupo carrega um ID próprio no Identity Store, e toda política IAM, automação ou integração que referencia esses IDs parava de funcionar assim que a fonte mudava.

O antes e o depois, lado a lado

O que fica preservado na prática

Segundo a AWS, o identity store permanece no lugar durante a troca: usuários e grupos conservam o mesmo group ID e o mesmo identity store ID, e com isso permission set assignments e application assignments continuam válidas sem reconfiguração. Qualquer política IAM que referencie user ID, group ID ou identity store ID continua funcionando depois da migração, porque o armazenamento subjacente não é recriado, apenas reconectado à nova fonte.

Um exemplo comum: uma política de bucket S3 que restringe leitura a um grupo específico do Identity Center via tag de principal.

Nota da redação: o exemplo de política S3 com a condição aws:PrincipalTag/IdentityStoreGroupId é ilustrativo. Essa chave de condição e o comportamento de ABAC descrito não constam no anúncio oficial da AWS sobre esta mudança nem em outra fonte que pudéssemos checar, então não é possível confirmar que funcionam exatamente assim na prática. O código também não foi executado em ambiente real. Valide tudo antes de usar em produção.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::relatorios-financeiros-sp/*",
 "Condition": {
 "StringEquals": {
 "aws:PrincipalTag/IdentityStoreGroupId": "g-1234567890abcdef"
 }
 }
 }
 ]
}

Antes do anúncio, trocar a fonte a partir do AD apagava esse vínculo: o grupo seria recriado com outro IdentityStoreGroupId, e a condição acima deixaria de bater com ninguém, silenciosamente. Com a mudança, o g-1234567890abcdef sobrevive à migração, e a política continua valendo sem precisar de um segundo deploy nem de um ajuste manual na condição.

Como fica o acesso do usuário final

Depois de configurar a nova fonte com o setup padrão exigido para login, o workforce passa a entrar pela URL dual-stack do AWS access portal, servindo IPv4 e IPv6. A fonte não detalha como era essa URL antes da mudança. A AWS não alterou o caminho inverso: migrar de volta para o Active Directory continua exigindo o processo anterior, sem a preservação de identidades.

Para quem mantém a conta organizacional no Brasil

A novidade vale para instâncias organizacionais do IAM Identity Center em todas as Regiões onde o serviço está disponível, sem custo adicional: o Identity Center continua sendo cobrado apenas pelos recursos de AWS que ele orquestra, não pela gestão de identidade em si. O anúncio não cita regiões específicas, mas, na prática, isso deve incluir São Paulo (sa-east-1) para as contas que já rodam o Identity Center ali.

Para times que rodam a conta de gestão em sa-east-1 e planejam sair de um Active Directory on-premises ou do AWS Managed Microsoft AD para o Entra ID, comum em empresas que já centralizaram identidade corporativa no Microsoft 365, o ganho é duplo. Primeiro, evita recriar centenas de atribuições de permission set manualmente, conta por conta. Segundo, preserva um ponto relevante para LGPD: como o identity store ID não muda, políticas e integrações que referenciam esses identificadores continuam válidas antes e depois da migração, sem buraco na linha do tempo de quem tinha acesso a quê.

O que ainda fica por sua conta

A AWS não automatiza a configuração do novo provedor: cabe ao administrador configurar o Okta, o Entra ID ou o diretório nativo com o setup de login padrão antes da troca. Vale também revisar, depois da migração, se alguma política ainda usa "Resource": "*" combinada a atribuições antigas que deveriam ter sido revogadas; a preservação de IDs reduz o atrito da migração, mas não substitui uma varredura de acesso excessivo no pós-migração. O passo a passo oficial está documentado em "Change your identity source", no guia do usuário do IAM Identity Center.

Fonte 1: AWS What's New (https://aws.amazon.com/about-aws/whats-new/2026/10/iam-identity-center-chg-id-src-from-ad/)

AWS IAM Identity Center simplifies identity source changes from Active Directory - AWS

Skip to main content

AWS IAM Identity Center simplifies identity source changes from Active Directory

Posted on: Oct 20, 2026

AWS IAM Identity Center now retains your workforce identities and their assignments when you change your identity source from Active Directory to an external identity provider (IdP), such as Okta or Microsoft Entra ID, or to the Identity Center directory. Specifically, it preserves your users, groups, group memberships, permission set assignments, and application assignments. Previously, this change required you to recreate them in IAM Identity Center.

IAM Identity Center helps you connect your workforce identities to AWS once and manage their access centrally across AWS applications and accounts. When you change your identity source from Active Directory, your existing identity store remains in place, so your users and groups keep the same IDs. As a result, users retain their access to AWS accounts and applications, and policies that reference your user IDs, group IDs, or identity store ID continue to work.

To make this change, configure your new identity source with the standard setup required for users to sign in. After the change, your workforce signs in through your dual-stack AWS access portal URL. Changing your identity source in the other direction, to Active Directory, works as before. This feature is available for organization instances of IAM Identity Center in all AWS Regions where IAM Identity Center is available. IAM Identity Center is provided at no additional cost.

To get started, navigate to the IAM Identity Center console. For more information, see Change your identity source in the IAM Identity Center User Guide. To learn more about IAM Identity Center, visit the product detail page .

Fonte: AWS What's New