🏢Active DirectoryComputers

Inventario de controladores de dominio AD: reconciliar FSMO

Reconcilie identidades de DCs e titulares FSMO com leituras independentes do diretório. Qualifique metadados vazios e verifique a replicação separadamente.

Younes AZABARPor Younes AZABAR11 min de leitura
Inventario de controladores de dominio AD: reconciliar FSMO

O que um inventário de controladores de domínio AD estabelece

Um inventário de controladores de domínio AD deve identificar os DCs no âmbito analisado e explicar a origem de cada entrada. Nomes, sistemas operativos, sites, indicadores de só de leitura, funções FSMO e parceiros de replicação configurados ajudam o operador a compreender o diretório. Por si só, não provam que um DC esteja acessível, que todos os DCs esperados tenham sido recolhidos ou que as alterações do diretório estejam a ser replicadas com sucesso.

A revisão prática consiste em reconciliar a captura do coletor com leituras independentes do diretório, preservando o domínio, o servidor consultado, os contextos de nomenclatura e os erros de recolha. Uma lista FSMO vazia deve continuar a distinguir-se de uma leitura bem-sucedida que mostre que esse DC não detém nenhuma função. Da mesma forma, um parceiro configurado é informação sobre a topologia, não um resultado de replicação bem-sucedida.

Este guia foi verificado com base no Microsoft Learn e no código-fonte do etc-collector em 4 de outubro de 2026. Os comandos são exemplos documentados de inspeção só de leitura ou adaptações de sintaxe documentada. Não foram executados num diretório de cliente. O fluxo abaixo é uma proposta de revisão de evidências, não um relato de um incidente observado.

Como o âmbito e os metadados opcionais afetam o resultado

Comece pelo registo de recolha, em vez de se limitar à apresentação dos dados. Identifique o domínio solicitado, o endpoint LDAP, a BaseDN, o contexto da conta, a hora de recolha e as exclusões. Preserve os contextos de nomenclatura efetivamente envolvidos nas leituras, incluindo o contexto de configuração usado para enriquecimento. Uma designação de domínio sem o servidor e o contexto de pesquisa é insuficiente para explicar diferenças entre duas exportações.

No coletor inspecionado, os DCs são derivados dos objetos de computador recolhidos após as exclusões. O fornecedor de metadados enriquece essa lista recebida. Assim, um parceiro que não possa ser associado à lista de DCs recebida pode ser omitido do campo de parceiros resultante. Um array vazio pode, portanto, representar um mapeamento incompleto, em vez da ausência de objetos de ligação.

O fornecedor também constrói a sua base de pesquisa de configuração acrescentando o prefixo CN=Configuration, à BaseDN. Ao rever uma recolha num domínio subordinado, compare esse contexto construído com o contexto real de configuração da floresta usado na sua inspeção independente do diretório. A possível divergência de âmbito é uma inferência estática a partir do código, não uma falha reproduzida numa floresta de cliente. Preserve o contexto e o resultado da pesquisa antes de decidir se explicam um campo em falta.

Um registo de revisão útil associa cada identificador de DC à sua origem e a um estado de leitura explícito. Os estados sugeridos são lido com sucesso, não recolhido, leitura falhada e ainda não verificado. São designações do fluxo de trabalho, não valores emitidos pelo detetor. Não converta silenciosamente nenhum destes últimos estados numa lista vazia ou num indicador false.

Campo do inventárioEvidência a compararConclusão a evitar
Nome e domínio do DCEnumeração independente bem-sucedida para o domínio indicadoUma lista recolhida abrange todos os domínios da floresta
Funções FSMOPropriedades de funções por DC, juntamente com os titulares das funções do domínio e da florestaUm campo vazio prova que uma função não tem titular
Indicador RODCPropriedades independentes do DC e estado da recolhaUm valor predefinido é uma avaliação verificada de DC gravável
SitePropriedades do DC no diretório e mapeamento de site previstoUm nome de site demonstra replicação bem-sucedida
Parceiros de replicaçãoEvidência de configuração, com uma leitura separada do estado de replicaçãoUma ligação configurada prova sucesso atual da replicação

Deteção: reconciliar DCs e titulares FSMO de forma independente

1. Enumerar o domínio pretendido

