Cet article est la suite de Dépanner la réplication d’AD -partie 1. Il traite de la supervision et de la réparation des problèmes de réplication.
Contenu complémentaire : Le site de la Cadim Dépanner la réplication d’AD - partie 1 |
Cet article est la suite de Dépanner la réplication d’AD -partie 1. Il traite de la supervision et de la réparation des problèmes de réplication.
Contenu complémentaire : Le site de la Cadim Dépanner la réplication d’AD - partie 1 |
Mon exemple montre pourquoi une mauvaise configuration de DNS est la cause la plus fréquente des problèmes d’AD. La configuration de DNS est complexe et étroitement intégrée à la fonctionnalité des AD. Il existe de nombreuses manières de mal configurer DNS. En cas de défaillances de consultation de DNS ou autres erreurs de type « can’t locate » pour un DC, vous devez passer en revue les points suivants.
Vérifiez que les adresses IP dans les paramètres client du DC (propriétés TCP/IP de la connexion de zone locale) sont correctes. Si le DC est aussi un serveur DNS, la configuration recommandée est que l’entrée DNS primaire pointe sur elle-même. (Longhorn Server configurera automatiquement l’entrée DNS pour un retour en boucle – 127.0.0.1 – quand Dcpromo s’exécute.) Le serveur DNS secondaire doit pointer vers un autre DC dans le même domaine. Pour plus de détails sur les avantages et inconvénients des différents types de configurations client DNS pour les DC, voir l’article Microsoft « Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 ».
Le serveur DNS primaire d’un DC est son seul moyen de trouver d’autres ressources sur le réseau. Donc, vous pouvez contrôler la connaissance par un DC d’autres serveurs et domaines en contrôlant son entrée DNS primaire. Si vous vous demandez si le propre serveur DNS du DC fonctionne, pointez l’entrée DNS primaire vers un serveur DNS qui marche bien. Assurez-vous que le DC a déjà enregistré les enregistrements de ressources dont il a besoin pour fonctionner.
Trois enregistrements ont un rapport avec la réplication. Deux d’entre eux sont le CNAME (déjà vu) et son enregistrement A (c’est-à-dire la traduction du nom d’hôte en adresse IP). Vous pouvez exécuter DCDiag /test:connectivity pour confirmer que ces enregistrements sont enregistrés dans le serveur DNS primaire du DC. Et vous pouvez utiliser la commande NetDiag pour enregistrer les enregistrements si nécessaire.
Si les enregistrements ne s’enregistrent toujours pas, exécutez DCDiag /test:Registerdomain /Dns Domain: dnsdomainname pour vérifier que le DC est configuré de manière à effectuer l’enregistrement. L’enregistrement A doit aussi être associé à l’adresse IP correcte et souvenez-vous que ces enregistrements doivent se répliquer sur les serveurs DNS que leurs partenaires utilisent avant de pouvoir les trouver. (A noter que la commande IPConfig /RegisterDNS n’enregistre pas tous les enregistrements DNS dont un DC a besoin.)
Pour les DC de domaines enfants dans une configuration d’arborescence de domaines, vous devez vérifier un troisième enregistrement : Glue. Les enregistrements Glue sont des enregistrements A des serveurs DNS (autrement dit, vos DC) pour les domaines enfants de la forêt, gardés dans la zone de consultation avant du domaine racine.
Les enregistrements Glue aident à résoudre un dilemme de référence circulaire sans fin : pour trouver un hôte dans un domaine enfant à partir de l’extérieur de ce domaine, vous devez parler à un serveur DNS qui a l’autorité pour le domaine ; mais vous ne pouvez pas résoudre ce serveur ayant autorité, parce que son enregistrement A est précisément le domaine sur lequel vous essayez d’obtenir l’information DNS ! Le placement d’un second ensemble d’enregistrements A pour les serveurs DNS du domaine enfant dans le domaine racine résout ce problème de référence et par conséquence colle (glue) le domaine enfant à la racine. Le test DNS DCDiag avec l’option /DnsDelegation (DCDiag /test:DNS /DnsDelegation) teste l’enregistrement correct des enregistrements glue d’un DC.
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.