Lacunas de cobertura LAPS: auditoria e correção

Resumo: o que são lacunas de cobertura LAPS após a implementação?

As lacunas de cobertura LAPS após a implementação descrevem um ambiente Active Directory em que existe gestão de palavras-passe de administrador local, mas a proteção não chega a todas as máquinas ou identidades relevantes. Alguns computadores nunca recebem a política prevista. Outros continuam a usar armazenamento legado em texto simples, concedem direitos de recuperação de forma demasiado ampla ou mantêm uma palavra-passe exposta utilizável até a rotação ser concluída com êxito.

O Windows Local Administrator Password Solution gere e guarda uma cópia de segurança da palavra-passe de uma conta de administrador local. Entre os seus objetivos está a redução do movimento lateral através de credenciais locais reutilizadas. A visão geral do Windows LAPS da Microsoft descreve tanto a cópia de segurança no Active Directory como a implementação nativa mais recente. Um objeto de política, uma funcionalidade instalada ou um atributo preenchido são indícios a investigar; cada um responde a uma pergunta diferente de saber se todos os dispositivos previstos estão protegidos.

Este artigo pressupõe que o LAPS com cópia de segurança no AD já está presente. O nosso guia sobre Windows LAPS não implementado explica a ausência de um ciclo de vida das credenciais: palavras-passe de administrador local não geridas, estáticas ou partilhadas e como estabelecer a rotação. O nosso artigo sobre higiene de objetos de computador e esquema LAPS aborda o pré-requisito mais fundamental de um esquema não expandido, juntamente com a higiene de computadores e controladores de domínio. Aqui, o esquema existe e a implementação já começou; a tarefa é descobrir onde essa implementação falha.

Como funciona: quatro formas de o LAPS implementado perder proteção

1. Cobertura parcial do domínio

Uma implementação pode ter êxito numa OU piloto e deixar de fora servidores membros, estações de trabalho recém-provisionadas ou dispositivos movidos para outra OU. Isso deixa duas populações por detrás da mesma afirmação tranquilizadora: «usamos LAPS». Reveja o inventário previsto e o estado real dos dispositivos separadamente para estações de trabalho e servidores membros, em vez de permitir que uma grande população de estações de trabalho esconda um parque de servidores não gerido.

A cobertura também é diferente do bom funcionamento. Um atributo de expiração pode continuar preenchido enquanto um dispositivo está offline ou a aplicação da política falha. Registe se um computador apresenta indícios de Windows LAPS nativo, indícios da versão legada ou nenhum dos dois, e depois valide a atividade recente face à política de rotação configurada. Mantenha os objetos de computador desativados e os controladores de domínio explicitamente identificados no âmbito; a gestão de palavras-passe DSRM é um caso de utilização separado para DCs.

2. O atributo legado continua a ser o caminho de recuperação

As gerações usam atributos diferentes. A referência do esquema da Microsoft associa ms-Mcs-AdmPwdExpirationTime a msLAPS-PasswordExpirationTime e ms-Mcs-AdmPwd a msLAPS-Password. O valor nativo de msLAPS-Password contém dados da palavra-passe em texto simples, em JSON; msLAPS-EncryptedPassword contém dados encriptados. Assim, o prefixo msLAPS-, por si só, não prova a existência de encriptação.

O Windows LAPS pode respeitar políticas antigas através do modo de emulação do Microsoft LAPS legado. A emulação mantém o armazenamento em texto simples no AD e não disponibiliza encriptação nativa de palavras-passe. Encontrar um atributo legado deve desencadear uma revisão da política ativa e do estado da migração, em vez da suposição de que a extensão cliente antiga está necessariamente em execução. A política nativa do Windows LAPS tem precedência sobre a política legada. A emulação também exige que a extensão do lado do cliente do Microsoft LAPS legado esteja ausente do dispositivo gerido.

3. A obtenção de palavras-passe está delegada de forma demasiado ampla

