Suite au déplacement du rôle FSMO PDC sur un autre contrôleur du domaine, les synchronisations NTP ne fonctionnent plus et des problèmes d’accès à la console GPMC apparaissent.
Sommaire
Symptômes
Chez l’un de mes clients, pour préparer une migration AD, j’ai dû déplacer le rôle PDC sur un autre contrôleur du domaine. Jusque-là rien de compliqué.
Au niveau NTP, simple reconfiguration du PDC pour qu’il se synchronise avec un NTP publique et vérification sur tous les contrôleurs de domaine que ceux-ci récupèrent bien la nouvelle configuration et basculent donc sur le nouveau PDC.
Le monitoring du NTP est réalisé avec la commande :
w32tm /monitor
A l’aide de cette commande, il est possible de connaitre la configuration NTP de chaque DC, notamment :
- qui est le PDC.
- quel est le NTP de référence pour chaque DC.
- le décalage de temps.
Environ 2 heures après la migration du PDC, aucun DC ne pointait sur le nouveau PDC mais restait bloqué sur l’ancien.
Après quelques commandes de bases pour forcer la reconfiguration automatique du service NTP sur un DC, vérification de la configuration (NT5DS) et redémarrage du service w32time. Impossible de se synchroniser avec le PDC, et même pire, la source de temps est passée en local “Local CMOS Clock”.
w32tm /query /source
Local CMOS Clock
Ci-dessous vous trouverez un extrait de la commande w32tm /monitor.
Depuis la console GPMC impossible de se connecter au domaine et d’accéder aux GPO.
Le PDC est donc bien hors-service.
Cause
Après quelques heures à éplucher les logs des DC et un retour arrière, je remarque des erreurs NETLOGON noyées au milieu d’autres erreurs.
Ci-dessous un exemple d’erreur :
Cette même erreur présente pour les enregistrements DNS :
- _ldap._tcp.dc._msdcs.
- _kerberos._tcp.SITE._sites.dc._msdcs.
- _kerberos._tcp.dc._msdcs.
- gc._msdcs.
- …
Et sont présentes sur 90% des DC du domaine.
Ce n’est pas le type d’erreur que l’on aime voir. Mais par forcément de rapport avec le déplacement du PDC.
Quoi qu’il en soit ces erreurs ne sont pas normales et avec le peu d’idée pour résoudre le problème de migration NTP /PDC KO, pourquoi ne pas chercher de ce côté-ci.
Après quelques vérifications, chez ce client-ci, le DNS n’est pas un DNS Windows, mais un Infoblox. Par défaut, la mise à jour dynamique des enregistrements DNS n’est pas activée, il faut donc truster chaque DC sur chaque zone DNS.
Et étrangement, après vérification la plupart des DC n’a pas été trusté sur l’ensemble des zones AD (notamment la zone _msdcs).
Solution
Une fois les autorisations sur les zones DNS mise à jour, tous les DC ont put recréer leurs enregistrements DNS (quelques redémarrages et ipconfig /registerdns) et miracle plus d’erreurs NETLOGON.
Second miracle, le déplacement du rôle PDC s’est déroulé sans souci, la configuration NTP des DC est remontée automatiquement comme cela aurait dû être le cas lors du premier déplacement.
Les contrôleurs se réenregistrent dans le DNS a minima à chaque reboot. Et donc recréés tous les enregistrements liais à AD.
Pour recréer manuellement, utiliser :
ipconfig /registerdns
Je reconnais que les erreurs NETLOGON auraient pu être détectées lors des dcdiag de pré migration. Mais sur ce domaine ci, il y a suffisamment d’erreurs pour que celles-ci soient diluées au milieu des autres.