Use um host de gestão com o módulo PowerShell ActiveDirectory e uma conta autorizada a ler os dados relevantes do diretório. A referência de Get-ADDomainController da Microsoft documenta o conjunto de parâmetros Filter e -Server. A adaptação seguinte solicita DCs a um servidor de diretório explicitamente identificado; substitua o hostname ilustrativo pelo servidor verificado do seu domínio:

Get-ADDomainController -Filter * -Server "dc01.contoso.com"

Registe o servidor que efetivamente consultou, juntamente com os objetos devolvidos e os erros. Compare os identificadores e a pertença ao domínio com as entradas do coletor antes de examinar diferenças no enriquecimento. Preserve os objetos em falta em qualquer das exportações como divergências a investigar, incluindo qualquer exclusão conhecida que explique uma diferença.

A referência distingue a obtenção por Filter ou Identity da descoberta. Uma chamada de descoberta encontra um DC que cumpre os seus critérios; não enumera todos os DCs. Numa revisão de toda a floresta, mantenha resultados separados por domínio. A referência de Get-ADForest inclui a enumeração através da coleção Domains da floresta. Não classifique uma exportação bem-sucedida de um único domínio como cobertura completa da floresta.

2. Ler as funções por DC e cruzar a titularidade do domínio e da floresta

A página de gestão de FSMO da Microsoft apresenta este exemplo exato de inspeção do domínio atual:

$domainControllers = Get-ADDomainController -Filter *
foreach ($dc in $domainControllers) {
    Write-Output "Name: $($dc.Name)"
    Write-Output "OperationMasterRoles:"
    foreach ($role in $dc.OperationMasterRoles) {
        Write-Output "- $role"
    }
}

Como esse exemplo usa o contexto de ligação predefinido, registe-o explicitamente. Prefira a enumeração anterior, limitada a um servidor, ao preparar uma comparação controlada. Preserve os objetos DC completos devolvidos, além do resumo das funções, para que uma opção de formatação não possa ocultar a identidade da origem.

A documentação de Get-ADDomain expõe PDCEmulator, RIDMaster e InfrastructureMaster. A saída de Get-ADForest expõe SchemaMaster e DomainNamingMaster. Estas adaptações só de leitura usam os parâmetros Identity e Server documentados:

Get-ADDomain -Identity "contoso.com" -Server "dc01.contoso.com"
Get-ADForest -Identity "contoso.com" -Server "dc01.contoso.com"

Substitua o domínio e a floresta pretendidos de forma independente; não têm necessariamente o mesmo nome DNS. Guarde a saída completa, incluindo a identidade do domínio e a pertença à floresta devolvidas. Compare cada titular com as propriedades de funções por DC e com os metadados do coletor. Um titular de função da floresta fora de uma recolha num domínio subordinado é uma questão de âmbito, não uma evidência de função em falta.

3. Preservar divergências e dados não lidos

Para cada divergência, anexe ambas as saídas, as respetivas horas de recolha, as identidades dos servidores e os resultados das leituras. Uma leitura independente bem-sucedida que identifique outro titular pode explicar por que razão um DC não detém nenhuma função. Uma leitura falhada não pode fazê-lo. Se as leituras limitadas a servidores divergirem, preserve ambas, em vez de escolher a que faz o inventário parecer completo.

Atribua a um responsável a investigação do contexto de recolha e de qualquer inconsistência do diretório. A questão imediata a esclarecer com evidências é se o valor em falta reflete o âmbito, uma exclusão, metadados não lidos ou um estado verificado do diretório. Essa questão deve ser respondida antes de planear uma alteração ao AD.

Correção: corrigir as evidências antes de alterar o diretório (Remediation)

1. Resolver lacunas de recolha e repetir a comparação

Reveja com o responsável pelo diretório o endpoint registado, a BaseDN do domínio, o contexto de configuração, as exclusões e as permissões. Corrija um problema confirmado de contexto de recolha através do processo de configuração suportado pelo coletor. Preserve em conjunto a captura original, o motivo da correção e os novos resultados de leitura.

Repita a enumeração de DCs no âmbito definido e os comandos de inspeção do domínio/floresta apresentados acima. Compare novamente os mesmos identificadores e propriedades de funções. Se os metadados continuarem por ler, mantenha esse estado visível e atribua a investigação ainda não resolvida; preencher manualmente o campo do relatório destruiria a distinção entre uma leitura do diretório e uma suposição do operador.

