Restauration autoritaire de SYSVOL

Posted on

J’aime bien commencer une belle et chaude semaine d’été par une restauration autoritaire de SYSVOL. Ou comment annoncer gentillement que bordel de merde, c’est pas le moment, j’avais vraiment autre chose à faire que de me prendre le choux avec ça. Ce billet détaille ma résolution pour remettre debout l’infra Active Directory.

État des lieux

Avant toute chose, il est de rigueur de décrire le parc et les versions utilisées. En effet Microsoft a introduit énormément de changements à partir de Windows Server 2008, et la procédure décrite ici ne pourra en conséquence pas fonctionner pour un contrôleur de domaine Windows Server 2003 ou plus ancien. Pour être plus précis, la procédure ne peut s’appliquer que lorsque le niveau fonctionnel du domaine est au minimum fixé à Windows Server 2008.

Le parc est plutôt modeste et est, pour la partie qui nous concerne, composé de :

  • 1 contrôleur de domaine sous Windows Server 2012 (AZSHARA)
  • 1 contrôleur de domaine sous Windows Server 2012R2 (ALEXSTRASZA)
  • le niveau fonctionnel du domaine est fixé à Windows Server 2012
  • le niveau fonctionnel de la forêt est fixé à Windows Server 2012
  • un script PowerShell qui s’exécute au démarrage de chaque ordinateur via une GPO. Le script est enregistré quelque part dans le partage SYSVOL

sysvol_script_ps

Symptômes

J’avoue qu’il s’agit d’un problème qui aurait pu être évité, mais ne connaissant aucun indicateur fiable « OK, ton domaine fonctionne normalement, tout est bien synchronisé » (en revanche si vous en connaissez un, un script ou n’importe quoi qui puisse me donner l’état de santé du domaine, je suis preneur), j’ai du faire avec les petits moyens dont je dispose.
A priori, les contrôleurs de domaine fonctionnaient normalement, les utilisateurs pouvaient se logguer, les contrôleurs étaient redémarrés régulièrement pour appliquer les mises à jour Windows. Cependant il existait un phénomène assez curieux mais sur lequel je ne me suis penché qu’assez tardivement : de temps en temps, les changements que je faisais sur le script PowerShell n’étaient pas pris en compte lorsque je le testais par la suite sur une VM de test. Ce script est mis à jour assez régulièrement car il sert à déployer tout ce qui ne repose pas sur du MSI, c’est à dire Firefox, Filezilla, les grosses mises à jour Visual Studio etc…
Après une énième occurrence du phénomène, je décide de prendre 5 minutes pour regarder de plus près ce qu’il se passe vraiment. J’accède alors au partage SYSVOL où se trouve le script sur chaque contrôleur de domaine et là, c’est le drame : chaque serveur possède une version du script différente ; le partage n’est absolument plus synchronisé, dans un sens comme dans l’autre.

Diagnostic

Comme toujours dans ces cas là, on part à la chasse aux informations. Je trouve assez rapidement la raison pour laquelle il n’existe plus de réplication dans le journal d’événement d’un des contrôleurs de domaine.

event_bad-stop

C’est à partir d’ici où il est important de savoir dans quel niveau fonctionnel le domaine se trouve. Les contrôleurs de domaines sont tous maîtres, il n’y a pas (par défaut) de relation 1 maître – x esclaves comme c’est souvent le cas pour les serveurs de bases de données transactionnelles. Les données synchronisés entre les contrôleurs de domaine sont :

  • l’annuaire. Il contient entre autre tous les utilisateurs, groupes, unités organisationnelles, les enregistrements DNS, la topologie de réplication.
  • le partage SYSVOL, il contient mon script et des fichiers en relation directe avec les stratégies de groupe (les GPOs) mises en place.

Etant donné que le problème ne se situe pas sur l’annuaire, la commande repadmin.exe ne sera d’aucun secours. A la place, il faudra utiliser la commande dfsrdiag.exe.
Vu que cette dernière est bien barbare et demande un certain nombre de paramètre non évident, j’ai préféré examiner la réplication via la console de gestion du système de fichiers distributés DFS (dfsmgmt.msc).
Cette console permet de créer un rapport d’intégrité (première option), ce que j’ai fait ou de tester la propagation (seconde option pour lancer le test, troisième option pour suivre la progression du test)
Je vous conseille fortement d’ouvrir ce rapport exclusivement avec Internet Explorer sous peine d’avoir du hachis parmentier à l’écran avec un autre navigateur.

rapport-1 rapport-2 rapport-3 rapport-4

 

Résolution

Je suis donc la procédure décrite dans l’événement pour relancer la synchronisation, cela nous mène au second drame.

Et impose un choix à faire parmi deux propositions :

  • on suit les recommandations de l’événement et on considère que la copie du partage SYSVOL est foutue car trop vieille. La bonne copie est donc celle se trouvant sur l’autre contrôleur de domaine. C’est souvent le choix à faire dans le cas où l’on a au moins 3 contrôleurs de domaines dont 2 au minimum ont une réplication fonctionnelle du partage SYSVOL.
  • on fait sa tête de mule et l’on décide que finalement la vieille copie est la bonne et devrait écraser l’autre copie.

Restauration autoritaire / non-autoritaire

  • Si vous avez un contrôleur de domaine avec un SYSVOL propre, alors vous pouvez (et même devriez) effectuer une restauration dite non-autoritaire, c’est à dire que l’on va invalider la copie du SYSVOL foutue, afin que le contrôleur de domaine qui héberge la copie la resynchronise à partir des autres contrôleurs de domaine. Dans mon cas, cela se traduit par AZSHARA qui va synchroniser son partage SYSVOL à partir de ALEXSTRASZA
  • Si vous avez opté pour le second choix ou bien si aucun contrôleur de domaine n’a un SYSVOL propre, alors il est nécessaire d’effectuer une restauration dite autoritaire, c’est-à-dire que l’on va explicitement déclarer qu’un des contrôleurs de domaine a la « bonne » copie du SYSVOL, et tous les autres contrôleurs de domaines vont effectuer une resynchronisation sur cette copie. La restauration autoritaire est à considérer comme la solution de la dernière chance, il est préférable tant que faire se peut d’effectuer en priorité une restauration non-autoritaire.

Sources

No Comments

Post a Comment