A rotação não compensa a recuperação da palavra-passe atual por uma entidade de segurança não autorizada. Verifique tanto a permissão para obter o material armazenado como, quando é usada encriptação, a entidade autorizada a desencriptar. São controlos distintos. Um grupo de suporte com uma responsabilidade de recuperação aprovada exige uma revisão dos seus membros; não se torna seguro apenas porque o nome contém «LAPS».

Uma delegação ampla na OU pode afetar muitos computadores. As permissões explícitas de computadores também podem diferir da configuração de referência da OU. Reveja em conjunto concessões herdadas, exceções, membros dos grupos e a população aprovada para recuperação. Uma concessão a um grupo não é o mesmo que uma contagem das pessoas individuais que podem exercê-la.

4. A exposição da palavra-passe persiste após a revisão de acesso

Uma alteração da ACL restringe futuras leituras do diretório. Não pode retirar uma palavra-passe já copiada para um ticket, uma transcrição, a saída de um script ou a sessão de outra pessoa. Estas são possibilidades a investigar num incidente, não provas de que ocorreu uma fuga num ambiente específico.

A cadeia de ataque: dos direitos de recuperação ao acesso local

Uma sequência de falha plausível começa com a compromissão de uma identidade que tem direitos de recuperação não previstos. Se essa entidade de segurança conseguir obter uma palavra-passe utilizável de administrador local, o atacante ganha uma credencial para o computador afetado. O alcance resultante depende do estado da conta, do acesso de rede e dos controlos de autenticação local; um atributo legível não equivale à tomada automática do domínio.

Um dispositivo sem cobertura apresenta um caminho diferente: a sua palavra-passe local permanece fora do ciclo de vida LAPS previsto. Um dispositivo que usa apenas a versão legada pode efetuar a rotação corretamente e, ainda assim, expor material de recuperação em texto simples a uma população demasiado ampla com direitos de leitura. Estas condições podem coexistir, mas exigem correções diferentes. Alargar o âmbito da política não elimina leitores excessivos, e ativar a encriptação não inclui um dispositivo excluído no âmbito.

Na triagem de incidentes, identifique o computador, a geração da palavra-passe armazenada, a população autorizada para recuperação e a rotação bem-sucedida após a contenção. Evite exportar palavras-passe reais apenas para demonstrar a fragilidade. Metadados, provas de ACL e registos dos endpoints costumam permitir uma primeira avaliação mais segura.

Medir a cobertura e as permissões de leitura

Encontrar computadores com indícios de expiração nativa

As orientações de migração da Microsoft identificam um msLAPS-PasswordExpirationTime novo ou atualizado como uma forma de acompanhar a transição para o Windows LAPS nativo. O comando abaixo é uma adaptação para auditoria dos parâmetros documentados de filtro LDAP e propriedades de Get-ADComputer, usando o atributo documentado. Substitua a OU de exemplo pelo seu âmbito de auditoria aprovado. Este comando é disponibilizado ao leitor; não foi executado contra um domínio de produção para este artigo.

Get-ADComputer -SearchBase 'OU=Workstations,DC=corp,DC=example' -LDAPFilter '(msLAPS-PasswordExpirationTime=*)' -Properties 'msLAPS-PasswordExpirationTime',OperatingSystem,Enabled

O resultado é uma lista de computadores com indícios de expiração nativa, não uma percentagem nem uma prova de que todos os resultados correspondem a dispositivos em bom funcionamento. Compare-a com o inventário esperado de dispositivos para identificar computadores em falta. Um valor de expiração legado num computador em falta pode indicar uma implementação anterior. Verifique o estado desativado, o diretório previsto para a cópia de segurança e a configuração real do endpoint antes de classificar uma lacuna de cobertura. Um dispositivo com cópia de segurança no Entra não deve ser avaliado pela ausência de um atributo de cópia de segurança no AD.

Para um cálculo de cobertura defensável, concilie o mesmo inventário de estações de trabalho e servidores membros ativados e dentro do âmbito com indícios de implementação nativa ou legada. Indique que gerações contam como cobertas. Mantenha a perspetiva de migração para a versão nativa separada da perspetiva de implementação de qualquer geração. Depois reveja a atualidade dos valores de expiração e a rotação bem-sucedida; a presença de atributos, por si só, não comprova nenhuma delas.

