O controlador de domínio pensa que está em uma rede pública

Temos um controlador de domínio primário do Server 2008 R2 que parece ter amnésia quando se trata de descobrir em que tipo de rede ele está. A (apenas) conexão de rede é identificada na inicialização como uma 'Rede pública'.

No entanto, se eu desabilitar e reativar a conexão, ele ficará feliz em descobrir que na verdade faz parte de uma rede de domínio.

Isso ocorre porque os Serviços de Domínio AD não são iniciados quando o local da rede é inicialmente calculado?

Esse problema causa algumas dores de cabeça com as Regras do Firewall do Windows (que eu sei que podem ser resolvidas de outras maneiras), por isso estou curioso para saber se alguém sabe por que isso acontece.

Você tem um gateway padrão nessa conexão? Ele responde a solicitações de ping?

O Windows usa gateways para identificar redes; se ele não tiver um gateway configurado ou se não conseguir fazer o ping com êxito, não poderá identificar a rede à qual está conectado e presumirá que é público.

Se a rede de um controlador de domínio é classificada como rede de domínio não depende da configuração do gateway.

O comportamento de uma classificação de rede falsa pode ser causado pelo serviço NLA(reconhecimento de local da rede) starts before the domain is available. Nesse caso, a rede pública ou privada é escolhida e não corrigida posteriormente.

Como verificar se esta situação de falha é fornecida
Quando o controlador de domínio após a reinicialização estiver na rede pública, reinicie o serviço NLA ou desconecte / reconecte a rede. O controlador de domínio deve estar na rede de domínio posteriormente.

Como resolver
Pode ser útil configurar o Serviço NLA para o início atrasado . Melhor, verifique por que o domínio precisa de muito tempo para estar presente. Parece que o domínio precisa de mais tempo para iniciar quando há várias placas de rede.

Quando isso não ajuda
Ao acelerar o carregamento do domínio nem ao atraso da ajuda do NLA e o erro é causado pelo longo carregamento do domínio (veja: "como verificar ..."), existem alguns mais coisas que podem ser feitas.

• Escreva um script para reiniciá-lo e execute-o com o planejador (perigoso)

• Mude o carregamento do serviço NLA para o final do serviço, alterando a ordem de carregamento no registro (perigoso)

  A seguinte entrada do Registro define as dependências para NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS:

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
  "DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
  63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00
  

• Execute "IPCONFIG / RENEW" do agendador na inicialização com um atraso de 1 ou 2 minutos (melhor que iniciar o serviço NLA)

• Reinicie o serviço NLA manualmente após cada reinicialização (mas: "IPCONFIG / RENEW" deve ser preferido)!

Mais uma causa também pode ocorrer quando o controlador de domínio tem dois ou mais IPs configurados (na mesma ou em outras placas de rede) e as redes adicionais não estão configuradas no DNS.

Reprodução do comportamento
Em um controlador de domínio de teste (único controlador de domínio!), Excluí a entrada do gateway padrão e defina DNS Servercomo delayed start. Para isso, o domínio precisava de muito tempo para ser carregado e a rede foi classificada como public. Após desconectar e reconectar o cabo de rede, a rede foi classificada corretamente como domain network.

Editar

agradecido pelos comentários Daniel Fisher lennybacone Joshua Hanley:

Como adicionar uma dependência do NlaSvc ao DNS e NTDS

executar a sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSpartir do CMD (use sc.exe se você estiver executando no PowerShell). Se você quiser verificar as dependências existentes antes de adicionar DNS e NTDS, usesc qc nlasvc

Eu já vi um comportamento semelhante em um servidor AD 2008 R2. O que me levou a ter mais de uma NIC ativada, mesmo que não estivesse em uso. Depois que desativei as NICs não utilizadas e reiniciei, o problema desapareceu.

O recurso exato do Windows que você enfrenta aqui é chamado NLA (Network Location Awareness). Eu não sei o suficiente sobre isso para afirmar ser um especialista, mas sei que há algumas informações interessantes nos intertubes sobre como tudo funciona ou como deveria funcionar.

No meu caso, o servidor era DMZ e muitas regras de firewall bloqueavam o servidor para conversar com controladores de domínio. Nesse caso, você precisará abrir Firewalls (hardware FW) para permitir que os servidores se comuniquem. Também para executar um teste, conecte o servidor à rede em que as regras do firewall estão permitindo a comunicação entre o cliente e os servidores.

Após a instalação de um novo controlador de domínio, você pode achar que o "WINDOWS FIREWALL" não está definido corretamente como "DOMAIN: ON". Isso é resultado de padrões de instalação incorretos fornecidos pela Microsoft. Para corrigir isso, limpe as configurações de DNS do IP6 na conexão de rede de ":: 0" de volta para automático. Além disso, limpe os encaminhadores IP6 do servidor DNS.