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ário | Evidência a comparar | Conclusão a evitar |
|---|---|---|
| Nome e domínio do DC | Enumeração independente bem-sucedida para o domínio indicado | Uma lista recolhida abrange todos os domínios da floresta |
| Funções FSMO | Propriedades de funções por DC, juntamente com os titulares das funções do domínio e da floresta | Um campo vazio prova que uma função não tem titular |
| Indicador RODC | Propriedades independentes do DC e estado da recolha | Um valor predefinido é uma avaliação verificada de DC gravável |
| Site | Propriedades do DC no diretório e mapeamento de site previsto | Um nome de site demonstra replicação bem-sucedida |
| Parceiros de replicação | Evidência de configuração, com uma leitura separada do estado de replicação | Uma 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
