DEV Community: Eduardo Silva

Staged Rollout no Microsoft Entra Connect: migrando da federação para autenticação em nuvem sem drama

Eduardo Silva — Fri, 30 Oct 2026 11:58:23 +0000

Staged Rollout no Microsoft Entra Connect: migrando da federação para autenticação em nuvem sem drama

Se você administra um ambiente híbrido com AD FS (ou outro provedor de federação) e está pensando em migrar para autenticação gerenciada no Microsoft Entra ID (antigo Azure AD), provavelmente já se perguntou: "como eu testo isso com um grupo pequeno de usuários antes de virar a chave pra empresa inteira?"

A resposta é o Staged Rollout (implantação em estágios) do Microsoft Entra Connect — um recurso que existe exatamente para isso, mas que ainda é pouco usado porque muita documentação trata a migração como um "tudo ou nada". Neste artigo vou mostrar como configurar o Staged Rollout na prática, os cuidados que evitam dor de cabeça e como validar que está funcionando antes do corte definitivo do domínio.

O que é o Staged Rollout, de fato

O Staged Rollout é um mecanismo de teste temporário para organizações com domínios federados. Ele permite mover um grupo de usuários — via grupo de segurança — para autenticação em nuvem (Password Hash Sync, Pass-through Authentication ou Autenticação baseada em certificado), mesmo com o domínio ainda configurado como federado no Entra ID.[1]

Ponto importante: não é uma configuração permanente. A recomendação oficial da Microsoft é manter o provedor de identidade federado ativo como fallback durante os testes, e completar o corte (cutover) do domínio para autenticação gerenciada depois que a validação for bem-sucedida. Continuar usando Staged Rollout por muito tempo, sem IdP federado de apoio, pode gerar falhas inesperadas de autenticação.[1]

Combinações suportadas:

Password Hash Sync + Seamless SSO
Pass-through Authentication + Seamless SSO
Autenticação baseada em certificado (CBA)
Azure MFA

PHS + PTA + Seamless SSO simultâneos não são suportados na mesma rollout.[1]

Pré-requisitos antes de habilitar

Tenant Microsoft Entra com domínios federados.
Decisão já tomada sobre qual mecanismo você vai migrar: PHS ou PTA.
Se for usar PTA, um servidor Windows Server 2012 R2+ dedicado (nunca o próprio servidor do Entra Connect) para rodar o agente de autenticação, com conectividade de saída liberada para os endpoints da Microsoft.[1]
Recomendado habilitar Seamless SSO para experiência de login silenciosa — em estações Windows 10/Server 2016+ isso ocorre via Primary Refresh Token (PRT).[1]
Papel de Hybrid Identity Administrator no tenant para configurar o Staged Rollout.
Se o cenário envolve mover de federado para autenticação em nuvem, confirme que o atributo synchronizeUpnForManagedUsersEnabled está como true — sem isso o Entra ID não permite sincronizar atualizações de UPN para contas licenciadas usando autenticação gerenciada.[1]

Passo a passo para habilitar

A configuração acontece direto no portal do Microsoft Entra, não no instalador do Entra Connect:

Acesse o Microsoft Entra admin center com uma conta Hybrid Identity Administrator.
Navegue até Entra ID > Entra Connect > Connect Sync.
Na página do Microsoft Entra Connect, em Staged rollout of cloud authentication, clique em Enable staged rollout for managed user sign-in.
Habilite a(s) opção(ões) desejada(s): Password Hash Sync, Pass-through Authentication, Seamless SSO ou Certificate-based Authentication.
Adicione um grupo de segurança a cada funcionalidade habilitada.

Alguns limites que pegam muita gente desprevenida:

Máximo de 10 grupos por funcionalidade (PHS, PTA e Seamless SSO contam separadamente).
Grupos aninhados e dinâmicos não são suportados — e contatos dentro do grupo bloqueiam a adição.
Ao adicionar um novo grupo pela primeira vez, você fica limitado a 200 usuários para evitar timeout na interface; depois disso pode adicionar mais membros diretamente ao grupo.
Alterações em um grupo já existente (adicionar/remover membros) podem levar até 24 horas para ter efeito.[1]

