Sites do AD: verificar sub-redes e seleção de DCs antes de alterações

Sites do AD: o que verificar nas sub-redes antes de alterar a topologia

A análise dos sites do AD e das sub-redes deve responder a uma pergunta prática: um cliente representativo identifica o site de Active Directory previsto e encontra um controlador de domínio adequado? Um site sem objetos de servidor recolhidos e um site sem objetos de sub-rede associados são pontos de partida úteis para uma investigação. Nenhum destes resultados, por si só, demonstra um ataque ou indica qual alteração de configuração se justifica.

Este guia foi confrontado com o Microsoft Learn e a implementação do etc-collector em 3 de outubro de 2026. Os comandos abaixo são exemplos documentados de inspeção e configuração; não foram executados num domínio de cliente. Use o inventário de rede, os resultados do diretório e as observações dos clientes para determinar a causa antes de alterar uma associação.

Uma filial pode deliberadamente não ter um DC local. Por outro lado, um site pode ter um objeto de sub-rede enquanto outras redes efetivamente usadas pelos clientes continuam por declarar. Mantenha estes casos separados: uma contagem de objetos do diretório não é um teste da cobertura da rede nem do sucesso da autenticação.

Como a associação a sites afeta a seleção de DCs e a replicação

A documentação de DC locator da Microsoft descreve a descoberta através do Netlogon, de anúncios DNS e de respostas LDAP UDP. Durante a negociação, um DC identifica o site do cliente a partir da sua sub-rede IP. Se o primeiro DC estiver fora do site adequado, a informação devolvida sobre o site do cliente pode desencadear outra pesquisa específica desse site. A descoberta também usa informação em cache; um único DC devolvido é uma observação desse pedido, não um histórico completo da autenticação da aplicação.

Uma sub-rede de cliente sem associação deixa a seleção do site incompleta e pode conduzir a um DC fora da localização prevista. Isso justifica investigar o endereço real do cliente e a associação, em vez de assumir que todos os clientes escolhem um DC aleatoriamente. Um DC remoto também pode ser o serviço previsto para uma filial sem DC local.

Os conceitos de replicação da Microsoft distinguem os objetos de sub-rede, que associam endereços de rede a sites, das ligações entre sites e dos objetos de ligação usados na replicação. O objeto de servidor de um DC tem um objeto filho NTDS Settings que representa o DC que replica. O KCC cria as ligações de replicação; as ligações entre sites descrevem caminhos lógicos de replicação e os respetivos custos.

Para esta análise, mantenha duas perguntas separadas. A descoberta pelo cliente pergunta que DC uma máquina consegue localizar a partir da sua rede atual. O desenho da replicação pergunta como os DCs trocam alterações do diretório. Uma associação correta entre cliente e site não comprova a saúde da replicação, e uma replicação bem-sucedida não comprova que todas as redes de clientes tenham a associação ao site previsto.

O guia de segurança das zonas DNS do AD aborda transferências, atualizações dinâmicas e permissões de registos. Estes controlos sobre os dados de resolução complementam a investigação, mas não definem a associação entre sub-redes e sites. Investigue o DNS quando a descoberta falha, mantendo separadas as evidências da topologia.

Deteção: conciliar o inventário do diretório com as observações dos clientes

1. Determinar o que as consultas ao diretório realmente devolveram

Use uma máquina de gestão com o módulo ActiveDirectory PowerShell e uma conta autorizada a ler os objetos de configuração relevantes. As referências da Microsoft documentam Get-ADReplicationSubnet e Get-ADReplicationSite. Os seguintes exemplos, apenas de leitura, solicitam os objetos e as suas propriedades:

Get-ADReplicationSubnet -Filter * -Properties *
Get-ADReplicationSite -Filter * -Properties *

Registe o servidor de diretório consultado, o contexto da conta, o sucesso da consulta e o momento da recolha juntamente com os resultados. Inspecione os nomes das sub-redes e as respetivas associações Site e compare o site associado com o distinguished name desse site. Não transforme um erro de acesso ou uma exportação incompleta numa conclusão de que os objetos não existem.