Enumerar entidades de segurança com direitos de recuperação

A referência de Find-LapsADExtendedRights documenta a consulta de OU e a opção -IncludeComputers. Este exemplo substitui a OU por uma OU de auditoria e inclui permissões ao nível do computador:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=example' -IncludeComputers

Compare as entidades de segurança devolvidas com uma lista aprovada para recuperação e inspecione os membros relevantes e as permissões herdadas ou explícitas. Trate isto como uma enumeração de permissões, em vez de prova de uma leitura de palavra-passe concluída ou de uma reconstrução exaustiva do acesso efetivo. Preserve os identificadores dos objetos e das entidades beneficiárias das permissões nas provas da auditoria, sem armazenar valores de palavras-passe.

Para uma verificação autorizada de recuperação num computador, a referência de Get-LapsADPassword da Microsoft documenta o seguinte padrão, com um nome de computador de exemplo substituído. Isto obtém material de credenciais; não é uma consulta apenas de metadados e não foi executada contra um domínio de produção para este artigo.

Get-LapsADPassword -Identity 'WS-001'

Sem -AsPlainText, as palavras-passe devolvidas são encapsuladas em SecureString. Inspecione Source, DecryptionStatus e AuthorizedDecryptor para distinguir os resultados de armazenamento e desencriptação. O cmdlet também obtém palavras-passe legadas ms-Mcs-AdmPwd, mas os resultados legados não incluem Account e PasswordUpdateTime; uma hora de atualização vazia nesses resultados não é prova de uma rotação falhada.

Deteção: ler o registo operacional LAPS do cliente

A Microsoft documenta estes sinais na referência do registo de eventos do Windows LAPS:

Recolha estes eventos de Microsoft-Windows-LAPS/Operational nos clientes geridos. O canal correspondente num controlador de domínio diz respeito à sua própria gestão de DSRM, não à atividade dos clientes associados ao domínio. Um ciclo de processamento bem-sucedido não tem necessariamente de incluir rotação se nenhuma atualização de palavra-passe era devida.

Correlacione os eventos por dispositivo e ciclo de processamento. Use a política configurada para decidir quando deveria ter ocorrido uma atualização. Estes eventos operacionais comprovam os resultados do processamento e das atualizações; não comprovam quem obteve a palavra-passe armazenada. A ausência de eventos também exige uma verificação do bom funcionamento da recolha antes de ser tratada como ausência de atividade LAPS.

Correção: resolver cada falha separadamente (Remediation)

1. Reparar o âmbito da política e as permissões de escrita

Atribua um responsável a cada computador sem cobertura. Verifique o diretório previsto para a cópia de segurança e o direcionamento da política, e depois repare a causa real: localização na OU, filtragem, precedência de políticas ou delegação de escrita. O procedimento de implementação no AD da Microsoft documenta o seguinte comando, com uma OU de exemplo substituída:

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example'

Isto concede permissões de autoatualização para atributos nativos do Windows LAPS; não configura a política nem comprova uma cópia de segurança bem-sucedida. Para implementações legadas ou de emulação, use as ferramentas de ACL legadas descritas nas orientações de emulação da Microsoft, em vez de presumir que este cmdlet nativo repara permissões legadas. Volte a verificar a lista de candidatos e as provas de atualização dos endpoints após a correção.

2. Restringir a obtenção e a desencriptação

Remova concessões não previstas na sua origem real, incluindo permissões herdadas, e depois delegue a recuperação à população aprovada. Adicionar uma concessão restrita não revoga uma concessão ampla já existente. Repita a consulta de direitos após a revisão das ACLs e teste a recuperação aprovada sem colocar credenciais na saída geral da auditoria.

Para a encriptação nativa no AD, a referência de definições de política da Microsoft exige o nível funcional de domínio 2016 ou posterior. Reveja ADPasswordEncryptionEnabled e ADPasswordEncryptionPrincipal; este último identifica a entidade autorizada a desencriptar e tem de ser resolvido no dispositivo. Não trate os direitos de obtenção do diretório como equivalentes à autoridade de desencriptação.

