Un article du itPro sur la réparation de AD
Dépanner la réplication d’AD – partie 1
Tags : Active Directory / Administration / Windows Server
Par Sean Deuby . Mise en ligne : 05 Janvier 2009, Publication : Octobre 2007
La réplication d’AD (Active Directory)
est la méthode par laquelle les changements de répertoire
apportés à un DC (domain controller) passent à
d’autres DC. AD est un service très robuste et à
tolérance de pannes. Comme il est distribué sur de
nombreux DC, la perte éventuelle de certaines parties de
l’entier ne paralyse pas la totalité du service de
répertoires.
Dans
une forêt d’AD, il faut superviser non seulement
l’état de santé général des DC mais
également la réplication entre eux.
L’expérience m’a appris que la réplication
dans une forêt non supervisée se dégrade un jour ou
l’autre, même si vous avez configuré les DC avec
soin.
Superviser et réparer les problèmes de réplication
quand ils surviennent est beaucoup plus facile que de remettre en
état une forêt accumulant les problèmes. Mais que
vous supervisiez ou non votre réplication d’AD, vous devrez un jour ou l’autre inévitablement la dépanner.
Dans cet article j’explique quelques principes de
réplication élémentaires et je présente une
méthode simple et directe pour dépanner les problèmes de réplication d’AD.
Dépanner la réplication d’AD n’est pas si
simple. En suivant mes pas, le côté obscur de cette
tâche devrait disparaître.
Il Mais, au début, couvrez scrupuleusement chaque étape,
Les principes de base
n’est pas facile de déterminer la meilleure approche de
dépannage de la réplication. Bien sûr, vous voulez
utiliser la méthode qui résout le problème le plus
vite possible, mais sans sauter une étape au risque de sortir
des rails. J’ai toujours constaté qu’une approche
logique, de l’extérieur vers l’intérieur,
donne le meilleur résultat. Il est naturel d’être
impatient de jouer avec des outils de dépannage
sophistiqués, mais commencez d’abord par une approche
logique pour vérifier que les éléments de base
fonctionnent correctement. Quand vous serez plus à l’aise
avec le dépannage des problèmes de réplication,
vous pourrez sauter certaines étapes.
pour ne pas sauter à la mauvaise conclusion et être
obligé de revenir en arrière. Commencez par
vérifier la santé de l’OS sur le DC lui-même,
puis vérifiez la santé du service de répertoires.
Ensuite, vérifiez les communications basiques du DC avec ses
homologues. Enfin, vérifiez le protocole que le service de
répertoires utilise et déterminez si les DC
s’authentifient bien mutuellement. En suivant ces étapes,
vous aurez résolu 90 % des problèmes de
réplication.
Vérifier la fondation (1)
En premier lieu, il faut vérifier que l’OS du DC
fonctionne bien. En effet, les erreurs de réplication peuvent
être dues à des erreurs locales sur un DC. Vous devez donc
vous assurer que la fondation du serveur est saine. Si ce n’est
déjà fait, installez le dernier Windows Server Support
Tools sur tous vos systèmes de production. (Tous les utilitaires
que je décris dans cet article sont des Windows Server Support
Tools.)
Vous pouvez télécharger ces outils depuis le Microsoft
Download Center (http://www.microsoft. com/ downloads ). Recherchez
« Support Tools » pour votre version d’OS et pour
votre niveau de pack de service. Pour consulter la liste des outils
utiles, voyez l’encadré exclusif « Replication
Troubleshooting Toolkit », http://www.itpro.fr Club
abonnés. Il est ambitieux de vouloir résoudre tous les
problèmes dans un vaste environnement. Cependant, vous pouvez
utiliser un moteur de recherche Internet et la Microsoft Knowledge Base pour détacher les problèmes les plus notables.
Après avoir installé le Windows Server Support Tools, examinez les journaux d’événements.
Premièrement, vérifiez les avertissements et erreurs qui
pourraient se trouver dans le journal système. Si vous y trouvez
des erreurs, essayez d’exécuter NetDiag. Même sans
utiliser aucune de ces options ligne de commande, NetDiag
exécute 23 tests liés à la configuration
réseau du système. Parmi les tests utiles qu’il
effectue, on retiendra : appartenance aux domaines, DNS, configuration
client, relations d’approbation, Kerberos, et
fonctionnalité LDAP.
Si vous détectez une zone à problème,
réexécutez NetDiag avec le commutateur /test:testname et
l’option /v pour obtenir une analyse de test
détaillée de la zone. Une option NetDiag importante
à laquelle je fais référence plus loin dans
l’article est le commutateur /fix, qui réenregistre les
entrées DNS du serveur.
Si le journal du service de répertoires contient des erreurs,
exécutez DCDiag. C’est un utilitaire de test complet pour
les DC. Même sans utiliser aucune de ses options ligne de
commande, DCDiag exécute 25 tests liés au DC. Comme pour
NetDiag, si vous trouvez une zone à problèmes,
réexécutez DCDiag avec le commutateur /test:testname et
l’option /v pour obtenir une analyse de test
détaillée de la zone.
Ne vous laissez pas accaparer par des erreurs dans le test du journal
système ; des erreurs récentes dans le journal
système feront échouer ce test.
Si tout se présente bien à ce stade - Utilisons le domaine que montre la figure 1 pour voir comment Par conséquent, même si la réplication dans un site Bien que ce message d’erreur soit dense, nous pouvons analyser le L’un des premiers tests consiste à faire un ping vers
Vérifier la fondation (2)
c’est-à-dire si NetDiag et DCDiag n’ont
révélé aucune erreur liée à
l’OS ou au service de répertoires – il est temps de
commencer à examiner la réplication. Le meilleur endroit
pour commencer est de vérifier vos résultats de tests
DCDiag, parce que DCDiag effectue des tests de réplication
très poussés.
dépanner une erreur courante. Ce domaine, appelé
Deuby.net, a trois DC. Les DC nommés Godan et Kohai sont dans le
site Hub. Le DC nommé Sandan est dans le site Branch,
connecté au site Hub par une liaison de sites avec un intervalle
de réplication de 15 minutes. Supposons que les mises à
jour ne se répliquent pas de Kohai à Godan. La
réplication est toujours une opération entrante.
est déclenchée par des notifications de changement
provenant d’un DC qui a été mis à jour, vous
devez considérer que les mises à jour sont tirées
vers l’intérieur par le DC cible à partir
d’un autre DC. Commencez votre dépannage sur le DC qui
devrait recevoir les mises à jour. Dans mon exemple, ce DC est
Godan. La figure 2 montre la sortie partielle obtenue en
exécutant DCDiag sur Godan. Observez que le test Replication a
échoué parce que l’erreur « [KOHAI]
DsBindWithSpnEx() failed with error 1722, The RPC server is unavailable
».
message pour avoir une idée claire du problème. A
l’évidence, ce dernier a quelque chose à voir avec
le DC Kohai. Mais que signifie « DsBind WithSpnEx() » ?
« DsBindWithSpn » nous indique que l’erreur
s’est produite quand Godan a tenté de se lier
(c’est-à-dire de se connecter et de s’authentifier)
à Kohai. Il semble donc que Godan ne communique pas bien avec
Kohai. Il nous faut déterminer si Godan peut même trouver
son partenaire de réplication Kohai.
l’adresse IP de Kohai pour vérifier la connectivité
basique du réseau. Si ce test est concluant, vous pourriez
envoyer un ping à Kohai par le nom (c’est-à-dire
par son enregistrement DNS A). Cependant cette méthode
n’est pas un test concluant pour la réplication parce
qu’un DC trouve ses paramètres de réplication non
pas en résolvant leurs enregistrements A (par exemple
dc1.mycompany.com) mais en résolvant un DNS Canonical Name
(CNAME – c’est-à-dire alias) spécial, garanti
unique dans la forêt.
Vérifier la fondation (3)
Chaque DC de la forêt doit enregistrer son enregistrement CNAME
pour le nom DsaGuid._msdcs.ForestName ; ce CNAME identifie le DC
auprès du système de réplication comme un DC.
L’enregistrement CNAME associe cette chaîne à
l’enregistrement A du DC, lequel contient son adresse IP.
Par exemple, le CNAME DNS de dc1.mycompany.com pourrait être
d40c01da-23fa-46e6- 8bf3-798503e 2590f._ msdcs.mycompany.com.
L’enregistrement CNAME serait
d40c01da-23fa-46e6-8bf3-798503e2590f._msdcs. mycompany.com.
A noter que le GUID (globally unique identifier) du DSA (directory
service agent) qui comprend la première partie du CNAME du DC
n’est pas le GUID (spécifiquement l’attribut GUID
objet) de l’objet ordinateur du DC, comme vous pourriez vous y
attendre. Au lieu de cela, c’est le GUID de l’objet NTDS
Settings sous le DC dans le conteneur Sites.
Par exemple, si le DC1 était dans le site Hub, son DN
(distinguished name) serait SN=NTDS Settings, CN=DC1, CN=Servers,
CN=Hub, CN=sites, CN=configuration, DC= mycompany, DC=com. Si le DC en
difficulté ne peut pas résoudre le CNAME de son
partenaire de réplication, il ne pourra pas non plus en recevoir
des mises à jour.
Par conséquent, vous devez d’abord déterminer le
CNAME DNS basé sur GUID de Kohai ; puis vous devez voir si Godan
peut résoudre le CNAME. Probablement le moyen le plus simple
pour cela est de lancer Active Directory Sites and Services,
d’approfondir dans le site de Godan (c’est-à-dire,
Hub, Servers container, objet ordinateur KOHAI), puis de faire un clic
droit sur le conteneur NTDS Settings et sélectionner Properties.
Le CNAME de Kohai est dans le champ DNS Alias comme le montre la figure
3. Copiez et collez cette chaîne dans une commande Ping en
l’incluant dans une invite de commande sur Godan, comme le montre
la figure 4, pour déterminer si le moteur de réplication
peut résoudre Kohai. Comme DNS ne peut pas résoudre Kohai
via son CNAME, la réplication ne peut pas se produire. A noter
qu’une requête similaire utilisant le CNAME de Godan
résout correctement.
Nous avons déterminé le problème : CNAME DNS de
Kohai est manquant. Il existe deux méthodes pour le
réenregistrer. Une solution simple et directe consiste à
arrêter et démarrer le service Netlogon ; hélas,
cette méthode va aussi interrompre temporairement la
communication entre Kohai et ses utilisateurs actifs. Le seul fait
qu’un DC ait des problèmes de réplication ne
signifie pas forcément qu’il ne sert pas ses utilisateurs.
Une solution plus discrète consiste à exécuter
NetDiag /fix. Le paramètre /fix sert spécifiquement
à réenregistrer tous les enregistrements DNS
nécessaires pour un DC. Après cette étape, NetDiag
s’exécute de façon satisfaisante, mais avec un
avertissement disant que le CNAME nouvellement ajouté prendra un
certain temps pour se répliquer vers le serveur DNS qui est
spécifié comme secondaire dans la configuration DNS de la
carte réseau.