Concilie essa exportação com o inventário atual da equipa de rede: redes de filiais, redes de escritórios, intervalos de clientes VPN e outras redes a partir das quais os clientes do domínio realmente se ligam. Para cada intervalo relevante, identifique o site esperado e o responsável que o pode confirmar. Esta comparação é uma etapa de análise manual; as duas verificações do EtcSec descritas abaixo não a executam.

Comece com um pequeno conjunto representativo de clientes que inclua as redes associadas ao resultado da análise. Registe o endereço ativo e o contexto de ligação para cada observação. Um portátil testado num escritório e o mesmo portátil testado através de uma VPN constituem observações de rede diferentes. Preserve o site esperado e a razão dessa expectativa antes de comparar a saída dos comandos.

2. Observar a pertença ao site e o resultado de DC locator

A página de resolução de problemas de sincronização do diretório da Microsoft documenta estes comandos para verificar a pertença de um computador a um site e localizar um DC. Substitua o domínio de exemplo pelo seu domínio DNS real:

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Leia o resultado do site, o DC selecionado e os campos Our Site Name e DC Site Name, quando forem devolvidos. Preserve as falhas como falhas, incluindo o texto do erro. Um resultado de site indisponível exige investigação; não é prova de que o cliente pertence ao escritório geograficamente mais próximo.

Para uma comparação deliberada com uma nova descoberta, a referência de Nltest documenta /force como forma de evitar a informação de descoberta em cache:

nltest /dsgetdc:contoso.com /force

Mantenha ambos os resultados, em vez de substituir a primeira observação. Compare o site do cliente indicado com a associação esperada e o site do DC com o desenho documentado da filial. Se forem diferentes, investigue a associação, a descoberta e a exceção WAN prevista antes de editar qualquer configuração. Estes comandos exercitam a descoberta; valide separadamente o comportamento da aplicação afetada se uma queixa de autenticação desencadeou a análise.

3. Correlacionar as evidências de clientes sem associação

A Microsoft documenta o evento NETLOGON 5807 em Resposta atrasada do DC a pedidos LDAP ou Kerberos. O evento descreve ligações de endereços de clientes que não correspondem a sites existentes. Essa página identifica %SystemRoot%\debug\netlogon.log e o respetivo ficheiro .bak resultante da rotação como locais dos nomes e endereços de clientes, com NO_CLIENT_SITE: a identificar as entradas relevantes.

Quando este evento ou as entradas de log que o acompanham estiverem presentes, concilie os endereços observados com o inventário de rede e as sub-redes declaradas. Verifique qual ligação originou o endereço antes de o associar a um site. A ausência deste evento não substitui a comparação com o inventário, e a sua presença não identifica um atacante.

Correção: ajustar a associação ou documentar a exceção prevista (Remediation)

1. Resolver primeiro a incerteza do inventário

Antes de editar a topologia, concilie o instantâneo do collector com leituras bem-sucedidas do diretório. Se a enumeração de servidores ou sub-redes falhou, investigue o contexto de recolha e repita o inventário. Não implemente um DC, não elimine um site e não invente uma sub-rede apenas para eliminar uma ausência aparente produzida por uma consulta falhada.

Num site sem DC local, pergunte aos responsáveis pelo domínio e pela rede se isso é deliberado. Documente a localização do DC que presta o serviço, a dependência WAN esperada, o responsável e o motivo que deverá desencadear uma nova análise. Mantenha essa exceção com as observações dos clientes para que outro revisor compreenda por que a descoberta entre sites é aceitável nesse caso.

2. Corrigir uma associação ausente ou incorreta confirmada

Identifique a rede real dos clientes e o site existente que a deve representar. Analise a associação proposta com o responsável da rede, incluindo outras redes que possam ser afetadas. Uma definição de sub-rede deve expressar o desenho de rede acordado, não simplesmente copiar o endereço da primeira máquina que produziu um erro.