Recomendação prática: use grupos somente na nuvem (cloud-only) em vez de grupos sincronizados do AD on-premises, justamente para evitar a latência extra da sincronização do Entra Connect antes mesmo da propagação do Staged Rollout.[1]

O detalhe que ninguém avisa: o "um login extra"

Quando um usuário entra num grupo de Staged Rollout, a troca de federado para gerenciado não é instantânea. Ele precisa completar um login interativo adicional usando o método de autenticação federado atual; só depois desse login o Entra atualiza o estado do usuário e passa a aplicar autenticação gerenciada nos acessos seguintes. O mesmo vale no caminho inverso quando o usuário é removido do grupo.[1]

Isso também acontece após eventos de remediação do Entra ID Protection (SSPR, remediação de risco, dismissal de risco), que podem resetar o estado de Staged Rollout do usuário.[1]

Se isso for um problema de experiência para o seu piloto, a Microsoft recomenda emitir um Temporary Access Pass (TAP) logo após adicionar o usuário ao grupo: como o Entra avalia o TAP antes de redirecionar para o IdP federado, o usuário entra direto pela tela do Entra sem precisar do login federado extra.[1]

Validando que está funcionando

Depois de adicionar o grupo:

Em uma sessão de navegador privada (fora da rede corporativa), acesse a página de Apps e digite o UPN de um usuário do grupo piloto. Se o Staged Rollout estiver ativo, ele não será redirecionado para a página de login federado — vai direto para a tela de login com a marca do tenant Entra.
Confirme o login no relatório de atividade de sign-in do Entra, filtrando pelo UPN do usuário.
Para Seamless SSO, o teste é feito na rede interna: o usuário deve ser logado silenciosamente, com a mensagem "Trying to sign you in..." aparecendo brevemente antes do acesso.[1]

E se a sincronização travar no meio do processo?

Durante o piloto é comum revisar a saúde da sincronização. Dois comandos que valem a pena ter na manga no servidor do Entra Connect:

Import-Module ADSync
Get-ADSyncScheduler

Confirme que SyncCycleEnabled está True e que CurrentlyEffectiveSyncCycleInterval corresponde ao intervalo configurado (padrão de 30 minutos).[3]

Se aparecerem erros de objeto específico no relatório de sincronização (por exemplo, referência de objeto não encontrada), o fluxo de correção típico é:

# Força um ciclo delta depois de corrigir/remover o objeto problemático
Start-ADSyncSyncCycle -PolicyType Delta

seguido da conferência de que a exclusão ou correção foi propagada corretamente para o Entra ID, usando o Relatório de Erros de Sincronização disponível no Microsoft Entra Connect Health, atualizado a cada 30 minutos.[2]

Conclusão

O Staged Rollout resolve um problema real de migração híbrida: testar autenticação em nuvem com um grupo pequeno e controlado, sem comprometer o restante da organização que ainda depende do federado.[1] Os pontos que mais geram confusão na prática são: (1) o Staged Rollout não substitui o corte definitivo do domínio — ele é só uma ponte; (2) grupos dinâmicos/aninhados não funcionam, então planeje a governança de membership manualmente; e (3) o "um login extra" ao entrar/saída do grupo é esperado, e o TAP é a saída elegante pra suavizar isso durante o piloto.[1]

Se você está planejando migrar de AD FS para PHS ou PTA em 2026, vale montar primeiro um piloto de Staged Rollout com um grupo de TI ou early adopters antes de qualquer comunicado maior — o retrabalho de corrigir um cutover malfeito em produção custa muito mais tempo do que validar com calma antes.

Para quem quer aprofundar na arquitetura de identidade híbrida além do que cabe num artigo, o livro Microsoft Entra ID Handbook é uma referência prática sobre design seguro e escalável de ambientes Entra.

Sources

[1] https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-staged-rollout — Microsoft Entra Connect: Cloud authentication via Staged Rollout - Microsoft Learn
[2] https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-sync-errors — Microsoft Entra Connect: Troubleshoot errors during synchronization - Microsoft Learn
[3] https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-feature-scheduler — Microsoft Entra Connect Sync: Scheduler - Microsoft Learn

