Le contrôleur de domaine pense que c'est sur un réseau public
Nous avons un Server 2008 R2 Primaire Contrôleur de domaine 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 trouve heureusement qu'il fait réellement 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 peut pas le cingler avec succès, il ne pourra pas identifier le réseau auquel il est connecté et supposera qu'il est public.
Indique si le réseau d'un contrôleur de domaine est 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 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 de défaut est donnée
Lorsque le contrôleur de domaine après le redémarrage se trouve sur 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 définir le service NLA sur 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
Lorsque ni l'accélération du chargement du domaine ni le retard de l'aide NLA et que l'erreur n'est provoquée par le long chargement du domaine (regardez: "comment vérifier ..."), alors il y en a d'autres les 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,00Exé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 Server à delayed start. En faisant cela, le domaine avait besoin de temps pour se charger et le réseau était 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.
Éditer
avec reconnaissance des commentaires de Daniel Fisher lennybacon et Joshua Hanley:
Comment ajouter une dépendance pour NlaSvc à DNS et NTDS
courir sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS depuis 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, utilisez sc qc nlasvc
J'ai vu un comportement similaire sur un serveur 2008 R2 AD. La chose qui m'a permis d'avoir plus d'un NIC activé, même s'il n'était pas utilisé. 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 bloquant 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 également un test, connectez le serveur au réseau où les règles de pare-feu autorisent les communications entre le client et les serveurs.