Le contrôleur de domaine pense que c'est sur un réseau public

Nous avons un contrôleur de domaine principal Server 2008 R2 qui semble amnésique lorsqu'il s'agit de déterminer sur quel type de réseau il se trouve. La (seule) connexion réseau est identifiée au démarrage comme un «réseau public».

Pourtant, si je désactive puis réactive la connexion, il se rend compte heureusement qu'elle fait en fait partie d'un réseau de domaine.

Est-ce parce que les services de domaine AD ne sont pas démarrés lorsque l'emplacement réseau est initialement défini?

Ce problème provoque des maux de tête avec les règles du pare-feu Windows (qui, je le sais, peuvent être résolues d'autres manières), donc je suis surtout curieux de voir si quelqu'un sait pourquoi cela se produit.

Avez-vous une passerelle par défaut sur cette connexion? Répond-il aux requêtes ping?

Windows utilise des passerelles pour identifier les réseaux; s'il n'a pas de passerelle configurée, ou s'il ne réussit pas à le ping, il ne pourra pas identifier le réseau auquel il est connecté et supposera qu'il est public.

Le fait que le réseau d'un contrôleur de domaine soit classé comme réseau de domaine ne dépend pas de la configuration de la passerelle.

Le comportement d'une fausse classification de réseau peut être provoqué par le service NLA(détection d'emplacement de réseau) starts before the domain is available. Dans ce cas, le réseau public ou privé est choisi et non corrigé par la suite.

Comment vérifier si cette situation d'erreur est donnée
Lorsque le contrôleur de domaine après le redémarrage est dans le réseau public, redémarrez le service NLA ou déconnectez / reconnectez le réseau. Le contrôleur de domaine doit ensuite être dans le réseau de domaine.

Comment le résoudre
Il peut être utile de régler le service NLA sur un démarrage différé . Mieux, vérifiez pourquoi le domaine a besoin de temps pour être présent. Il semble que le domaine ait besoin de plus de temps pour démarrer lorsqu'il existe plusieurs cartes réseau.

Quand ça n'aide pas
Quand ni l'accélération du chargement du domaine ni le retard de l'aide NLA et l'erreur sont causés par le long chargement du domaine (regardez: "comment vérifier ..."), alors il y en a plus de choses qui peuvent être faites.

• Écrire un script pour le redémarrer et l'exécuter avec le planificateur (dangereux)

• Décaler le chargement du service NLA à la fin du service commence, en changeant l'ordre de chargement dans le registre (dangereux)

  L'entrée de Registre suivante définit les dépendances sur 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
  

• Exécutez "IPCONFIG / RENEW" à partir du planificateur au démarrage avec un délai de 1 ou 2 minutes (mieux que le démarrage du service NLA)

• Redémarrez le service NLA manuellement après chaque redémarrage (mais: "IPCONFIG / RENEW" devrait être préféré)!

Une autre cause peut également être lorsque le contrôleur de domaine a deux adresses IP ou plus configurées (sur la même carte ou sur d'autres cartes réseau) et que les réseaux supplémentaires ne sont pas configurés dans le DNS.

Reproduction du comportement
Sur un contrôleur de domaine de test (DC unique!), J'ai supprimé l'entrée de passerelle par défaut et défini le DNS Serversur delayed start. En faisant cela, le domaine avait besoin de temps pour être chargé et le réseau a été classé comme public. Après avoir déconnecté et reconnecté le câble réseau, le réseau a été correctement classé comme domain network.

modifier

avec reconnaissance des commentaires de Daniel Fisher lennybaconet Joshua Hanley:

Comment ajouter une dépendance pour NlaSvc à DNS et NTDS

exécutez à sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSpartir de CMD (utilisez sc.exe si vous l'exécutez dans PowerShell). Si vous souhaitez vérifier les dépendances existantes avant d'ajouter DNS et NTDS, utilisezsc qc nlasvc

J'ai vu un comportement similaire sur un serveur 2008 R2 AD. La chose qui m'a permis d'avoir plus d'une carte réseau activée, même si elle n'était pas utilisée. Une fois que j'ai désactivé les cartes réseau inutilisées et redémarré, le problème a disparu.

La fonctionnalité Windows exacte que vous rencontrez ici s'appelle NLA (Network Location Awareness). Je n'en sais pas assez pour prétendre être un expert, mais je sais qu'il y a des informations intéressantes sur les intertubes sur la façon dont tout cela fonctionne, ou est censé fonctionner.

Dans mon cas, le serveur était DMZ et de nombreuses règles de pare-feu bloquaient le serveur pour parler aux contrôleurs de domaine. Dans ce cas, vous devrez ouvrir des pare-feu (matériel FW) pour permettre aux serveurs de communiquer. Pour exécuter un test, connectez également le serveur au réseau où les règles de pare-feu autorisent les communications entre le client et les serveurs.

Après avoir installé un nouveau contrôleur de domaine, vous pouvez constater que le "PARE-FEU WINDOWS" n'est pas configuré correctement sur "DOMAINE: ON". Ceci est le résultat de défauts d'installation par défaut fournis par Microsoft. Pour résoudre ce problème, effacez les paramètres DNS IP6 sur la connexion réseau de ":: 0" à automatique. Supprimez également les redirecteurs IP6 du serveur DNS.