Active Directory Domain Controller Higiene de Objetos de Computador Schema LAPS: Seis Lacunas que uma Auditoria ao Vivo Continua Encontrando

Active Directory Domain Controller Higiene de Objetos de Computador Schema LAPS: O Que Esta Auditoria Cobre

As verificações de Active Directory Domain Controller Higiene de Objetos de Computador Schema LAPS são o que uma auditoria ao vivo encontra primeiro, e nenhuma delas é dramática isoladamente: um schema do AD que nunca foi estendido para o LAPS, domain controllers posicionados fora de sua OU, e objetos de computador que ninguém observa há anos. Juntas, elas ficam por baixo dos caminhos de ataque mais conhecidos — Kerberoasting, DCSync, escalonamento via ADCS — e determinam silenciosamente se esses ataques sequer são necessários. Um domínio em que todo objeto de computador está atualizado, todo domain controller está onde deveria estar, e as senhas de administrador local são gerenciadas centralmente é um domínio em que um atacante precisa se esforçar para conseguir um ponto de apoio. Um domínio em que nada disso é verdade oferece atalhos de graça.

Este artigo cobre seis lacunas que uma auditoria ao vivo contra um ambiente AD real encontra consistentemente juntas, nenhuma das quais aparece em uma lista típica de "top 10 configurações incorretas" porque nenhuma delas é uma única vulnerabilidade dramática:

1. A extensão do schema do Active Directory para o LAPS nunca foi aplicada — não é o caso de "o LAPS está implantado, mas não em todos os lugares"; os próprios atributos do schema não existem.
2. Domain controllers cujo objeto de computador está fora da OU Domain Controllers.
3. Objetos de domain controller que pararam de replicar e nunca foram limpos.
4. Objetos de computador obsoletos e inativos, sem nenhum responsável observando-os.
5. Computadores sem BitLocker, incluindo domain controllers que armazenam o NTDS.dit.
6. Contas de computador cuja senha de máquina parou de rotacionar.

Cada uma delas é pouco dramática isoladamente. Juntas, descrevem um ambiente em que o ciclo de vida dos objetos não é responsabilidade de ninguém — e é exatamente essa a condição da qual os atacantes dependem quando os controles mais chamativos, como os cobertos em Endurecimento Active Directory: o que bloquear primeiro e como validar, já estão travados.

Por Que um Schema LAPS Não Estendido É a Lacuna Mais Profunda

O Local Administrator Password Solution existe em duas gerações, e a distinção importa aqui. O LAPS legado da Microsoft armazenava a senha gerenciada no atributo ms-Mcs-AdmPwd, adicionado ao schema executando Update-AdmPwdADSchema como um Schema Admin — veja a própria referência de atributos da Microsoft em MS-ADA2. Desde a atualização cumulativa de abril de 2023, o Windows LAPS é entregue como um componente nativo do sistema operacional e usa um conjunto diferente de atributos criptografados (msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-PasswordExpirationTime) — veja a referência técnica do Windows LAPS. Qualquer uma das gerações exige sua própria extensão de schema (Update-LapsADSchema para os novos atributos), executada uma única vez, em todo o domínio, por alguém do grupo Schema Admins.

Essa etapa é fácil de pular porque pulá-la não gera nenhum erro. As GPOs podem ser vinculadas, o CSE do LAPS pode ser distribuído para todos os endpoints, e nada acontece — não existe atributo algum para escrever a senha. Essa é uma lacuna diferente e mais fundamental do que "o LAPS está configurado, mas alguns computadores estão fora do escopo", que é a lacuna Windows LAPS não implantado que já cobrimos separadamente. Aqui, o schema em si nunca foi tocado, o que significa que toda senha de administrador local no domínio está sem gerenciamento — normalmente compartilhada de forma idêntica em toda uma imagem de build, segundo a análise de implantação do LAPS do ADSecurity.org. Uma única credencial de administrador local baseada em imagem, uma vez quebrada ou extraída de uma única estação de trabalho de baixo valor, libera movimento lateral para todas as máquinas construídas a partir dessa imagem.