Para uma sub-rede realmente em falta, a Microsoft documenta este exemplo de criação em New-ADReplicationSubnet:

New-ADReplicationSubnet -Name "10.10.0.0/22" -Site Asia -Location "Tokyo,Japan"

Esta é a rede e o site usados como exemplo pela Microsoft, não uma proposta de configuração para o seu ambiente. Substitua-os por uma rede verificada e pelo site existente previsto apenas depois de confirmar que o objeto de sub-rede realmente está em falta. Para um objeto existente com associação incorreta, corrija a sua associação Site em Active Directory Sites and Services através do processo normal de alterações. Preserve os valores originais e a substituição aprovada no registo da alteração.

Se um servidor foi efetivamente desativado, siga as orientações separadas sobre higiene de objetos de DC e limpeza de metadados. Confirme a desativação antes da limpeza. Uma lista de servidores recolhida vazia não é prova de que um DC ativo deva ser removido, e adicionar ou remover objetos de servidor não substitui a correção da associação entre sub-redes de clientes e sites.

3. Voltar a verificar os clientes representativos e guardar as evidências

Repita o inventário do diretório e os comandos de descoberta pelos clientes depois de a alteração estar visível no servidor de diretório usado na validação. Teste as mesmas redes representativas, incluindo os casos previstos de serviço remoto. Registe o site esperado, o site observado, o DC devolvido e a exceção restante para cada cliente.

Volte a verificar o fluxo da aplicação que motivou a investigação e analise a replicação separadamente se a topologia foi alterada. Um resultado de inventário que deixou de ocorrer é uma confirmação útil dos objetos recolhidos, mas não comprova que todas as redes ou aplicações usam agora o caminho pretendido.

Como o EtcSec deteta este problema

A implementação do etc-collector no EtcSec avalia duas verificações da categoria Network sobre o inventário de sites e sub-redes recolhido:

• SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 percorre data.Sites e recolhe cada site em que len(site.Servers) == 0. Devolve um resultado cujo Count é o número desses sites, com os respetivos nomes em sitesWithoutDc. Quando a contagem é positiva, adiciona as entidades dos sites afetados. Também devolve o resultado quando a contagem é zero; não existe uma condição de latência medida neste ramo.
• SUBNET_MISSING — Info. subnet-missing.go:24 procura nas sub-redes recolhidas um Subnet.SiteDN que corresponda a cada Site.DistinguishedName usando strings.EqualFold. Um site sem qualquer correspondência contribui para Count e sitesWithoutSubnets; os detalhes também incluem as contagens totais de sites e sub-redes. As entidades dos sites afetados só são adicionadas quando IncludeDetails está ativado e a contagem é positiva. Uma única sub-rede associada satisfaz este predicado, mesmo que outras redes reais continuem sem associação.

O provider LDAP importa para a interpretação. Em client.go:1872, GetSitesAndSubnets pesquisa o contentor Servers de cada site com (objectClass=server). Embora o comentário mencione nTDSDSA, o código não verifica um objeto filho NTDS Settings nem testa a saúde do DC. Adiciona o dNSHostName de um servidor, recorrendo a name como alternativa, apenas quando existe um valor não vazio.

Uma falha na consulta dos sites devolve um erro. Uma falha na consulta de servidores de um site é ignorada e pode deixar Servers vazio. Uma falha na consulta das sub-redes devolve sites, nil, nil, sem erro. Estes dois últimos ramos podem simular uma ausência nos dados entregues aos detetores. Uma lista de sites ou sub-redes aparentemente vazia exige, portanto, evidências independentes de um inventário bem-sucedido.

Nenhuma das verificações analisa a cobertura CIDR, valida endereços IP de clientes, mede a latência, avalia custos de ligações entre sites ou ligações de replicação, ou testa a acessibilidade dos DCs. Nenhuma comprova que todos os servidores declarados são DCs saudáveis. Um site deliberadamente sem DC pode produzir o resultado Low, enquanto um site com uma sub-rede pode evitar a contagem Info apesar de existirem lacunas noutras redes.