Metadados do descritor de seguranca do esquema AD: avaliar uma alteração recente

O que revelam os metadados do descritor de seguranca do esquema AD

Os metadados do descritor de seguranca do esquema AD ajudam a qualificar quando o descritor de segurança da raiz do contexto de nomenclatura do esquema foi alterado pela última vez. Um carimbo de data e hora recente é motivo para coletar evidências e revisar a alteração. Ele não demonstra que uma permissão se tornou perigosa, que um administrador agiu sem autorização ou que a floresta foi comprometida.

Este guia examina nTSecurityDescriptor no objeto exato retornado como schemaNamingContext. Ele não examina defaultSecurityDescriptor nas classes individuais do esquema. Mantenha essa distinção no registro da investigação: uma alteração no descritor do objeto raiz e uma alteração no descritor padrão de uma classe são alvos de revisão diferentes.

A Microsoft descreve msDS-ReplAttributeMetaData como metadados mantidos pelo sistema para atributos replicados. Trate essas informações como proveniência da replicação. O servidor de diretório de origem não é a conta de usuário ou de serviço que solicitou uma gravação. Identificar a conta solicitante exige evidências separadas.

O resultado prático é uma ficha de qualificação: qual objeto foi consultado, qual controlador de domínio respondeu, quais metadados foram retornados, se o carimbo de data e hora é utilizável e se uma referência aprovada explica as permissões atuais. Este é um fluxo de investigação, revisado com base na documentação da Microsoft em 4 de outubro de 2026; nenhum dos comandos apresentados aqui foi executado em um diretório de cliente.

Detecção: identificar o objeto antes de consultar os metadados

Etapa 1: resolver o contexto de nomenclatura do esquema no DC escolhido

Use uma estação administrativa Windows com o módulo PowerShell ActiveDirectory e uma conta autorizada a ler os dados de diretório relevantes. Substitua o servidor de exemplo por um DC específico da sua floresta. Mantenha o mesmo servidor para a descoberta e a primeira consulta de metadados.

O exemplo a seguir usa o parâmetro documentado -Server de Get-ADRootDSE. Sua saída inclui schemaNamingContext, defaultNamingContext, o nome de host do servidor e a hora atual.

$dc = 'dc01.example.com'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$root | Format-List dnsHostName, defaultNamingContext, schemaNamingContext, currentTime
$schemaDN = [string]$root.schemaNamingContext
if ([string]::IsNullOrWhiteSpace($schemaDN)) {
    throw 'Schema naming context was not returned; stop qualification.'
}

Registre exatamente o DN retornado. Compare-o com o DN do objeto usado pela sua ferramenta de auditoria. No contexto de um domínio filho, verifique especificamente se um DN montado a partir do DN do domínio atual corresponde ao RootDSE. Uma divergência é uma questão de coleta a resolver antes de interpretar o resultado; ela não é evidência de que o descritor foi alterado.

Etapa 2: obter os metadados de replicação do atributo

Get-ADReplicationAttributeMetadata aceita um nome distinto por -Object, um DC por -Server e nomes de atributos por -Properties. Este exemplo restringe a solicitação a nTSecurityDescriptor e exibe todos os metadados retornados, em vez de ocultar campos em uma tabela curta.

$metadata = @(Get-ADReplicationAttributeMetadata -Object $schemaDN -Server $dc -Properties nTSecurityDescriptor -ErrorAction Stop)
if ($metadata.Count -eq 0) {
    throw 'No metadata was returned; record insufficient evidence.'
}
$metadata | Format-List *

Preserve a saída, incluindo o nome do atributo, a versão, a hora da última alteração de origem e a identidade do servidor de diretório de origem. Distinga o DC consultado do servidor identificado como origem da alteração. Mantenha qualquer identidade não resolvida conforme retornada; não a substitua por um nome de administrador presumido.

Etapa 3: qualificar o carimbo de data e hora e a janela de observação

Registre a hora da coleta e o fuso horário junto ao carimbo de data e hora bruto. Confirme que a data está presente e foi interpretada corretamente antes de aplicar uma janela. Use a hora de referência registrada pela auditoria ao reproduzir sua decisão, em vez de substituí-la silenciosamente pela hora de hoje durante uma investigação posterior.

Se repetir a consulta em outro DC, repita também a descoberta por RootDSE nesse servidor e salve um registro de coleta separado. Não una duas observações em um histórico inventado. Um carimbo de data e hora da última alteração não pode reconstruir cada estado anterior do descritor nem cada modificação no período de revisão.

Correção: qualificar primeiro, corrigir desvios confirmados (Remediation)

Etapa 1: comparar o descritor atual com uma referência aprovada

Obtenha o descritor atual da raiz exata do esquema e compare-o com uma referência datada e aprovada para esse mesmo objeto. Para visualizar as permissões no DC escolhido, o exemplo a seguir usa a sintaxe de objeto remoto documentada pela Microsoft para Dsacls. Execute o comando em um shell Windows elevado, com Dsacls instalado e acesso de leitura ao objeto de destino. Sem opções de modificação, ele exibe a ACL.

dsacls "\\$dc\$schemaDN"

Preserve a saída do comando e relate qualquer falha. A exibição da ACL auxilia a revisão de permissões; mantenha uma exportação completa do descritor pelas ferramentas de diretório aprovadas se a investigação também precisar de informações de proprietário, grupo ou auditoria. Identifique exatamente quais componentes foram capturados para que uma visão parcial não seja apresentada como uma comparação completa de descritores.