Windows LAPS: como implantar o LAPS moderno no Active Directory (passo a passo com PowerShell)

Eduardo Silva — Fri, 30 Oct 2026 09:01:24 +0000

Windows LAPS: como implantar o LAPS moderno no Active Directory (passo a passo com PowerShell)

Se você ainda administra senhas de administrador local "na mão" ou usa o LAPS legado (aquele módulo AdmPwd.PS), vale a pena parar e migrar para o Windows LAPS, a versão nativa que a Microsoft integrou ao próprio Windows a partir das atualizações de abril de 2023 (e nativamente no Windows Server 2025 e Windows 11). Ele resolve um problema clássico de infraestrutura: senha de administrador local repetida em todas as máquinas, nunca rotacionada, e sem controle de quem pode lê-la.

Neste artigo mostro como preparar o Active Directory, extender o schema, configurar a política via GPO e consultar as senhas via PowerShell — sem inventar comando nenhum, tudo conferido na documentação oficial da Microsoft.

Por que migrar do LAPS legado

O Windows LAPS não é só um "rebranding" do LAPS clássico. Ele passou a fazer parte do sistema operacional (sem precisar instalar um MSI separado em todo cliente), ganhou suporte a backup de senha tanto no Active Directory quanto no Microsoft Entra ID (cenário híbrido), e trouxe um módulo PowerShell novo com cmdlets próprios. A tabela de equivalência entre os dois mundos ajuda bastante na migração:

Windows LAPS	LAPS legado (AdmPwd.PS)
`Get-LapsADPassword`	`Get-AdmPwdPassword`
`Update-LapsADSchema`	`Update-AdmPwdADSchema`
`Set-LapsADAuditing`	`Set-AdmPwdAuditing`
`Set-LapsADComputerSelfPermission`	`Set-AdmPwdComputerSelfPermission`
`Set-LapsADReadPasswordPermission`	`Set-AdmPwdReadPasswordPermission`
`Set-LapsADResetPasswordPermission`	`Set-AdmPwdResetPasswordPermission`

Além disso, cmdlets novos sem equivalente no legado, como Get-LapsDiagnostics, Invoke-LapsPolicyProcessing e Reset-LapsPassword (rotação imediata de senha), facilitam bastante o dia a dia de quem precisa resolver chamado com urgência.[1]

Requisitos de domínio

Antes de sair rodando comando, confirme o Nível Funcional do Domínio (DFL — Domain Functional Level):

DFL anterior a 2016: só é possível armazenar a senha em texto claro (protegida por ACL no AD), sem criptografia, e sem suporte a gerenciamento da conta DSRM em controladores de domínio.
DFL 2016 ou superior: já é possível habilitar criptografia da senha no AD. Mesmo assim, DCs com Windows Server 2016 ou anteriores não suportam Windows LAPS e não participam do gerenciamento de conta DSRM.
DFL 2016+ com DCs apenas Windows Server 2019 ou mais recentes: cenário ideal — criptografia e gerenciamento de DSRM totalmente suportados.[4]

Na prática: se seus controladores de domínio ainda são 2016 ou mais antigos, planeje a atualização. Não dá para aproveitar 100% do recurso sem isso.

Passo 1 — Extender o schema do Active Directory

Esse é um passo único por floresta, e exige permissão de Schema Admins. Em um controlador de domínio (ou máquina com RSAT e o módulo LAPS instalado):

Update-LapsADSchema -Verbose

Esse cmdlet adiciona os atributos novos do Windows LAPS ao schema (substitui o antigo Update-AdmPwdADSchema do LAPS legado). É irreversível e afeta toda a floresta, então rode isso fora do horário de pico e com change management aprovado.[3]

Passo 2 — Configurar permissões na OU

Depois de extender o schema, defina quem pode ler a senha e quem pode resetar/expirar o prazo. Isso é feito por OU, usando os cmdlets de permissão:

# Permite que os computadores da OU atualizem sua própria senha LAPS no AD
Set-LapsADComputerSelfPermission -Identity "OU=Estacoes,DC=suaempresa,DC=local"

