Windows LAPS: Gerir Passwords de Administrador Local

A password partilhada do administrador local é uma das vulnerabilidades mais exploradas em redes Windows: um único comprometimento dá acesso lateral a toda a frota. O Windows LAPS (Local Administrator Password Solution) resolve o problema nativo — gera uma password única, complexa e rotativa por dispositivo, com backup automático no Entra ID ou no Active Directory, sem agentes extra. Este artigo cobre a configuração em Entra-joined e AD-joined, o cenário DSRM nos controladores de domínio e o acesso de emergência à password.

Por que o Windows LAPS substitui o Microsoft LAPS legacy

O Windows LAPS é uma funcionalidade nativa do Windows (presente no Windows 11, Windows 10 suportado e Windows Server 2019+) que gere e faz backup da password do administrador local. O Microsoft LAPS legacy (a versão original de 2016, distribuída como MSI) — que todos instalávamos no AD — foi marcado como deprecated a partir do Windows 11 23H2: a instalação do pacote MSI está bloqueada nas versões mais recentes e a Microsoft não aceita alterações de código. A Microsoft mantém suporte ao legacy apenas em versões antigas onde já estava instalado.

O que muda na prática entre legacy e Windows LAPS:

Capacidade Microsoft LAPS legacy Windows LAPS
Backup da password AD apenas Entra ID ou Active Directory
Password do DSRM nos DCs Não Sim
Gestão de política GPO (DLL adicionar) CSP/Intune, GPO nativa ou registo
Rotação pós-autenticação Não Sim (grace period configurável)
Tamanho máximo da password 14 caracteres 64 caracteres
Histórico de passwords Não Sim (no AD)
Conta personalizada Não (Built-in Administrator) Sim (qualquer conta local)

A migração é cumulativa: o Windows LAPS pode ler as passwords gestionadas pelo legacy durante a transição (cenário de compatibilidade documentado pela Microsoft), mas o objectivo final é desinstalar o MSI antigo e mover a política para as raízes nativas.

Pré-requisitos e restrições por tipo de join

O Windows LAPS está disponível em Windows Server 2019 e posteriores e nos clientes Windows 10 e Windows 11 suportados. O estado de join do dispositivo determina o destino do backup:

  • Microsoft Entra-joined — backup da password apenas para o Entra ID.
  • Active Directory-joined — backup da password para o AD (ou para o Entra ID em cenários suportados híbridos).
  • Híbrido (Entra + AD) — escolher um dos directórios. Não é possível fazer backup para ambos em simultâneo.
  • Workplace-joined — não suportado.

A regra prática para PME: cloud-only usa Entra como destino. Ambientes com AD on-premise normalmente escolhem o AD como repositório — os admins já têm as ferramentas (ADUC, PowerShell AD) para o acesso de emergência.

Configuração em Entra-joined com Intune

Para frotas Entra-joined, o caminho de configuração é o Intune:

  1. Intune admin center → Endpoint security → Account protection → Create policy.
  2. Platform: Windows 10 and later. Profile: Local admin password solution (Windows LAPS).
  3. Configurar as definições principais:
Definição Valor recomendado Notas
Backup Directory Microsoft Entra ID Obrigatório em Entra-joined
Password Age (Days) 30 (default) Mínimo 7 no Entra, 1 no AD; máximo 365
Password Length 15+ (default 14) Mínimo 8, máximo 64
Password Complexity Large + small + numbers + specials 4 caracteres por complexidade
Administrator Account Name (opcional) Custom account; vazio = Built-in Administrator
Post-Authentication Actions Reset password and log off Ver secção abaixo
Post-Authentication Reset Delay 4–8 horas (consoante fluxo de suporte) Grace period após uso
  1. Atribuir a política a grupos de dispositivos (piloto primeiro).
  2. No dispositivo, forçar sync ou gpupdate e confirmar o evento de backup.

A retrieval é feita no Entra admin center → Devices → Local administrator password recovery (ou via Graph), com permissões de administrador. Cada consulta fica registada nos audit logs — importante para compliance e para detectar uso abusivo.

Configuração em AD-joined com GPO

Ambientes com Active Directory usam a GPO nativa do Windows LAPS ( ADMX incluída no Windows):

  1. Criar uma GPO em Computer Configuration > Policies > Administrative Templates > System > LAPS.
  2. Definir BackupDirectory = Active Directory.
  3. Ajustar PasswordAgeDays, PasswordLength, PasswordComplexity (o valor do AD deve estar preparado para passwords longas — ver callout).
  4. Configurar permissões no AD: o grupo de administradores que pode ler a password precisa de permissões estendidas no atributo msLAPS-Password (ou msLAPS-PasswordEncrypted), e o device precisa de permissão de escrita. O cmdlet Set-LapsADReadPasswordPermission configura a leitura:
Set-LapsADReadPasswordPermission -Domain "dominio.pt" -AllowedPrincipals "DOMINIO\HelpdeskTier"
Reset-LapsPassword -Identity "PC-PILOTO01" -WaitForProcessing