Um registo de aceitação deve indicar que domínio foi reconciliado, que DCs continuam sem explicação, que titulares de funções foram lidos de forma independente e que campos permanecem desconhecidos. Trate um DC excluído como excluído, em vez de o declarar ausente do diretório. Repetir uma recolha com sucesso é uma evidência útil, mas não alarga o seu âmbito para além dos domínios e contextos efetivamente consultados.

2. Verificar a replicação como controlo distinto

O guia de resolução de problemas de replicação da Microsoft documenta este comando exato, executado numa Linha de Comandos com privilégios elevados:

repadmin /showrepl * /csv > showrepl.csv

O procedimento documentado exige pertença a Enterprise Admins ou permissões equivalentes. Siga o processo de diagnóstico autorizado pela organização. Preserve o CSV e os erros do comando. Reveja os parceiros de origem, os contextos de nomenclatura, a informação sobre o último sucesso e as falhas separadamente da lista de parceiros configurados no inventário.

O mesmo guia identifica o registo de eventos Directory Service e a saída de Repadmin como evidências para resolução de problemas. Use o texto real do erro para investigar um resultado de diagnóstico falhado. Uma ligação indicada num inventário não responde a essas questões sobre o estado da replicação, e um alvo de diagnóstico inacessível continua por resolver, mesmo que outros DCs tenham devolvido resultados.

Registe o âmbito e o resultado da verificação de replicação num registo de evidências próprio. Não substitua o campo de parceiros configurados por um veredito sobre o estado da replicação nem classifique todas as ligações como saudáveis porque uma consulta teve sucesso. Este artigo sobre inventário não prescreve alterações de topologia nem operações de recuperação a partir de uma lacuna de metadados.

3. Ligar o inventário qualificado ao planeamento de topologia e recuperação

Use a informação de site verificada juntamente com a seleção de DC pelos clientes e o mapeamento de sub-redes para sites. Essa revisão reconcilia a topologia do diretório com as redes reais dos clientes e as observações de descoberta. Um nome de site inventariado, por si só, não prova uma seleção adequada pelos clientes nem um estado saudável de replicação.

Forneça o registo reconciliado de DCs e titulares de funções como entrada para o planeamento de recuperação da floresta e a validação de backups. A preparação da recuperação exige DCs e funções conhecidos, mas também seleção de backups, evidências de restauro e um manual operacional específico do ambiente. Uma exportação de inventário não valida um restauro nem estabelece que o estado recuperado do diretório seja fiável.

Como o EtcSec deteta isto

O etc-collector do EtcSec emite INFO_DOMAIN_CONTROLLER como constatação de inventário. A implementação inspecionada de dc-inventory.go produz uma constatação Info com Count 1 por DC recolhido. Não devolve constatações quando a lista de DCs recebida está vazia. Esse comportamento não é um veredito de vulnerabilidade e não prova que um diretório sem entradas devolvidas não tenha DCs.

As entidades afetadas detalhadas só são anexadas com IncludeDetails. Contêm os campos básicos de identidade do computador e sistema operativo, com funções FSMO, estado RODC, site e parceiros de replicação opcionais. O enriquecimento em falta deixa arrays vazios ou valores predefinidos. Quem consome os dados deve qualificar esses valores antes de os tratar como observações negativas bem-sucedidas.

O GetDCMetadata do fornecedor LDAP lê os objetos de titulares de funções e a configuração NTDS/de ligações. Erros de pesquisa FSMO ou resultados vazios são ignorados. Um erro de pesquisa NTDS deixa os campos de site e parceiros por preencher, enquanto o indicador RODC e quaisquer funções já lidas continuam disponíveis; os erros de pesquisa de ligações são ignorados. Os identificadores dos parceiros são mapeados para a lista de DCs recebida. O motor também só atribui DCInfo quando a chamada de metadados tem sucesso.

Estes são limites observados no código-fonte no commit afca1b9f7bba6f076d6a6493371486071001452b, não falhas reproduzidas em clientes. A verificação não testa o estado da replicação, não mede qualquer troca bem-sucedida de alterações e não decide se o ambiente está preparado para recuperação. Use-a para revelar os ativos DC recolhidos e depois qualifique a cobertura e os metadados opcionais com as leituras independentes descritas acima.

Explore as paginas de identidade que sustentam este tema