J'essaie de connecter une machine Windows 7 Ultimate à un domaine Windows 2k8 et cela ne fonctionne pas. Je reçois cette erreur:
Remarque: Ces informations sont destinées à un administrateur réseau. Si vous n'êtes pas administrateur de votre réseau, informez l'administrateur que vous avez reçu ces informations, qui ont été enregistrées dans le fichier C: \ Windows \ debug \ dcdiag.txt.
DNS a été interrogé avec succès pour l'enregistrement de ressource d'emplacement de service (SRV) utilisé pour localiser un contrôleur de domaine pour le domaine "example.local":
La requête concernait l'enregistrement SRV pour _ldap._tcp.dc._msdcs.example.local
Les contrôleurs de domaine suivants ont été identifiés par la requête:
dc1.example.local
dc2.example.localCependant, aucun contrôleur de domaine n'a pu être contacté.
Les causes courantes de cette erreur incluent:
Les enregistrements d'hôte (A) ou (AAAA) qui mappent les noms des contrôleurs de domaine à leurs adresses IP sont manquants ou contiennent des adresses incorrectes.
Les contrôleurs de domaine enregistrés dans DNS ne sont pas connectés au réseau ou ne fonctionnent pas.
Le client est dans un bureau connecté à distance via MPLS au centre de données où nos contrôleurs de domaine existent. Je ne semble pas avoir quelque chose qui bloque la connectivité aux contrôleurs de domaine, mais je n'ai pas un contrôle total sur le circuit MPLS, il est donc possible que quelque chose bloque la connectivité.
J'ai essayé plusieurs clients (Win7 Ultimate et WinXP SP3) dans le même bureau et j'obtiens les mêmes symptômes sur chacun d'eux.
Je n'ai aucun problème à me connecter à l'un des contrôleurs de domaine, même si je n'ai certes pas essayé tous les ports possibles. Les connexions ICMP, LDAP, DNS et SMB fonctionnent toutes bien.
Le DNS client pointe vers les contrôleurs de domaine et "example.local" résout les deux adresses IP des contrôleurs de domaine.
J'obtiens cette sortie de l'utilitaire de ligne de commande NetLogon Test:
C:\Windows\System32>nltest /dsgetdc:example.local
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
J'ai également créé un réseau distinct pour émuler la configuration de ce bureau qui est connecté au réseau DC via un VPN LAN à LAN au lieu de MPLS. Rejoindre des ordinateurs Windows 7 à partir de ce réseau distant fonctionne correctement.
La seule différence que je peux trouver entre les deux environnements est la connectivité intermédiaire, mais je ne sais pas quoi tester ou comment le faire. Quelles autres mesures dois-je prendre?
(Notez que ce n'est pas vraiment mon poste de travail client et que je n'y ai pas d'accès direct; je suis obligé d'y accéder à distance, ce qui rend certaines des méthodes de dépannage évidentes, comme le reniflage de paquets, plus difficiles. Si je Je pourrais simplement y installer un système dans lequel je pourrais me connecter à distance, mais les demandes à cet effet sont restées sans réponse.)
Mise à jour du 25-08-2011:
j'avais DCDIAG.EXE
exécuté sur un client essayant de rejoindre le domaine:
C:\Windows\System32>dcdiag /u:example\adminuser /p:********* /s:dc2.example.local
Directory Server Diagnosis
Performing initial setup:
Ldap search capabality attribute search failed on server
dc2.example.local, return value = 81
On dirait qu'il a pu se connecter via LDAP, mais la chose qu'il essayait de faire a échoué. Mais je ne suis pas tout à fait à la hauteur de ce qu'il essayait de faire, encore moins comment le reproduire ou le résoudre.
Mise à jour du 2011-08-26: L'
utilisation LDP.EXE
pour essayer d'établir une connexion LDAP directement avec les contrôleurs de domaine entraîne les erreurs suivantes:
ld = ldap_open ("10.0.0.1", 389);
Erreur <0x51>: échec de connexion à 10.0.0.1.
ld = ldap_open ("10.0.0.2", 389);
Erreur <0x51>: échec de connexion à 10.0.0.2.
ld = ldap_open ("10.0.0.1", 3268);
Erreur <0x51>: échec de connexion à 10.0.0.1.
ld = ldap_open ("10.0.0.2", 3268);
Erreur <0x51>: échec de connexion à 10.0.0.2.
Cela semblerait pointer du doigt les connexions LDAP bloquées quelque part. (Et 0x51 == 81, qui était l'erreur de DCDIAG.EXE
la mise à jour d'hier.) Je pourrais jurer que j'ai testé cela en utilisant des TELNET.EXE
semaines auparavant, mais maintenant je pense que j'ai peut-être supposé que son effacement de l'écran me disait que c'était attendre et non pas qu'il se soit connecté.
Je recherche les problèmes de connectivité LDAP maintenant. Cette mise à jour peut devenir une réponse.
dcdiag
sortie.Réponses:
Il a fallu une éternité pour trouver où cela se passait, mais il s'avère qu'il y avait des filtres dans le VPN bloquant le trafic LDAP (et autres). J'ai effacé ces filtres et maintenant ça marche.
la source
Il pourrait y avoir un pare-feu entre la machine Win7 et les contrôleurs de domaine.
Si vous avez accès à nmap :
Mise à jour:
NtVer demande V5 (netlogon version5), V5EX (ouverture de session étendue version 5), VCS (dc le plus proche). Tiré de Win7Ent.
(ldap hex est trixy.)
la source
nltest
ne les cherche pas. Vérifiez que le client peut obtenir l'enregistrement SRV. Ne pensez pas que les serveurs MS DNS divisent la vue, mais manquent d'options.On dirait que le win7 ne pointe pas son DNS vers un DC? Peut-être que DHCP pointe DNS vers le DNS des fournisseurs Internet?
la source
Il semble que vous ayez tout essayé et testé en ce qui concerne le DNS, mais avez-vous vérifié que les enregistrements A pour les serveurs DC / DNS existent et sont corrects? Que se passe-t-il lorsque vous exécutez nslookup pour tester la présence des enregistrements A sur les deux serveurs sur les deux serveurs? Les contrôleurs de domaine renvoyés dans le message d'erreur sont-ils réellement les serveurs DC / DNS corrects pour le domaine?
la source
Existe-t-il une possibilité que le client du bureau distant exécute uniquement IPv6 et bien qu'il trouve l'enregistrement SRV pour le contrôleur de domaine, DNS n'est pas configuré avec des enregistrements AAAA (IPV6)?
la source