3. Concluir a migração da versão legada

Siga o procedimento de migração da Microsoft para uma transição imediata ou uma coexistência temporária. Durante a coexistência, as duas implementações têm de gerir contas locais diferentes. Verifique a política nativa, os atributos nativos atualizados e a atividade bem-sucedida dos endpoints antes de remover o software legado. Reveja também o acesso ao material residual de palavras-passe legadas; uma implementação nativa bem-sucedida não comprova que todos os caminhos antigos de recuperação foram limpos.

4. Efetuar a rotação após exposição credível

Após conter o acesso não autorizado, coordene a rotação no endpoint afetado. A Microsoft documenta Reset-LapsPassword para situações excecionais que exigem uma alteração imediata, incluindo uma violação de segurança da máquina:

Reset-LapsPassword

Execute-o localmente no dispositivo gerido afetado, com os privilégios necessários. O cmdlet não devolve informações detalhadas sobre o resultado; verifique os eventos resultantes. Um pedido de reposição submetido não é prova suficiente de que a credencial exposta deixou de funcionar. Reveja as identidades e os endpoints afetados pelo incidente juntamente com a rotação, em vez de o encerrar apenas porque a ACL dos leitores mudou.

Como a EtcSec deteta este problema

O catálogo aceita estes quatro identificadores. As descrições seguintes refletem as implementações de Detect() revistas para este artigo, não uma afirmação de que foi executada uma auditoria contra o seu domínio:

• LAPS_DOMAIN_COVERAGE_LOW avalia a cobertura dos computadores ativados que não são DCs, contando a presença de LAPS legado ou nativo. Separa os valores de estações de trabalho e servidores e apresenta uma métrica ao nível do domínio. Na implementação de Detect() revista, uma cobertura inferior a 95% produz um resultado: High abaixo de 80%, caso contrário Medium abaixo de 95%. Estes são limiares de controlo da EtcSec, não recomendações da Microsoft. Fonte: etc-collector public/internal/audit/detectors/ad/advanced/laps/laps-domain-coverage.go, linhas 78–86, commit f51fad0b69c0c7fbda2fcc3c43bd6f6b4da4bee4, revisto em 3 de outubro de 2026. O controlo mede indícios de implementação, não a atualidade da rotação nem a qualidade da encriptação.
• LAPS_LEGACY_ATTRIBUTE identifica computadores com indícios de LAPS legado e sem indícios de Windows LAPS nativo. Não identifica a implementação cliente em execução nem demonstra uma leitura não autorizada.
• LAPS_PASSWORD_READABLE examina ACEs de concessão com CONTROL_ACCESS que visam o GUID de esquema de ms-Mcs-AdmPwd resolvido na floresta ativa. Exclui entidades reconhecidas como administradores incorporados e o SID do próprio computador. O seu âmbito é este sinal de permissão legada, não uma avaliação geral dos direitos de desencriptação de palavras-passe nativas encriptadas.
• LAPS_PASSWORD_LEAKED usa o mesmo sinal legado de ACEs de concessão CONTROL_ACCESS e sinaliza mais de uma entidade distinta com direitos de leitura num computador, após as mesmas exclusões de administradores incorporados e do SID próprio. Aqui, «non-admin» significa não reconhecido por esse filtro; o detetor não determina o papel administrativo efetivo de cada entidade. Sinaliza uma exposição potencial por permissões excessivas, não uma exfiltração observada, e não expande grupos para obter uma contagem de pessoas. Valide o acesso efetivo separadamente: este predicado conta concessões correspondentes, em vez de resolver ACEs de negação contra elas.

Use os resultados do etc-collector para priorizar a investigação e depois valide separadamente a cobertura, os direitos efetivos, a geração da política e a rotação dos endpoints. Um resultado de implementação pode estar resolvido enquanto persiste um problema de permissões. Encerre a revisão apenas quando tanto o inventário previsto como o caminho de recuperação aprovado corresponderem às provas.