Archives de catégorie : SYSVOL

DFSRMIG & SYSVOL (Republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Lors de la mise à niveau d’une infrastructure Active Directory, la mise à niveau des contrôleurs de domaine vers Windows Server 2008 doit être finalisée par une migration de NTFRS vers DFS-R. En effet, même avec des contrôleurs de domaine sous Windows Server 2008, c’est toujours NTFRS qui est utilisé pour répliquer le contenu de SYSVOL (sauf si on a pas migré). DFS-R présente un certain nombre d’avantages dont :

  • Une meilleure fiabilité dans les environnements complexes comprenant de nombreux contrôleurs de domaine
  • La possibilité de répliquer au niveau des changements opérés dans les fichiers (Remote Differential Compression)
  • Une meilleure sécurisation du contenu de SYSVOL sur les RDOC.
  • Jusqu’à seize transferts de fichiers simultanément, au lieu de quatre
  • Une gestion asynchrone des transferts
  • Une reconstruction automatique suite à un arrêt brutal du serveur

Pour bénéficier de ces avantages et de beaucoup d’autres, il est nécessaire de migrer  SYSVOL vers DFS-R. Ce processus doit être réalisé sur l’ensemble des contrôleurs de domaine de chaque domaine. le processus de migration est intégralement piloté au travers d’un seul et unique outil : “DFSRMIG.EXE”.

Pré-requis

  • La migration vers DFS-R n’est possible que dès lors que le mode de domaine est “Windows Server 2008”. Ceci implique que tous les contrôleurs de domaine de version antérieurs ont bien été migrés. Pour rappel, cette opération sera irréversible. Il ne sera plus possible de promouvoir des serveurs membre en contrôleurs de domaine pour les systèmes d’exploitation antérieur à Windows Server 2008.
  • Chaque contrôleur de domaine reportera son état de migration ainsi que son avancement dans des objets créés pour l’occasion dans l’annuaire Active Directory. Il est donc impératif que la réplication d’annuaire Active Directory soit opérationnelle. De ce fait, on peut tout de suite poser la règle suivante : “C’est la vitesse de propagation des mises à jour Active Directory qui donne le tempo de la migration et impose la durée globale de l’opération” (Commandant Sylvestre s’abstenir!).
  • Le processus de bascule vers DFS-R va reprendre le contenu du partage SYSVOL actuel. Il est donc impératif de s’assurer qu’il n’y a pas de problème à ce niveau. Par exemple qu’il y a bien cohérence entre la version de la GPO inscrite dans l’annuaire Active Directory et son contenu dans le partage SYSVOL.

Démarche

La démarche de l’outil DFSRMIG.EXE repose sur quatre phases :

  • Phase “Start” : DFSRMIG.EXE va mettre en place les moyens nécessaires au suivi de la migration pour chaque contrôleur de domaine. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Prepared” : DFSRMIG.EXE va mettre en place un nouveau répertoire SYSVOL et alimenter son contenu. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • phase “Redirected” : DFSRMIG.EXE va continuer à maintenir l’ancien répertoire SYSVOL  mais rediriger le partage vers le nouveau répertoire SYSVOL. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Eleminated” : Lors de cette dernière phase, NTFRS sera démantelé. Seul DFS-R sera utilisé pour répliquer le contenu de notre nouveau partage SYSVOL.

 

Il est à noter que l’ensemble du processus sera intégralement pilote depuis le contrôleur de domaine hébergeant le rôle de maitre d’émulateur principal de domaine (PDCE). De plus, le processus de migration est réversible (possibilité de revenir à l’état précédent ou de tout annuler) sauf pour la dernière étape. On peut donc considérer que la migration ne présente pas de risque majeur pour l’infrastructure.

Dans quel état suis-je?

C’est la phase d’initialisation. L’objectif de cette phase est de mettre en place les moyens nécessaire au suivi de la migration. D’un point de vue technique, chaque contrôleur de domaine devra reporter son état de migration dans l’annuaire Active Directory toutes les cinq minutes. C’est grâce à cela que l’on va consolider les informations et déterminer l’avancement de la migration. Pour déterminer dans quel état se trouve la migration, on dispose de la commande DFSRMIG.EXE /GetGlobalState tel qu’illustré ci-dessous :

clip_image001

 

Dans le cas illustré ci-dessous, le processus de migration n’a pas encore commencé. Pour ma démonstration, mon environnement comprend un domaine composé de trois contrôleurs de domaine opérant sous Windows Server 2008, dans un seul site Active Directory.

Initialiser la migration : Phase “Start”

Pour passer d’un mode à un autre, on dispose de l’argument “/SetGlobalState” auquel on associe une valeur. Dans le cas présent, la valeur “0” pour initialiser la phase “Start”. tel qu’illustré ci-dessous :

clip_image002

 

On peut immédiatement s’assurer que la commande a bien été prise en compte avec une nouvelle exécution de la commande “DFSRMIG.EXE /GetGlobalState” tel qu’illustré ci-dessous :

clip_image003

 

On peut même obtenir un peu plus de précision avec l’argument “/GetMigrationState” :

clip_image004

 

Pour plus d’informations, on dispose même d’un journal d’exécution de chaque commande “DFSRMIG.EXE” dans le répertoire “C:\Windows\Debug” sur chaque contrôleur de domaine. A ce stade, rien n’a encore changé, on a juste initié le processus de migration.

Préparer la migration : Phase “Prepared”

Entrons dans le vif du sujet. Le passage à la phase “Prepared” va engendrer la création d’un répertoire “SYSVOL_DFSR” sur chaque contrôleur de domaine. Son contenu sera recopié à l’aide de ROBOCOPY.EXE.

clip_image005

 

L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 1” indique que chaque contrôleur de domaine devra procéder à la création de son propre répertoire”SYSVOL_DFSR”. Pour accélérer les choses, on peut  forcer nos contrôleurs de domaine à travailler un peu plus rapidement avec la commande : “DFSRDIAG.EXE POLLAD” :

clip_image006

 

De cette manière, on force notre contrôleur de domaine à prendre en considération le changement d’état au lieu d’attendre cinq minutes. Avant de pouvoir continuer, il faut s’assurer que chaque contrôleur de domaine a bien pris en charge le changement d’état avec la commande “DFSRMIG.EXE /GetMigrationState”.

clip_image007

 

L’illustration ci-dessous nous indique que le contrôleur de domaine “DC2” n’a pas encore réaliser la première réplication initiale. Il n’est donc pas encore possible de passer à la suite.

clip_image008

 

Avec un peu de patience, tous les contrôleurs de domaine ont fini par créer leur propre répertoire “C:\Windows\SYSVOL_DFSR”. Pour s’en assurer, on trouvera même le journal d’exécution de la commande “Robocopy.Exe” dans le répertoire “C:\Windows\Debug”. On pourra y constater que l’opération à consister en une copie locale des données. On comprend donc pourquoi il est important que le contenu de SYSVOL soit cohérent entre tous les contrôleurs de domaine :

clip_image009

 

Un peu plus tôt dans ce billet, j’ai indique que chaque contrôleur de domaine reportait son état individuel de migration dans l’annuaire Active Directory. Chaque contrôleur de domaine va créer un conteneur “DFSR-LocalSettings” tel qu’illustré ci-dessous pour y référencer son état dans l’attribut msDFSR-Flags :

clip_image010

 

La valeur “16” indique un état “Prepared”. Voila donc un moyen fiable de suivre l’avancement de chaque contrôleur de domaine.

Une petite subtilité pour les RODC. Chaque contrôleur de domaine est censé maintenir son état en créant le conteneur et en renseignant l’attribut. Pour eux, ils ont besoin d’un petit coup de pouce avec la commande “DFSRMIG.EXE /CreateGlobalObjects” pour créer le conteneur à leur place. Les RODC maintiendront leur état en actualisant l’attribut directement sur le PDCE.

 

Redirection : Phase “redirected”

Jusqu’à maintenant, SYSVOL est toujours SYSVOL, il n’a pas changé. Pour s’en assurer, rien de mieux qu’une commande “NET SHARE” :

clip_image011

 

L’objectif de cette phase est de remplacer le répertoire partagé pour SYSVOL, tout en continuant à maintenir la réplication NTFRS, ce qui nous permet de toujours revenir en arrière, voire même d’annuler toute l’opération. Et bien basculons avant la commande “DFSRMIG.EXE /SetMigrationState 2” tel qu’illustré ci-dessous :

clip_image012

Lors de cette phase, chaque contrôleur de domaine va de nouveau effectuer un Robocopy entre son répertoire “SYSVOL” et “SYSVOL_DFSR” pour s’assurer qu’il dispose bien des fichiers les plus récents. Ici encore, on peut suivre chaque migration avec les fichiers de journalisation générés dans le répertoire “C:\Windows\Debug” ou bien plus globalement tel qu’illustré ci-dessous :

clip_image013

 

Si on va plus vite que la réplication, la commande “DFSRMIG.EXE /GetMigrationState” nous indiquera que nos contrôleurs de domaine n’ont pas encore commencé l’opération. Avec un peu de patience (ou à la méthode “Commandant Sylvestre”  : DFSRDIAG.EXE POLLAD + REPADMIN /SYNCALL /E = *** j’ai le réseau qui lag!), on arrive au résultat suivant :

clip_image014

 

Petite remarque, il serait opportun de “figer” les modifications réalisées sur “SYSVOL” avant de passer à la phase “Redirected” pour s’assurer que chaque contrôleur de domaine dispose bien des fichiers les plus récents.

L’avancement individuel de la migration peut être constaté en consultant la valeur de l’attribut msDFSR-Flags” qui doit être passé à 32 :

  clip_image015

 

Ou bien plus simplement avec une commande “NET SHARE”:

clip_image016

 

On constate donc que les partages “NETLOGON” et “SYSVOL” désignent maintenant un sous-répertoire différent. A ce stade, il est toujours possible de revenir en arrière, voire d’annuler toute la migration. Pour s’en convaincre, chaque contrôleur de domaine de dispose toujours de sa propre copie du répertoire SYSVOL, toujours maintenue :

clip_image017

 

Elimination: Phase “Eliminated”

L’ultime étape, celle qui est irréversible (merci de maintenir les commandants sylvestre à l’écart). L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 3” va supprimer le répertoire “SYSVOL” ainsi que les souscriptions FRS de chaque contrôleur de domaine :

clip_image018

 

Comme toujours, on peut constater l’avancement avec la commande “DFSRMIG.EXE /GetMigrationState”

clip_image019

 

Une fois l’opération terminée :

clip_image020

Et dans l’annuaire Active Directory :

clip_image021

Le service NTFRS est arrêté et n’est plus considéré comme un service dépendant pour le démarrage de l’annuaire Active Directory.

Encore une fois, petite subtilités pour les RODC. Ils ne pourront supprimer les abonnements FRS eux même. Ils ont besoin d’aide avec la commande “DFSRMIG.EXE /DeleteRoNtfrsMember”

 

Rollback ?

Oui, c’est possible mais uniquement jusqu’à la phase “redirected”. Il suffit juste d’exécuter la commande “DFSRMIG.EXE /SetGlobalState’ avec le numéro de l’état correspondant.

 

Conclusion

C’est simple, transparent pour l’utilisateur final, sans risque majeur pour l’infrastructure. En plus, cela permettra d’éviter qu’un “commandant Sylvestre” auquel on aura accordé le privilège d’administrer un RODC de supprimer le contenu de son partage SYSVOL et par extension de répliquer son erreur sur l’ensemble de l’infrastructure. DFSR détectera la problématique et procèdera automatiquement à une restauration autoritaire du contenu du partage. La migration DFSR est donc impérative dès lors que notre infrastructure comprend des RODC.

BenoîtS – Simple by Design

MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege

Les GPO de préférences sont une évolution intéressante des GPO introduite avec Windows 2008. Cependant, il y a une petite faiblesse que Microsoft a enfin corrigé. Les GPO de préférences peuvent être utilisées pour créer/ mettre à jour des comptes de services sur les systèmes gérés. Problème, il faut bien stocker le mot de passe dans la GPO. Avec un peu de recherche dans le répertoire SYSVOL d’une GPO utilisant la fonctionnalité incriminée, on trouve le fichier GROUPS.XML :

INITIALDISCLOSE

Déjà en 2009, l’équipe Group Policy reconnaissait que les mots de passe manipulés par les GPO de préférence étaient plus “masqués” que “chiffrés” et qu’il fallait bien évaluer le risque. A la vue de l’illustration ci-dessus, on pourrait penser que le mot de passe est bien chiffré. Vrai, il est chiffré en AES 256 et faux car la clé est disponible sur le MSDN. Pour vous en convaincre, exécutez le script Get-SettingsWithCPassword.ps1 mis à disposition avec la KB2962486 (il faut toujours lire un KB jusqu’au bout).

DISCLOSE1

Dans l’illustration ci-dessus le script a identifié une GPO avec un mot de passe masqué. Il a juste été nécessaire d’accéder à mon répertoire SYSVOL ou a une sauvegarde des GPO. Pour rappel toute GPO est librement accessible en lecture par défaut. 

Installer la KB2962486 ne fait que bloquer l’usage de la fonctionnalité, cela ne fait pas le ménage à votre place (d’ou l’intérêt de lire une KB jusqu’au bout). Le problème, c’est qu’il y a des développeurs Powershell talentueux qui ont développé des scripts plus complet, voire même trop  :

FINALDISCLOSE

Dans l’exemple ci-dessus, le script va jusqu’à révéler le mot de passe associé au compte “SECOURS_ADM”. Pour rappel, cette information est en libre accès (sauf si on retire le droit “read” sur la GPO pour les utilisateurs).

Que fait la KB alors? Ben elle corrige l’interface d’édition des stratégies de groupe de préférence pour nous empêcher d’utiliser la fonctionnalité.

NEW

C’est bien mais pour cela, il faut s’assurer de patcher tous les systèmes sur lesquels un administrateur utilisera l’éditeur de stratégies de groupes pour manipuler son contenu. Cela implique donc de patcher :

  • Les contrôleurs de domaine (GPMC est nativement installé)
  • Les serveurs membres (GPMC est potentiellement installé)
  • Les stations de travail (GPMC peut être installé si les RSAT sont installés)

 

En conclusion :

  • Abandonnez immédiatement l’utilisation des GPO de préférence pour manipuler les comptes & mots de passe
  • Faites la chasse aux stratégies de groupe utilisant cette fonctionnalité
  • Installez le correctifs sur tous les systèmes ou GPMC est potentiellement installé (pour éviter qu’un Administrateur ne recréé une GPO de préférence avec un mot de passe)
  • Formez vos Admins pour ne plus utiliser cette fonctionnalité!

 

Enfin, si c’est pour gérer le mot de passe Administrateur local de vos stations de travail, la solution ADMPWD est faite pour cela.

 

BenoitS – Simple and Secure by Design but Business compliant