# Concede ao grupo de suporte permissão para LER a senha
Set-LapsADReadPasswordPermission -Identity "OU=Estacoes,DC=suaempresa,DC=local" -AllowedPrincipals "SUAEMPRESA\GT-Suporte-N2"

# Concede ao mesmo grupo permissão para forçar expiração/reset da senha
Set-LapsADResetPasswordPermission -Identity "OU=Estacoes,DC=suaempresa,DC=local" -AllowedPrincipals "SUAEMPRESA\GT-Suporte-N2"

Se quiser auditar quem está lendo as senhas (recomendado para qualquer ambiente com exigência de compliance), use:

Set-LapsADAuditing -Identity "OU=Estacoes,DC=suaempresa,DC=local" -AuditType Success,Failure

E para descobrir rapidamente quais identidades já têm direitos estendidos numa OU (útil em auditoria ou troubleshooting de permissão):

Find-LapsADExtendedRights -Identity "OU=Estacoes,DC=suaempresa,DC=local"

Todos esses cmdlets vêm do módulo LAPS, nativo a partir das atualizações de 2023 em diante.[1]

Passo 3 — Configurar a política (GPO)

O Windows LAPS lê configuração de quatro raízes de registro possíveis — CSP (Intune), Group Policy, configuração local, e a chave legada do LAPS antigo — sempre nessa ordem de prioridade, e sem herdar configuração entre elas. Ou seja: não misture GPO com Intune CSP na mesma máquina, escolha um mecanismo.[5]

Se for usar GPO (cenário on-premises mais comum), copie os templates ADMX do LAPS para o Central Store antes de editar a política, e configure pelo menos:

BackupDirectory = Active Directory
PasswordComplexity
PasswordLength
PasswordAgeDays
ADPasswordEncryptionEnabled = habilitado (se o DFL permitir)

Depois de vincular a GPO na OU correta, force o processamento imediato numa estação de teste em vez de esperar o ciclo normal do GPO:

Invoke-LapsPolicyProcessing

Passo 4 — Consultar e rotacionar a senha

Para ler a senha atual de uma máquina (exige permissão de leitura concedida no Passo 2):

Get-LapsADPassword -Identity "ESTACAO01" -AsPlainText

A saída traz ComputerName, Account, Password, PasswordUpdateTime e ExpirationTimestamp. Sem o parâmetro -AsPlainText, a senha vem como SecureString.[2]

Se precisar forçar a rotação imediatamente (por exemplo, depois que um técnico usou a senha localmente):

Reset-LapsPassword

Esse cmdlet é novo — não existe equivalente no LAPS legado — e evita que você precise esperar o PasswordAgeDays configurado na política.[1]

Conclusão

O Windows LAPS resolve de forma nativa (sem instalar agente extra) um problema de segurança básico que ainda aparece em muita auditoria: senha de admin local fixa e compartilhada entre máquinas. Os pontos que eu mais destacaria para quem vai implantar:

Confira o DFL do domínio antes de tudo — ele decide se você tem criptografia de senha e gerenciamento de DSRM disponíveis.[4]
Update-LapsADSchema é único por floresta e irreversível — trate como mudança de produção, com aprovação.[3]
Permissões de leitura/reset são por OU, via Set-LapsADReadPasswordPermission e Set-LapsADResetPasswordPermission — modele seus grupos de suporte antes de distribuir a política.[1]
Não misture GPO e Intune CSP na mesma máquina — o Windows LAPS usa apenas a primeira raiz de registro com configuração explícita que encontrar.[5]

Com isso configurado, a troca de senha de admin local deixa de ser um processo manual (ou, pior, uma senha que nunca muda) e passa a ser auditável, automatizada e integrada ao próprio AD.

Sources

[1] https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell — Windows LAPS PowerShell Cmdlets Overview
[2] https://learn.microsoft.com/en-us/powershell/module/laps/get-lapsadpassword — Get-LapsADPassword
[3] https://learn.microsoft.com/en-us/powershell/module/laps/update-lapsadschema — Update-LapsADSchema
[4] https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory — Get started with Windows LAPS and AD
[5] https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-policy-settings — Configure Policy Settings for Windows LAPS