Revise os titulares de direitos alterados, os direitos, os GUIDs específicos de objeto, a herança e o escopo. Determine se cada diferença pertence à própria raiz ou a outro objeto. A revisão existente das permissões do esquema fornece contexto relacionado às permissões; esta verificação temporal não demonstra uma alteração no defaultSecurityDescriptor de uma classe.

Se não houver referência aprovada, registre essa limitação. O descritor atual ainda pode ser revisado em relação à delegação pretendida pela organização, mas uma comparação histórica exata permanece indisponível. Não fabrique um estado anterior a partir do carimbo de data e hora nem trate um padrão genérico como a referência aprovada da sua floresta.

Etapa 2: correlacionar a autorização e os eventos disponíveis

Compare as evidências com um ticket real de alteração: DN de destino, permissões esperadas, equipe responsável, janela de execução aprovada e estado resultante. Um ticket que menciona uma implantação relacionada ao esquema não é suficiente por si só; verifique se a alteração pretendida explica o objeto observado e a diferença no descritor.

A Microsoft documenta o evento de segurança 5136 para modificações de objetos de diretório sob Audit Directory Service Changes. Sua geração exige uma entrada apropriada de auditoria de gravação de atributo na SACL do objeto. Quando houver eventos, verifique ObjectDN e AttributeLDAPDisplayName, preserve os campos da conta em Subject e correlacione as operações correspondentes usando OpCorrelationID. A Microsoft descreve registros típicos de Value Deleted e Value Added, mas verifique os valores efetivamente disponíveis nas suas evidências.

Use o guia de monitoramento AD para coleta e correlação de eventos para revisar a cadeia de monitoramento envolvida. Determine se a auditoria, o encaminhamento e a retenção cobriam o DC e o período relevantes antes de interpretar uma busca vazia. Uma conta em Subject identifica um principal solicitante no evento; qualquer atribuição a uma pessoa específica ainda exige registros operacionais de apoio.

Etapa 3: escolher uma classificação defensável

Um carimbo de data e hora inexplicado, por si só, pertence ao terceiro ramo. Um desvio confirmado de permissões pode justificar uma correção sem estabelecer quem o causou. Mantenha explícitas a questão da autorização e a avaliação da exposição atual, para que a resposta não dependa de uma atribuição sem respaldo.

Etapa 4: corrigir apenas o desvio confirmado do descritor

Solicite que a equipe de diretório autorizada prepare uma alteração no DN verificado da raiz do esquema. Salve o descritor atual, identifique a ACE exata ou o componente do descritor a corrigir, documente o resultado pretendido e organize um caminho de recuperação antes de gravar. Aplique a alteração revisada pelo editor de ACL aprovado, preservando a delegação legítima e as permissões necessárias.

Evite usar uma redefinição indiscriminada para justificar um carimbo de data e hora recente. A referência Dsacls da Microsoft descreve /S como a restauração dos padrões de classe e /R como a remoção de todas as ACEs de um principal especificado; nenhuma dessas opções substitui uma correção direcionada respaldada pela comparação aprovada.

Após a correção, repita as leituras de RootDSE, metadados e permissões. Verifique se o estado pretendido do descritor está presente e se as operações de diretório necessárias continuam funcionando. Registre os novos metadados e quaisquer evidências de auditoria coletadas como uma nova alteração autorizada. Um resultado de alteração recente pode permanecer positivo após uma correção legítima porque a própria correção é recente; valide as permissões, e não apenas o desaparecimento do sinal temporal.

Como a EtcSec detecta isso

Na implementação revisada do etc-collector, SCHEMA_SD_RECENT_CHANGE produz um resultado Info com Count 1 quando SchemaSDLastChanged é diferente de zero e estritamente posterior a data.Now.AddDate(0, 0, -90). O limite usa a subtração de dias do calendário. O instante exato do limite é excluído e não há limite superior em Now: uma data futura também satisfaz o teste. Caso contrário, o resultado retornado tem Count 0.

O mecanismo constrói CN=Schema,CN=Configuration, seguido de DomainInfo.DomainDN, solicita os metadados de replicação e copia a hora da alteração de nTSecurityDescriptor. Compare esse DN construído com o schemaNamingContext real de RootDSE, especialmente quando o contexto da auditoria for um domínio filho. Esta revisão do código estabelece um requisito de validação, e não uma falha medida na sua floresta.

O provedor LDAP pesquisa a subárvore com resultados limitados a uma entrada e lê msDS-ReplAttributeMetaData. Respostas ausentes, erros de solicitação, tags XML ausentes ou carimbos de data e hora não interpretados podem deixar a data em zero. O interpretador de carimbos de data e hora aceita YYYY-MM-DDTHH:MM:SSZ e YYYY-MM-DDTHH:MM:SS. Este caminho não tem um estado probed separado que comprove o sucesso da coleta.

O detector não compara um descritor antigo com um novo, não calcula uma diferença de DACL, não identifica uma conta solicitante nem demonstra abuso. Use seu resultado Info para iniciar a qualificação. Count 1 sustenta o predicado temporal implementado; Count 0 não pode certificar um esquema inalterado nem uma coleta bem-sucedida.