DEV Community

Eduardo Silva
Eduardo Silva

Posted on

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

#windows #sysadmin #powershell #activedirectory

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Confira o DFL do domínio antes de tudo — ele decide se você tem criptografia de senha e gerenciamento de DSRM disponíveis.[4]
  2. Update-LapsADSchema é único por floresta e irreversível — trate como mudança de produção, com aprovação.[3]
  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]
  4. 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

Top comments (0)