O Reset-LapsPassword força a rotação imediata (útil pós-uso ou para testar o pipeline). A leitura da password do AD faz-se com Get-LapsADPassword -Identity PC-PILOTO01 -AsPlainText — o cmdlet devolve a password e o timestamp de expiração.

Atenção: o schema do AD precisa das extensões do Windows LAPS (Update-LapsADSchema) antes do primeiro backup. Sem o schema actualizado, o backup falha com eventos no log do dispositivo. Num domínio grande, executar uma vez por floresta e verificar o objecto msLAPS-Password num OU de teste primeiro.

O cenário DSRM nos controladores de domínio

O Directory Services Restore Mode é o modo offline de um DC — a password DSRM é a “porta dos fundos” de emergência e costuma ser a mesma em todos os DCs (ou pior, esquecida). O Windows LAPS faz backup da password DSRM no AD:

  • Política: ADBackupDSRMPassword = Yes, nos DCs.
  • A password fica no atributo do objecto DC e a rotação segue a mesma política de idade.
  • Recuperação com Get-LapsADPassword -Identity "CN=DC01,OU=Domain Controllers,..." -AsPlainText (requer permissão de decrypt — o cmdlet descodifica automaticamente quando o utilizador é o AuthorizedDecryptor; sem essa permissão devolve DecryptionStatus: Unauthorized em vez de erro).

Para PME com 1–2 DCs, é a forma mais robusta de garantir que o DSRM está funcional quando é preciso — sem folhas de Excel com passwords.

Post-Authentication Actions: rotação após uso

A funcionalidade que distingue o Windows LAPS do legacy: depois de alguém usar a password do admin local para entrar, o dispositivo roda a password automaticamente ao fim do grace period configurado. Os valores de PostAuthenticationActions:

  • Reset password — roda a password, mantém a sessão activa (suave para o suporte).
  • Reset password and log off — roda e força logout (o mais seguro).
  • Reset password and reboot — para manutenção que exija restart.
  • Reset password, log off and reboot — máximo rigor.

O grace period (PostAuthenticationResetDelay) dá tempo para concluir a tarefa de suporte. Para equipas de suporte das PME, a combinação “Reset password and log off” com 4–8 horas de grace period equilibra segurança e operação — o admin não fica despejado a meio de uma intervenção.

Acesso de emergência e contas de contingência

O Windows LAPS cobre a password do admin local, mas não substitui o plano de contas de emergência:

  • No Entra ID: a Microsoft recomenda contas de break-glass cloud-only com FIDO2, excluídas de Conditional Access, testadas trimestralmente (doc oficial de emergency access).
  • No AD: a conta DSRM + a password do Built-in Administrator devem estar em cofre físico (safé) — o LAPS ajuda a garantir que a password do admin local dos PCs está fresca, mas o DC mantém requisitos próprios.
  • Estações sem LAPS aplicável: appliances, thin clients e sistemas não-Windows não são cobertos — documentar as excepções no inventário.

Erros comuns

Problema Causa Solução
Backup falha silenciosamente Schema AD sem extensões LAPS Update-LapsADSchema no domínio
Password não rota no intervalo Política em conflito (legacy MSI instalado) Desinstalar o MSI legacy; usar a GPO raiz LAPS nova
Admin não consegue ler password no AD Permissões msLAPS-Password não configuradas Set-LapsADReadPasswordPermission para o grupo Helpdesk
Backup falha em híbrido Backup para Entra e AD simultâneo Escolher um directório — o dual backup não é suportado
Post-authentication bloqueia suporte Grace period demasiado curto Aumentar PostAuthenticationResetDelay (4–8h)
Conta personalizada não gerida Nome no policy não existe no dispositivo Criar/standardizar a conta (Intune account protection) antes do LAPS

Checklist rápido de verificação

  • ✓ Schema AD actualizado (Update-LapsADSchema) em domínios AD-joined
  • ✓ Política LAPS atribuída e a aparecer nos eventos do dispositivo
  • ✓ Backup da password confirmado (Entra ou AD) para o piloto
  • ✓ Permissões de leitura configuradas para o grupo de suporte
  • ✓ Post-Authentication Actions definido (recomendação: reset + log off)
  • ✓ Password do DSRM a fazer backup nos DCs
  • ✓ MSI legacy desinstalado dos dispositivos
  • ✓ Teste de recuperação executado de ponta a ponta

Como evitar no futuro

  • Auditoria mensal dos eventos LAPS nos dispositivos (falhas de backup = dispositivos offline ou em política inconsistente).
  • Revisão trimestral das permissões de leitura — o grupo Helpdesk deve ser o menor possível.
  • Documentar as excepções (dispositivos sem LAPS) no CMDB/inventário com owner e prazo.
  • Testar a recuperação de emergência a cada 6 meses — password fresca inútil se o processo estiver partido.
  • Acompanhar o roadmap do Intune para account protection — novas funcionalidades do LAPS entram primeiro no CSP.

Artigos Relacionados