DCs Fora de Sua OU e Metadados que Ninguém Limpou

DC_NOT_IN_DC_OU parece cosmético até você verificar o que a Microsoft realmente vincula à OU padrão Domain Controllers: a GPO Default Domain Controllers Policy, que define atribuições de direitos de usuário específicas de DC, política de auditoria e opções de segurança — a mesma cadeia de herança de GPO que exploramos em Má Configurações de GPO: Quando a Group Policy Se Torna um Vetor de Ataque. Mover o objeto de computador de um domain controller para outra OU — mesmo uma sub-OU criada por organização — quebra essa cadeia de herança, e a Microsoft documenta isso há anos como uma configuração não suportada, não como uma preferência de estilo; veja a análise da Computerworld sobre esse erro e o guia de segurança de domain controllers da Semperis. Um DC que silenciosamente perdeu sua política de auditoria de linha de base é um DC gerando logs de segurança incompletos — que é exatamente o tipo de ponto cego do qual uma técnica de registro de DC fraudulento como o DCShadow depende; cobrimos esse abuso específico em Ataque DCShadow Controlador de Domínio Fraudulento: Registro que Contorna a Auditoria do AD.

DC_INACTIVE é o problema irmão: um objeto de computador de DC que parou de replicar e nunca foi formalmente desativado. A orientação da Microsoft é explícita: um DC removido por falha de hardware ou por uma demoção forçada malsucedida deixa metadados órfãos de diretório e DNS — objetos de computador e de NTDS Settings, conexões de replicação, registros SRV/CNAME — que precisam ser removidos deliberadamente por meio de uma limpeza de metadados, e não deixados no lugar; veja Limpar metadados de servidor de domain controller do Active Directory. Se deixada de lado, essa identidade de DC obsoleta produz resultados inconsistentes de localização de DC e dá a um atacante um objeto plausível e raramente auditado para se passar por ele ou reaproveitá-lo. O posicionamento de objetos e a saúde da replicação são a metade "higiene" da segurança de domain controllers; a metade de serviços de rede — força de cifra do LDAPS, um Print Spooler exposto, desvio de relógio além da tolerância do Kerberos — é uma checklist distinta que publicamos em Domain Controller LDAPS TLS Fraco, Print Spooler, Sincronização Horário Audit.

Computadores Obsoletos, BitLocker Ausente e Senhas de Máquina que Ninguém Rotaciona

COMPUTER_STALE_INACTIVE é o equivalente, em objetos de computador, de uma conta de usuário obsoleta: uma máquina que não se autentica há meses, mas continua sendo um principal Kerberos totalmente válido, com SID, associações de grupo e — se alguém já concedeu a ela direitos de delegação ou acesso de escrita a algo sensível — uma superfície de ataque que ninguém observa. Os riscos distintos e mais profundos que existem sobre um objeto de computador quando um atacante o controla (delegação irrestrita, abuso de RBCD, direitos capazes de DCSync) são cobertos separadamente em Superfície de Ataque dos Objetos de Computador do Active Directory; esta lacuna trata da simples existência desses objetos, nunca revisados.

COMPUTER_NO_BITLOCKER importa mais nas máquinas que armazenam os dados em repouso mais valiosos. Em um domain controller, especificamente, isso é o NTDS.dit — o banco de dados que contém o hash de senha de cada conta. A própria orientação de hardening de domain controllers da Microsoft recomenda BitLocker apoiado em TPM em todos os volumes de DC precisamente porque isso protege o diretório mesmo que um disco físico seja removido do servidor (veja a referência Securing Domain Controllers Against Attack). Quando o BitLocker é habilitado com custódia de chaves baseada em AD, a senha de recuperação é registrada como um objeto filho msFVE-RecoveryInformation sob o objeto de computador — veja Storing BitLocker Recovery Keys in Active Directory —, portanto sua ausência é diretamente consultável, e não algo que você precisa confiar em uma planilha para saber.

