What Is Windows LAPS não implantado?
Windows LAPS não implantado significa que o ambiente ainda não possui um processo gerenciado para definir, rotacionar, armazenar e recuperar a senha do administrador local em estações Windows e servidores. O Windows Local Administrator Password Solution existe para resolver um problema muito prático: a conta de administrador local costuma permanecer por motivos de suporte, build ou contingência, mas, se a senha for estática ou reutilizada, a invasão de uma única máquina pode abrir o mesmo segredo em muitos outros dispositivos.
A orientação atual da Microsoft é usar Windows LAPS, e não depender de rotação manual. O Windows LAPS pode fazer backup da senha no Active Directory ou no Microsoft Entra ID e oferece políticas nativas, cmdlets PowerShell e auditoria. Se o recurso não foi implantado, foi aplicado ao escopo errado ou nunca foi distribuído de forma consistente via GPO, Intune ou CSP, o risco continua real mesmo que a organização acredite que o acesso admin local seja raro.
Por isso, Windows LAPS não implantado costuma aparecer ao lado de GPO mal configurado como vetor de ataque e Contas obsoletas e superprivilegiadas no AD. Em todos esses casos, a pergunta não é apenas quem tem direitos de administrador, mas se o ciclo de vida do segredo continua controlável após uma violação.
How Windows LAPS não implantado Works
Windows LAPS já vem integrado nas versões modernas do Windows e pode gerenciar uma conta de administrador local por dispositivo. A Microsoft documenta dois destinos de backup suportados:
- Windows Server Active Directory
- Microsoft Entra ID
No cliente, você configura a conta gerenciada, a complexidade da senha, a idade máxima, as ações pós-autenticação e o diretório de backup. Na administração, define quem pode ler a senha, quem pode disparar nova rotação e como a recuperação será auditada.
Para Entra ID, a Microsoft também estabelece pré-requisitos importantes:
- o dispositivo deve estar Microsoft Entra joined ou hybrid joined
- dispositivos apenas registered não são suportados
- o LAPS deve estar habilitado no tenant, e a política do cliente precisa apontar
BackupDirectorypara Entra ID
Para Active Directory, o Windows LAPS depende de extensão de esquema e de direitos delegados para armazenar e proteger o segredo. A Microsoft fornece cmdlets dedicados para atualizar o esquema, consultar senhas, descobrir quem pode lê-las e redefinir a rotação.
| Área do LAPS | O que a Microsoft fornece | Por que isso importa |
|---|---|---|
| Política do cliente | Configurações nativas do Windows LAPS | Impõe idade, tamanho, complexidade e conta gerenciada |
| Destino de backup | AD ou Entra ID | Torna a senha recuperável sem planilhas ou anotações |
| Controle de acesso | Papéis ou direitos delegados | Evita que conveniência de helpdesk vire exposição ampla |
| Ferramentas PowerShell | Get-LapsADPassword, Get-LapsAADPassword, Find-LapsADExtendedRights, Reset-LapsPassword | Permite medir implantação e recuperação |
A Microsoft também documenta o caminho de migração a partir do antigo Microsoft LAPS. Isso importa porque muitos ambientes acreditam que “já têm LAPS”, quando na prática possuem apenas uma implantação antiga, parcial ou nunca concluída.
The Attack Chain
Etapa 1 - Comprometer um host que ainda compartilha uma senha local reutilizável
Os atacantes não precisam de Domain Admin para aproveitar uma higiene ruim de senhas locais. Basta um host em que a conta de administrador local continue acessível e a senha possa ser descoberta, capturada ou reutilizada. Se o mesmo segredo funcionar em vários sistemas, a intrusão deixa de ser local rapidamente.
Etapa 2 - Reutilizar a senha para movimento lateral
Quando a senha ou o hash NTLM vale em vários dispositivos, canais de administração remota passam a ser muito mais úteis para o atacante. O problema central não é apenas a existência da conta local, mas o fato de o segredo não ser único por máquina nem rotacionar com rapidez após exposição.
# Verificar se um dispositivo registra atividade recente do Windows LAPS
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Se esse log estiver vazio em máquinas que deveriam estar cobertas, ou se não houver rotação e recuperação no caminho esperado, a implantação está incompleta.
Etapa 3 - Ampliar acesso mais rápido do que a rotação manual consegue reagir
Sem Windows LAPS, muitas organizações dependem de scripts de emergência, tickets e mudanças manuais durante um incidente. Isso desacelera a contenção e aumenta o tempo em que a mesma senha local pode ser reutilizada. É por isso que o assunto se conecta diretamente a Caminhos de ataque no Active Directory até Domain Admin: o LAPS não impede toda escalada de privilégio, mas sua ausência oferece um ótimo ponto de apoio para movimento lateral.
Por que uma implantação parcial continua perigosa
O cenário mais enganoso não é “LAPS não existe”, e sim “LAPS existe mais ou menos”. Se workstations comuns estão cobertas, mas jump hosts, servidores antigos ou estações administrativas ficam fora, o controle perde grande parte do valor. Os atacantes procuram exatamente os sistemas em que a senha local ainda é previsível ou compartilhada. Uma implantação parcial cria sensação de maturidade sem entregar a proteção esperada.
Por isso, a revisão não deve parar na existência da política. É preciso validar grupos-alvo, exceções, direitos de leitura e, principalmente, quais máquinas estão protegidas de verdade. Uma GPO visível no console não equivale a uma senha local realmente rotacionada e recuperável.
Detection
A melhor detecção combina cobertura de política, validação de backup e revisão de permissões.
| Indicador | Fonte | O que verificar |
|---|---|---|
| Não há política Windows LAPS efetiva | GPO, Intune, CSP ou política local | Os dispositivos gerenciados recebem configuração LAPS de fato? |
| Não há backup recente em AD ou Entra ID | Get-LapsADPassword ou Get-LapsAADPassword | As senhas estão sendo armazenadas e rotacionadas? |
| Não há atividade LAPS no endpoint | Microsoft-Windows-LAPS/Operational | O cliente está processando a política corretamente? |
| Há leitura excessiva dos segredos | Find-LapsADExtendedRights ou revisão de papéis Entra | Muitas identidades podem ler senhas locais? |
# Verificar quem pode ler senhas LAPS em uma OU no AD
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'
# Validar a recuperação de uma senha armazenada no AD
Get-LapsADPassword -Identity WS-001 -AsPlainText
Para implantações com Entra ID, a Microsoft também documenta Get-LapsAADPassword e recuperação baseada em papéis. Uma boa revisão precisa verificar os dois lados: a senha existe e apenas os papéis corretos conseguem recuperá-la.
Remediation
💡 Quick Win: escolha primeiro um modelo de backup suportado. Um ambiente meio migrado entre gestão manual, Microsoft LAPS legado e Windows LAPS costuma gerar mais confusão do que proteção.
Uma sequência pragmática de remediação costuma seguir esta ordem:
- Definir a autoridade de backup. Use Active Directory ou Microsoft Entra ID conforme o modelo de join e gestão do dispositivo.
- Preparar diretório e permissões. Para AD, atualize o esquema e revise direitos de leitura e reset. Para Entra, habilite LAPS no tenant e valide os papéis de recuperação.
- Configurar a política do cliente. Defina conta gerenciada, complexidade, idade, destino de backup e ações pós-autenticação.
- Validar processamento com sucesso. Use o log do Windows LAPS e os cmdlets de recuperação para confirmar que as senhas giram e são armazenadas.
- Remover deriva. Limpe scripts antigos, senhas compartilhadas e restos do Microsoft LAPS anterior.
- Auditar direitos de recuperação. Garanta que apenas as equipes corretas possam ler ou redefinir senhas.
# Exemplo de sequência de implantação e validação em AD
Update-LapsADSchema
Get-LapsADPassword -Identity WS-001
Reset-LapsPassword
Validate Before You Close the Finding
Uma implantação não está concluída porque existe uma política. Ela está concluída quando dispositivos representativos rotacionam suas senhas, o backend de backup contém segredos atuais e o caminho de recuperação foi validado de ponta a ponta pela função autorizada. O conjunto mínimo de validação deveria cobrir uma workstation padrão, uma estação administrativa se aplicável, uma classe relevante de servidor e um teste real de recuperação.
Essa validação também precisa documentar quem pode ler as senhas e quem pode acionar rotações. Caso contrário, o ambiente apenas troca uma senha local compartilhada por uma superfície ampla demais de recuperação.
O que validar separadamente em implantações com AD e Entra ID
Muitos projetos de LAPS não falham por falta de tecnologia, mas por misturar modelos operacionais. A Microsoft separa claramente Windows LAPS para Active Directory e para Microsoft Entra ID. Em implantações com AD, não basta apenas estender o esquema; também é preciso verificar se os direitos delegados de leitura estão limitados à OU ou ao grupo correto, se Get-LapsADPassword retorna valores atuais em dispositivos representativos e se Reset-LapsPassword realmente dispara uma nova rotação. Só assim fica claro se o caminho de recuperação funcionará em um incidente e não apenas na documentação.
Em implantações com Entra ID, os controles críticos são outros. A Microsoft só oferece suporte a dispositivos Entra joined ou hybrid joined; dispositivos apenas registrados não são suportados. Além disso, o LAPS deve ser habilitado no tenant e a política do cliente precisa definir BackupDirectory como Microsoft Entra ID. Os direitos de recuperação também merecem validação separada, porque a Microsoft distingue entre permissões para ler a senha e para ler metadados de senha. Um rollout só é confiável quando a equipe prevista testa ambos os caminhos: o backup correto do segredo e uma recuperação auditável quando ela realmente é necessária.
Outro erro frequente é presumir que “algum LAPS já existe” e isso basta. A Microsoft documenta um caminho explícito de migração a partir do antigo Microsoft LAPS. Por isso a aceitação do rollout deve esclarecer se GPOs antigas, scripts legados ou procedimentos paralelos ainda continuam ativos. Enquanto vários modelos de gestão coexistirem, surgem exceções, donos duplicados e lacunas de recuperação. Um piloto sólido valida AD e Entra separadamente, confirma quais dispositivos estão realmente cobertos e mede quanto tempo uma nova rotação leva para ficar visível depois de um uso ou de um reset.
Também vale revisar estações administrativas, jump hosts e servidores privilegiados como uma onda própria do piloto. Nesses sistemas importa ainda mais confirmar as Post-Authentication-Actions e garantir que o Windows LAPS esteja gerenciando apenas a conta local planejada por dispositivo, sem deixar contas antigas fora do controle de rotação.
How EtcSec Detects This
EtcSec associa esse tema a LAPS_NOT_DEPLOYED e GPO_LAPS_NOT_DEPLOYED. A distinção útil é saber se o Windows LAPS está ausente por completo ou se a organização acredita tê-lo implantado, embora nenhuma política durável alcance os endpoints certos.
ℹ️ Note: EtcSec verifica automaticamente cobertura ausente ou inconsistente de LAPS em auditorias de Active Directory para separar “recurso disponível” de “recurso realmente protegendo endpoints”.
Official References
- Microsoft Learn: What is Windows LAPS?
- Microsoft Learn: Windows LAPS PowerShell Cmdlets Overview
- Microsoft Learn: Use Windows Local Administrator Password Solution with Microsoft Entra ID
- Microsoft Learn: Prepare for Windows LAPS deployment and migration
Related Reading
Para priorizar esse tema corretamente, revise também GPO mal configurado como vetor de ataque, Contas obsoletas e superprivilegiadas no AD, Segurança de senhas no Active Directory: erros de configuração que importam, Como auditar a segurança do Active Directory: checklist prática para equipes internas e Monitoramento de segurança do Active Directory: eventos que realmente importam. Esses temas mostram por que rotação de senha local só funciona quando escopo, permissões e auditoria andam juntos.