COMPUTER_PASSWORD_OLD rastreia um sinal mais sutil. Por padrão, "Membro do domínio: idade máxima da senha da conta de computador" é 30 dias — espera-se que todo computador ingressado no domínio rotacione sua própria senha de máquina nesse ritmo, uma configuração documentada na referência de políticas de segurança da Microsoft e explicada em profundidade no passo a passo sobre senhas de contas de máquina do ADSecurity.org. Uma conta de máquina com uma senha muito mais antiga que 30 dias e que ainda está efetuando login ativamente geralmente indica um canal seguro quebrado, não um ambiente mais robusto — e uma senha de máquina estática dá a um atacante que comprometeu a conta muito mais tempo para atacá-la por força bruta ou repeti-la antes que a rotação force uma redefinição.

Detecção

# 1. Confirmar se a extensão do schema LAPS existe (qualquer uma das gerações)
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-Mcs-AdmPwd" -or name -eq "msLAPS-Password"}

# 2. Domain controllers cujo objeto de computador está fora da OU padrão de DC
Get-ADDomainController -Filter * | ForEach-Object {
    $dn = (Get-ADComputer $_.Name).DistinguishedName
    if ($dn -notmatch "OU=Domain Controllers") { "$($_.Name) -> $dn" }
}

# 3. Objetos de computador obsoletos — sem autenticação há mais de 90 dias
Get-ADComputer -Filter * -Properties lastLogonTimestamp |
    Where-Object { [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt (Get-Date).AddDays(-90) } |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}

# 4. Computadores sem informações de recuperação do BitLocker em custódia no AD
Get-ADComputer -Filter * | ForEach-Object {
    $recovery = Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} -SearchBase $_.DistinguishedName
    if (-not $recovery) { $_.Name }
}

# 5. Senha de conta de máquina mais antiga que a política de 30 dias
Get-ADComputer -Filter * -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } |
    Select-Object Name, PasswordLastSet

Remediação

1. Estender o Schema do LAPS, uma Única Vez, em Todo o Domínio

Execute o Update-LapsADSchema (Windows LAPS) — ou o Update-AdmPwdADSchema, se a organização deliberadamente permanecer no LAPS legado — como membro de Schema Admins, e depois delegue a permissão de escrita SELF nos novos atributos com Set-LapsADComputerSelfPermission antes de distribuir a GPO.

2. Mover Objetos de DC Mal Posicionados de Volta para Domain Controllers

Use o Move-ADObject ou o ADUC para realocar o objeto de computador, e depois confirme que a Default Domain Controllers Policy volta a se aplicar com gpresult /r no DC afetado.

3. Resolver ou Aposentar DCs Inativos Deliberadamente

Se o repadmin /showrepl mostrar uma falha de replicação real, corrija-a. Se o DC realmente não existir mais, execute uma limpeza de metadados adequada em vez de deixar o objeto órfão e os registros DNS no lugar.

4. Desativar e Depois Excluir Computadores Obsoletos em um Cronograma Fixo

Por exemplo, desative após 90 dias de inatividade e exclua após 180 — a mesma disciplina já aplicada a contas de usuário obsoletas.

5. Habilitar o BitLocker com TPM e Custódia de Chaves no AD

Priorize primeiro os domain controllers, por meio da configuração de GPO "Armazenar informações de recuperação do BitLocker no Active Directory Domain Services", para que o msFVE-RecoveryInformation seja preenchido e se torne auditável.

6. Deixar a Política de 30 Dias para a Idade da Senha de Máquina como Está

Investigue, em vez de ignorar, qualquer máquina ativa cujo PasswordLastSet tenha se desviado bem além disso — geralmente o Test-ComputerSecureChannel -Repair corrige um canal seguro quebrado que está bloqueando silenciosamente a rotação.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec verifica diretamente essas seis condições no domínio: COMPUTER_NO_LAPS para uma extensão de schema ausente, DC_NOT_IN_DC_OU e DC_INACTIVE para o posicionamento e a saúde de replicação dos domain controllers, COMPUTER_STALE_INACTIVE para máquinas inativas nunca revisadas, COMPUTER_NO_BITLOCKER para criptografia de disco sem custódia, e COMPUTER_PASSWORD_OLD para rotação estagnada de senhas de máquina.