Analyser automatiquement les performances de vos contrôleurs de domaine

Sommaire

 


Introduction

Pour analyser les performances de vos contrôleurs de domaine il existe le collecteur de données « Diagnostics Active Directory ». Il est disponible par défaut sur Windows Server 2008 et est  donc particulièrement utile pour identifier des éventuels problèmes de performances.

Je vais donc dans un premier temps vous montrer à quoi cela ressemble et comment l’utiliser. Ensuite, on ira un peu plus loin afin que vous le lanciez automatiquement et au moment le plus opportun.

 

 

Le collecteur de données « Diagnostics Active Directory »

Introduit sous Windows Server 2003 et connu sous le nom de « Server Performance Advisor » (http://www.microsoft.com/en-us/download/details.aspx?id=15506), il est désormais intégré nativement sous Windows Server 2008 sous la forme d’un collecteur de données et est donc appelé « Diagnostics Active Directory ». Il permet de faire une collecte de données exhaustive sur le contrôleur de domaine et de générer un rapport au format HTML.

De plus, le rapport est particulièrement intéressant car Microsoft à créer un ensemble de règles permettant de mettre en relief ce qui ne va pas (exemple : un manque de mémoire, une requête LDAP malformée ou/et consommatrice…). Il n’est donc pas nécessaire de se creuser la tête pendant des heures sur l’analyse de données.

Pour générer donc un rapport de diagnostiques il faut premièrement lancer la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Depuis la console « Analyseur de performances », développez l’arborescence « Ensemble de collecteurs de données > Système » et à l’aide d’un clic droit sur  « Active Directory Diagnostics (Diagnostics Active Directory) », sélectionnez « Démarrer ».

 

A la fin de la collecte, un rapport de diagnostiques est disponible depuis « Rapports > Système > Active Directory Diagnostics ».

 

Par défaut, la collecte dure 5 minutes et vous ne pouvez pas la modifier. Si vous voulez l’adapter à vos besoins, alors la seule solution va être de créer un modèle de données personnalisé (dit « utilisateur ») s’appuyant sur le modèle existant (dit « système »). Toutefois, je ne vais pas rentrer plus dans le détail car ce n’est pas l’objet de l’article mais si vous voulez plus d’information sur le sujet, je vous propose déjà l’article suivant : Son of SPA: AD Data Collector Sets in Win2008 and beyond (http://blogs.technet.com/b/askds/archive/2010/06/08/son-of-spa-ad-data-collector-sets-in-win2008-and-beyond.aspx).

Maintenant revenons à nos moutons… Il est particulièrement intéressant de disposer d’un outil de la sorte mais faut-il encore que la collecte soit réalisée au bon moment. L’objectif étant de pouvoir identifier clairement l’origine d’une quelconque défaillance. Et pour cela, il faut que le déclenchement se fasse de manière automatique.

 

 

Présentation de la solution

Généralement, les problèmes de performances sur un contrôleur de domaine se traduisent par une utilisation excessive des ressources CPU par le processus LSASS. Nous allons donc définir une alerte de performance sur la consommation processeur de LSASS qui va, après un certain seuil, déclencher le collecteur de données « Diagnostics Active Directory ».

Pour améliorer la pertinence de notre collecte, l’alerte de performance ne va pas déclencher automatiquement le collecteur de données. Le petit plus de l’article est de passer par le biais d’un script qui prendra en charge le déclenchement de la collecte uniquement après plusieurs alertes.

Prenons un exemple. SCOM, L’outil de supervision Microsoft,  génère par défaut une alerte après avoir collecté, 5 fois d’affilé et sur une fréquence de 5 min, une utilisation du processus LSASS excédant 80% du CPU. Du coup si nous voulons reproduire le même comportement, nous devons enregistrer les différentes alertes remontées par notre alerte de performance durant une période précise. Grâce à ce mécanisme, je vais pouvoir démarrer ma collecte après X alertes sur une période de temps T.

 


Configuration du script

Le script est assez simple. Comme nous le disions un peu plus haut, il va contrôler le nombre d’alertes généré durant une certaine période, et si le seuil est atteint, il lancera le collecteur de données « Diagnostics Active Directory ».

Il est disponible depuis le lien Microsoft Technet : Starting Data Collector Set with PowerShell (managing timeline and sampling) (http://gallery.technet.microsoft.com/scriptcenter/Starting-Data-Collect-Set-1efc0013)

Copiez-le dans le répertoire de votre choix et modifiez-le en fonction de vos besoins.

Les paramètres sont :

  • NbSamples : Le nombre d’alertes nécessaire pour le déclenchement de la collecte (valeur par défaut : 5)
  • Duration : La durée de la période en minutes (valeur par défaut : 25)
  • DCSPath : Le nom du collecteur de données (valeur par défaut : « system\Active Directory Diagnostics »)
  • Notify : Activation de la Notification par message électronique. Vous le recevrez si le collecteur est démarré.

 

Si vous activez le paramètre « Notify », il faudra impérativement assigner les bonnes valeurs aux variables suivantes :

  • SmtpServerName : le nom du serveur SMTP
  • SmtpServerPort : le numéro de port du serveur SMTP
  • SmtpEnableSsl : activation du SSL
  • SmtpServerUsername : nom du compte utilisateur pour l’authentification SMTP
  • SmtpServerPassword : mot de passe du compte utilisateur pour l’authentification SMTP
  • SmtpSender : adresse électronique de l’expéditeur
  • SmtpRecipient : adresse électronique de chaque destinataire (si vous comptez ajouter plusieurs expéditeurs alors il faudra ajouter la liste sous forme d’un tableau)

 

Pour votre information, je me suis appuyé sur la configuration de l’alerte SCOM (l’outil de supervision Microsoft) pour définir à quel moment lancer la collecte. En effet, par défaut SCOM est configuré pour déclencher une action après une capture de 5 alertes toutes les 5 minutes.

 

 

Création de la tâche planifiée

La tâche planifiée est nécessaire pour permettre à l’alerte de performance d’interagir avec le script. En tout cas, c’est la seule solution que j’ai trouvée.

Ouvrez le planificateur de tâches et, à l’aide d’un clic droit, sélectionnez « Créer une tâche… ».

 

Entrez un nom pour cette nouvelle tâche (évitez les espaces) et, éventuellement, une description. Au niveau des options de sécurité, vous pouvez utiliser le compte « Système » et spécifier « Exécuter avec les autorisations maximales ».

 

Par contre, nous ne définirons aucun déclencheur. En effet, le déclenchement de la tâche sera réalisé par l’alerte de performance que nous configurons plus tard.

 

Depuis l’onglet « Actions », cliquez sur le bouton « Nouveau… ».

Pour la définition de la nouvelle action :

  • Action : «  Démarrer un programme »
  • Programme/Script : « powershell.exe »
  • Ajouter des arguments (facultatif) : « -ExecutionPolicy Unrestricted –Command ‘CHEMIN_DU_SCRIPT’ –Notify »

{gallery}88_DCSAD_AUTO/01{/gallery}

 

 

 

 

 

 

 

 

 

Au niveau des autres paramètres, je vous conseillerai à minima de définir  le paramètre « Arrêter la tâche si elle s’exécute plus de » à la valeur « 1 heure ».

 

 

Création de l’alerte de performance

Nous allons maintenant utiliser une alerte de performance en guise de déclencheur pour notre tâche. Notre alerte s’appuiera sur la consommation en processeur du processus LSASS.

Pour cela, il faut passer par la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Pour créer notre alerte, naviguez jusqu’à « Ensembles de collecteurs de données » et à l’aide d’un clic droit sur « Définis par l’utilisateur », sélectionnez « Nouveau >  Ensemble de collecteurs de données ».

 

Spécifiez le nom de votre alerte de performance. En l’occurrence, j’ai choisi « Alerte Processus LSASS ». Sélectionnez l’option « Créer manuellement (avancé) » et cliquez sur le bouton « Suivant ».

 

Le type de de données à inclure sera « Alerte de compteur de performance ».

 

A l’étape suivante, cliquez sur le bouton « Ajouter… ».

 

Sélectionner le compteur « % temps processeur » sur l’ordinateur local et spécifiez l’instance « lsass ». Cliquez le bouton « Ajouter >> » puis validez.

 

Nous définissons le seuil d’alerte « Au-dessus de 80 ».

 

Notre collecteur de données incluant notre alerte de performance est désormais créée. Il nous reste à préciser l’action à réaliser lorsque que l’alerte est déclenchée. Pour cela, nous allons éditer l’alerte « DataCollector01 » située à l’intérieur de notre de collecteur de données « Alerte Processus LSASS » en cliquant sur « Propriétés » à l’aide d’un clic droit.

 

Depuis l’onglet « Alertes », modifiez la valeur de l’intervalle d’échantillonnage à « 5 Minutes ».

 

Depuis l’onglet « Tâche d’alerte », spécifiez le nom de la tâche planifiée dans le champ « Exécuter cette tâche lorsqu’une alerte est déclenchée : ».

 

La dernière et ultime étape cruciale est le démarrage de la collecte de données pour votre alerte de performance. En effet, il faut que le collecteur soit démarré. Pour cela, fait un clic droit sur votre collecteur de données et sélectionnez l’option « Démarrer ».

 

 

Conclusion

Désormais, en cas de charge prolongé du processus LSASS et en fonction du paramétrage que vous aurez spécifié, le collecteur de données « Diagnostics Active Directory » va se déclencher automatiquement et générer un rapport de performance.

Vous serez désormais en mesure de détecter la cause de vos problèmes de performance !

Gérer automatiquement le mot de passe administrateur DSRM à partir de Windows Server 2008

Sommaire

 

 

Introduction

Nous allons voir dans cet article comment gérer de manière centralisée le mot de passe du mode DSRM sur l’ensemble de vos contrôleurs de domaine à partir de Windows Server 2008.

Cet article fait écho à l’article de l’équipe Ask the Directory Services Team suivant : http://blogs.technet.com/b/askds/archive/2009/03/11/ds-restore-mode-password-maintenance.aspx.

 


Qu’est-ce que le mot de passe administrateur DSRM ?

Le mode DSRM (Directory Services Restore Mode) est un mode de démarrage disponible sur vos contrôleurs de domaine afin de réaliser une restauration Active Directory. Il est accessible depuis les options de démarrage avancées (menu disponible au démarrage du serveur à l’aide de la touche « F8 »).

{gallery}71_DSRMPWD/01{/gallery}

 

 

 

 

 

 

 

Lorsque vous démarrez sur un contrôleur de domaine avec le « mode de restauration des services d’annuaire », l’état du contrôleur de domaine ne permet pas de se connecter avec un compte du domaine. Sachant qu’un contrôleur de domaine ne dispose pas d’une base locale de comptes, il faut donc passer par un compte spécifique, une sorte de compte administrateur local pour les contrôleurs de domaine. D’ailleurs, lors de la promotion d’un serveur en tant que nouveau contrôleur de domaine, l’assistant de promotion vous propose de définir le mot de passe DSRM.

{gallery}71_DSRMPWD/02{/gallery}

 

 

 

 

 

 


 

 

Il faut donc que les personnes responsables de la promotion de nouveaux contrôleurs de domaine aient connaissance du mot de passe à définir. Afin d’éviter cela, il est également possible de passer par un fichier de réponse mais là encore le mot de passe DSRM sera stocké en clair.

L’outil en ligne de commande NTDSUTIL permet également de modifier le mot de passe DSRM.

 

Du coup, vous pourriez définir facilement le mot de passe DSRM et à intervalle régulier grâce à un script sur tous les contrôleurs de domaine. Toutefois, là encore, le problème du stockage du mot de passe va poser problème.

 

 

 

Utilisation d’un compte de domaine pour définir le mot de passe administrateur DSRM

Dès Windows Server 2008 et avec l’application du hotfix KB961320 (http://support.microsoft.com/kb/961320), NTDSUTIL permet d’être défini à partir d’un compte utilisateur du domaine. Il suffit simplement de spécifié « SYNC FROM DOMAIN ACCOUNT <mon compte> » lorsque NTDSUTIL nous demande de redéfinir le mot de passe administrateur DSRM.

Par exemple, sur votre annuaire Active Directory, créez un compte utilisateur « Administrateur DSRM » avec comme nom d’ouverture de session « adminDSRM ».

{gallery}71_DSRMPWD/04{/gallery}

 

 

 

 


Ouvrez ensuite une invite de commandes et tapez les commandes suivantes :

  • ntdsutil
  • Set DSRM Password
  • Sync from domain account adminDSRM
  • q
  • q

 

Le mot de passe administrateur DSRM est désormais défini sans avoir à le connaitre en spécifiant tout simplement le compte de domaine vers lequel se synchroniser. Par contre, il ne s’agit que d’une synchronisation sur demande. Du coup, si vous changez le mot de passe du compte du domaine, le mot de passe administrateur DSRM ne sera pas synchroniser automatiquement.

 

 

Synchroniser automatiquement le mot de passe administrateur DSRM

Afin de garantir que le mot de passe administrateur DSRM sur chaque contrôleur de domaine et identique à votre compte utilisateur du domaine l’idéal sera de lancer de manière automatique et à intervalle régulier la commande NTDSUTIL « sync from domain account … ».

Pour cela, nous allons déployé une tâche planifiée via une stratégie de groupe.

Commençons par ouvrir la console « Gestion de stratégie de groupe » en lançant la commande « gpmc.msc » depuis « Démarrer | Exécuter ».

 

Nous allons créer la nouvelle stratégie de groupe « Synchronisation du mot de passe DSRM » et la lier directement au conteneur « Domain Controllers ». Pour cela fait un clic droit sur le conteneur et sélectionnez « Créer un objet GPO dans ce domaine, le lier ici… ».

{gallery}71_DSRMPWD/07{/gallery}

 

 

 

 

 

 

 

La GPO étant créée, faites un clic droit dessus et sélectionnez « Modifier… » pour accéder à la console « Editeur de gestion des stratégies de groupe ».

{gallery}71_DSRMPWD/08{/gallery}

 

 

 


 

 

Naviguez ensuite vers « Configuration ordinateur | Préférences | Tâches planifiées » et, l’aide d’un clic droit sur « Tâches planifiées », choisissez « Nouveau => Tâche planifiée ».

{gallery}71_DSRMPWD/09{/gallery}

 

 


 

 

 

 

 

Dans les propriétés de la tâche planifiée :

  • Choisissez l’action « Mettre à jour »
  • Donnez-lui un nom
  • Spécifiez le chemin d’accès « %systemRoot%\system32\ntdsutil.exe » dans le champ « Exécuter »
  • Ajouter les arguments suivant : « « SET DSRM PASSWORD » « SYNC FROM DOMAIN ACCOUNT adminDSRM » Q Q »

{gallery}71_DSRMPWD/10{/gallery}

 

 

 

 

 

 

 

 

 

Depuis l’onglet « Planifier », définissez l’intervalle d’exécution qui vous conviendra le mieux.

{gallery}71_DSRMPWD/11{/gallery}

 

 

 

 

 

 

 

 

 

 

Pour aller plus loin…

Pour les quelques idées à développer… vous avez, par exemple, la possibilité de dédier un compte de domaine pour les RODC et les RWDC ou empêcher l’ouverture de session interactive pour ces comptes de domaine.

Autre point intéressant sera de mettre un filtre WMI sur votre GPO ou activer le « ciblage au niveau de l’élément » au sein même de la GPP pour exclure les éventuels contrôleurs de domaine encore en version Windows Server 2003.

 

How to Find Active Directory Schema Update History by Using PowerShell

Migrer un serveur DHCP Windows Server 2003 vers Windows Server 2008

Sommaire

 

 

Introduction

Dans cet article nous allons voir comment migrer votre base de données DHCP d’un serveur Windows Server 2003 vers un serveur Windows Server 2008. L’article concerne également les versions R2 de 2003 et 2008.

La migration présentée dans cet article s’appuie exclusivement sur l’outil en ligne de commande NETSH. Il existe également l’outil « Server Migration Tools » pour mener à bien cette opération de migration cependant la procédure est plus longue à mettre en œuvre pour un résultat équivalent (pour plus d’information voir l’article Technet « Guide de migration du serveur DHCP »).

Il est évident qu’avant de pouvoir importer la base DHCP de votre serveur Windows 2003 sur votre serveur Windows Server 2008, vous devez installer le rôle « Serveur DHCP » sur votre machine de destination Windows Server 2008.

Ouvrez la console « Gestionnaire de serveur », faites un clic droit sur le nœud « Rôles » et sélectionnez « Ajouter des rôles ».

{gallery}68_DHCPMIG_0308/01{/gallery}

 

 

 

 

 

 


Choisissez le rôle « Serveur DHCP » et cliquez sur le bouton « Suivant ».

{gallery}68_DHCPMIG_0308/02{/gallery}

 

 

 

 

 

 


Définissez les connexions réseau sur lesquelles votre serveur traitera les demandes des clients DHCP.

{gallery}68_DHCPMIG_0308/03{/gallery}

 

 

 

 

 

 


Précisez le suffixe de votre domaine DNS ainsi que vos serveurs DNS et vos serveurs WINS si nécessaire.

{gallery}68_DHCPMIG_0308/04{/gallery}

 

 

 


 

 


A l’étape suivante, ne spécifiez aucune étendue DHCP sachant que nous allons importer celles de votre serveur Windows Server 2003.

{gallery}68_DHCPMIG_0308/05{/gallery}

 

 

 

 

 

 


Si vous le désirez, vous pouvez également configurer le mode DHCPv6.

{gallery}68_DHCPMIG_0308/06{/gallery}

 

 

 

 

 

 


Lancez l’installation en cliquant sur le bouton « Installer ».

{gallery}68_DHCPMIG_0308/07{/gallery}

 

 

 

 

 


 

 

 

Exportation de la base de données DHCP depuis le serveur Windows Server 2003

Pour les besoins de l’article, nous avons créé un serveur DHCP sur un serveur Windows Server 2003 avec une étendue, une exclusion, des options… dont vous voyez le détail ci-dessous.

{gallery}68_DHCPMIG_0308/08{/gallery}

 

 

 

 

 

 


L’exportation de la base de données DHCP est d’une simplicité enfantine. Il vous suffit d’ouvrir un invite de commandes et d’entrer la commande « netsh dhcp server export c:\temp\DHCP-Export.txt 192.168.0.0 ».

Bien entendu, il faudra remplacer l’étendue « 192.168.0.0 » par celles de votre serveur DHCP ( à la suite les unes des autres si vous en avez plusieurs).

{gallery}68_DHCPMIG_0308/09{/gallery}

 

 

 

 


ATTENTION !!! Si vous utilisez le paramètre « All » à la place de la liste des étendues, cela peut générer l’erreur « Erreur lors de l’importation de la classe ‘Classe de routage et d’accès distant par défaut’ ».

{gallery}68_DHCPMIG_0308/10{/gallery}

 

 

 

 

 


 

Importation de la base de données DHCP sur le serveur Windows Server 2008

L’importation de la base de données DHCP est aussi simple que l’exportation réalisée préalablement.

Récupérez la base de données DHCP exportée sur votre serveur Windows Server 2008 et lancez la commande « netsh dhcp server import c:\temp\DHCP-Export.txt all ».

{gallery}68_DHCPMIG_0308/11{/gallery}

 

 

 

 

 

Une fois l’importation réalisée, ouvrez la console « DHCP » depuis « Démarrer » | « Outils d’administration » et vérifiez que l’ensemble des informations a été correctement importé.

{gallery}68_DHCPMIG_0308/12{/gallery}

 

 

 

 

 

 

 

 

 

Opérations post-migration

La dernière étape de la migration de notre serveur DHCP consiste à désactiver la ou les étendues sur le serveur Windows Server 2003 à l’aide d’un clic droit sur chaque étendue et en sélectionnant l’option « Désactiver ».

{gallery}68_DHCPMIG_0308/13{/gallery}

 

 

 

 

 


 

Autorisez ensuite le serveur DHCP sur le Windows Server 2008 en réalisant un clic droit sur le nœud racine du serveur et en sélectionnant l’option « Autoriser » (dans un environnement Active Directory, vous devrez être administrateurs de l’entreprise).

{gallery}68_DHCPMIG_0308/14{/gallery}

 

 

 

 

 

 

Vous pouvez valider la migration en faisant des tests de renouvellement de baux DHCP sur vos postes clients à l’aide de la commande « ipconfig /renew ». N’oubliez pas également de supprimer les étendues inactives sur votre serveur source.

 

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Le centre d’administration Active Directory (ADAC)

Sommaire

 

 

Introduction

Avec Windows Server 2008 R2, une nouvelle console de gestion Active Directory appelée « Centre d’Administration Active Directory » (Active Directory Administrative Center – ADAC) est apparue. Elle tend clairement à remplacer la fameuse mais non moins vieillissante console Utilisateurs et ordinateurs Active Directory (ADUC). En réalité, son apparition marque clairement le désir de Microsoft de pousser ADUC vers la sortie.

Sachant que cette nouvelle console risque de devenir incontournable d’ici peu, de part ses évolutions actuelles et futures, nous allons vous présenter dans cet article tout ce que vous devez savoir sur ADAC et comment l’appréhender.

 

 

Pourquoi remplacer ADUC ?

La console Utilisateurs et ordinateurs Active Directory est apparue voila plus de 11 ans avec la naissance d’Active Directory et Microsoft Windows Server 2000. Elle a très peu évolué et ne répond plus désormais aux besoins en termes d’efficacité, de fonctionnalité et de flexibilité.

ADAC s’appuie exclusivement sur PowerShell et plus particulièrement sur le module Active Directory apparu avec Windows Server 2008 R2. Cela sera sans doute la force majeure d’ADAC et de son évolution dans les prochaines années.

Bien entendu, la console n’en est qu’à ses premiers balbutiements, elle est loin d’être sans défauts et faiblesses. De plus, la console Utilisateurs et ordinateurs Active Directory reste toujours d’actualité parce qu’un grand nombre de composants tiers ne sont pas encore compatibles avec ADAC.

 

 

Prérequis

La console est construite autour de Powershell et de son module Active Directory. Elle est donc incompatible avec les systèmes antérieurs à Windows Server 2008 R2 ou Windows 7.  En effet, les cmdlets Active Directory ne peuvent être installées que sur ces versions.

Pour disposer de la console sous Windows Server 2008 R2, nous allons ouvrir la console « Gestionnaire de serveur » en exécutant « servermanager.msc » et sélectionner « Ajouter des fonctionnalités ». Il suffit ensuite de cocher les fonctionnalités « Centre d’administration Active Directory » et « Module Active Directory pour Windows PowerShell » depuis « Outils d’administration de serveur distant » | « Outils AD DS et AD LDS ».

{gallery}35_ADAC/01{/gallery}

 

 

 

 

 

 

 

Remarque : ces fonctionnalités sont installées automatiquement lors de l’installation du service d’annuaire Active Directory (AD DS).

Pour Windows 7, il faut passer par le RSAT (Remote Server Administrative Tools). Une fois installé, ouvrez le gestionnaire de fonctionnalités de Windows depuis « Panneau de configuration » | « Programmes » | « Activer ou désactiver des fonctionnalités Windows ». Activez les fonctionnalités « Le module Active Directory pour Windows PowerShell » et « Centre d’administration Active Directory » depuis « Outils d’administration de rôles » | « Outils AD DS et AD LDS ».

{gallery}35_ADAC/02{/gallery}

 

 

 

 

 

 

 

 

Pour communiquer avec le service d’annuaire, ADAC exige également de disposer des services web Active Directory (en anglais Active Directory Web Services ou ADWS) sur chaque contrôleur susceptible d’en traiter les requêtes. ADWS est installé par défaut sur tout contrôleur de domaine sous Windows Server 2008 R2. Il est toutefois possible d’installer ce service sur des serveurs en version 2003 ou 2008 (voir article sur le sujet Le service web Active Directory (ADWS)).

Le client ADAC envoie des requêtes PowerShell à un contrôleur de domaine disposant du service ADWS sur le port 9389, qui interrogera directement la base LDAP d’active directory sur le port 389 ou le catalogue global sur le port 3268.

{gallery}35_ADAC/03{/gallery}

 

 

 

 

 

 

Découverte de la console

Nous allons dans un premier temps lancer la console soit à partir du menu « Démarrer » | « Outils d’administration » | « Centre d’administration Active Directory », soit simplement en exécutant la commande « dsac.exe » depuis « Démarrer » | « Exécuter… ».

{gallery}35_ADAC/04{/gallery}

 

 

 

 

 

 

 

 

Lors de son lancement, ADAC recherche le premier contrôleur de domaine disponible associé à votre site Active Directory et disposant de ADWS (ou Active Directory Management Gateway Service). Bien entendu, si vous ne disposez pas de contrôleur de domaine exécutant ADWS sur le site concerné alors la console tentera d’en rechercher un sur l’ensemble du domaine.

Dans le cas donc où la console ne trouvera pas un contrôleur de domaine avec ADWS alors la console généra l’erreur « Impossible de trouver un serveur disponible dans le domaine [MONDOMAINE] qui exécute les services Web Active Directory ».

{gallery}35_ADAC/05{/gallery}

 

 

 

 

Remarque : En réalité et comme nous vous l’avons présenté dans notre section précédente, c’est bien PowerShell qui exige l’utilisation de ADWS pour pouvoir communiquer avec l’annuaire Active Directory.

D’un point de vue visuel, la console ADAC respecte les standards graphiques des autres consoles d’administration déjà présentes sur Windows Server 2008:

  • Une partie consacrée à la navigation au sein de l’arborescence.
  • Une partie centrale pour la visualisation et la recherche d’objets.
  • Une partie listant l’ensemble des actions possibles.

{gallery}35_ADAC/06{/gallery}

 

 

 

 

 

 

Lors de la première exécution de la console, nous arrivons automatiquement en page centrale  sur « Vue d’ensemble » permettant de réaliser certaines actions spécifiques et considérées comme les plus routinières par Microsoft.

{gallery}35_ADAC/07{/gallery}

 

 

 

 

 

 

 

 

La navigation

La partie de gauche relative à la navigation est une des évolutions majeures et un des grands intérêts de la console ADAC. Il est possible de visualiser une liste personnalisée !

{gallery}35_ADAC/08{/gallery}

 

 

 

 

 

 

 

Cette liste personnalisée peut regrouper tout conteneur désiré (unités d’organisation ou domaines) en fonction de vos usages. Chaque élément ajouté, appelé « nœud de navigation », n’est autre qu’un simple raccourci. En clair, plutôt que de naviguer constamment au sein de l’arborescence d’une OU à une autre, il vous est possible de passer en un simple clic de l’une à l’autre. Cela représente un gain de temps non négligeable.

Pour ajouter un nœud de navigation, il suffit donc simplement de sélectionner le conteneur que vous voulez rajouter dans la liste et de cliquer sur le bouton « >> ». Vous pouvez répéter l’opération autant de fois que vous le jugerez nécessaire. Un fois les nœuds de navigation ajoutés, ils sont désormais accessible depuis l’affichage « Liste ».

{gallery}35_ADAC/09{/gallery}

 

 

 

 

 

 

 

 

Vous pouvez également réorganiser la liste à tout moment à l’aide d’un clic droit sur un nœud de navigation afin d’en modifier l’ordre, le renommer, le dupliquer ou le supprimer.

{gallery}35_ADAC/10{/gallery}

 

 

 

 

 

 

 

Autre fonctionnalité intéressante introduite avec ADAC est la possibilité de pouvoir se connecter à plusieurs domaines simultanément depuis la console et à l’aide de l’option « Se connecter à d’autres domaines… » situé dans le coin inférieur droit de la fenêtre « Ajouter des nœuds de navigation ». Vous pouvez donc créer des nœuds de navigation pointant sur des conteneurs présents sur différents domaines. Dans l’exemple ci-dessus, nous avons créé deux nœuds de navigation pointant directement sur le domaine contoso et emea alors que le nœud de navigation de notre domaine par défaut est identifiable par le suffixe « (local) ».

{gallery}35_ADAC/11{/gallery}

 

 

 

 

 

Remarque : le domaine par défaut sur lequel se connecte ADAC est celui du compte utilisateur utilisé (visualisable sur la partie inférieure gauche de la console) pour l’exécution de la console.

Seul petit regret reste l’impossibilité de préciser des informations d’identification spécifiques pour chaque domaine ajouté. Notez également qu’il faudra disposer impérativement d’une relation d’approbation entre les différents domaines afin de pouvoir s’y connecter.

 

Vous pouvez également profiter du MRU (Most Recently Used) qui permet tout simplement d’afficher les trois derniers conteneurs parcourus sous chacun de vos nœuds de navigation.

{gallery}35_ADAC/12{/gallery}

 

 

 

 

 

Enfin, vous pouvez également utiliser la barre de navigation pour parcourir l’arborescence ou tout simplement obtenir le chemin ldap d’un conteneur.

{gallery}35_ADAC/13{/gallery}

 

 

 

 

 

La recherche et le filtrage

La recherche d’objets est également particulièrement intéressante sur ADAC. Elle est accessible depuis la partie navigation « Recherche globale » ou sur chaque conteneur depuis la partie « Tâches » | « Recherche sous ce nœud ».

{gallery}35_ADAC/14{/gallery}

 

 

 

 

 

 

Premier point fort est qu’il est désormais possible de réaliser une recherche sur plusieurs nœuds en même temps. Depuis la fonction « Recherche globale », il suffit simplement de sélectionner depuis la liste déroulante « Etendue » la liste des nœuds de navigation qui feront l’objet de notre recherche.

{gallery}35_ADAC/15{/gallery}

 

 

 

 

 

 

Remarque : vous pouvez également interroger directement le catalogue global depuis le menu déroulant « Etendue ».

ADAC simplifie aussi la gestion des critères de recherche et l’usage de requêtes LDAP. Les recherches accessibles depuis le champ « Recherche » peuvent s’appuyer ou simplement être complétées  par des critères de recherche proposés par défaut via « Ajouter des critères ».

{gallery}35_ADAC/16{/gallery}

 

 

 

 

 

 

ADAC permet de convertir vos recherches au format LDAP afin de mieux appréhender ce langage et d’améliorer vos requêtes. Il suffit pour cela de sélectionner l’option « Convertir en LDAP ».

{gallery}35_ADAC/17{/gallery}

 

 

 

 

Vous pouvez enfin sauvegarder vos requêtes (couplant plus critères par exemple) et y accéder par la suite depuis le bouton « Requêtes ».

{gallery}35_ADAC/18{/gallery}

 

 

 

 

 

 

 

 

Remarque : les requêtes converties en LDAP et modifiées ne peuvent pas être enregistrées.

 

La notion de filtrage est aussi introduite dans ADAC afin de simplifier la localisation de l’information. Vous noterez d’ailleurs avec l’usage que ces fonctions de filtrage se retrouvent un peu partout au sein d’ADAC. La plus visible étant celle disponible dans la partie visualisation et permettant de repérer rapidement les objets voulus au sein d’un conteneur. Le filtrage dans la partie visualisation dispose de l’ensemble des fonctionnalités disponible dans « Recherche globale » (hormis la conversion LDAP).

{gallery}35_ADAC/19{/gallery}

 

 

 

 

 

La consultation

Sur ADAC, la consultation des objets se veut plus efficace. Cela passe en particulier par le regroupement de l’ensemble des attributs d’un objet sur une même et seule fenêtre. L’usage des onglets sur ADUC a donc été en partie délaissé. Pour visualiser donc les propriétés d’un objet, il suffit de double cliquer sur l’objet concerné ou de sélectionner « Propriétés » à l’aide d’un clic droit.

{gallery}35_ADAC/20{/gallery}

 

 

 

 

 

 

 

Comme vous pouvez le voir ci-dessous, tout est fait pour vous permettre de consulter rapidement les informations nécessaires (gestion des sections, menu de navigation, consultation des données depuis une seule fenêtre…).

{gallery}35_ADAC/21{/gallery}

 

 

 

 

 

 

Remarque : les onglets restent toujours d’usage pour un ensemble de paramètres depuis la section « Extensions ».

Dernier point d’intérêt surtout si vous utilisiez acctinfo.dll sur ADUC (qui vous permettez de disposer de l’onglet supplémentaire « Additional Account Info » sur les propriétés utilisateur) alors vous serez ravi d’apprendre que la majorité des informations fournies par acctinfo.dll sont désormais disponibles par défaut sur ADAC en cliquant sur la flèche située dans le coin inférieur gauche.

Cela est doublement intéressant sachant que acctinfo.dll n’est plus supporté depuis Windows 2008 R2 et Windows 7 x64 (la version 2 nommé acctinfo2.dll – non supportée mais opérationnelle sur une version US – est disponible ici).

{gallery}35_ADAC/22{/gallery}

 

 

 

 

 

 

 

 

 

 

Conclusion

Nous avons donc vu au sein de cet article tous les possibilités de la nouvelle console de gestion Active Directory. Si vous désirez toutefois approfondir le sujet, nous vous conseillons deux articles depuis le blog « Ask the Directory Services Team »  :

Snapshots AD: Exploiter les clichés instantanés Active Directory

Sommaire

 

Introduction

Créer et gérer vos clichés instantanés de votre base Active Directory n’est que l’étape préalable à leur exploitation que nous allons donc découvrir ensemble. Nous allons surtout vous présenter les différentes possibilités que nous apporte l’outil DSCT couplé à dsamain. Vous devriez être rapidement conquis par cette nouvelle fonctionnalité à la lecture de cet article.

 

Monter vos clichés à l’aide de dsamain

Apparu sous Windows Server 2008, dsamain est l’outil qui va permettre d’exposer les données Active Directory stocké depuis un cliché instantané ou une sauvegarde sous la forme d’un service LDAP afin de l’exploiter à l’aide de différents outils tel que la console « Utilisateur et ordinateur Active Directory ».

Si vous voulez donc explorer un cliché instantané Active Directory, il faudra au préalable créer et monter le cliché instantané à l’aide de ntdsutil  tel que nous l’avons vu dans notre article Snapshot AD: Gérer les clichés instantanés Active Directory.

{gallery}29_ADSNAPSHOT/01{/gallery} 

 

 

 

 

Une fois le cliché monté sous ntdsutil, nous allons exposer la base Active Directory à disposition à l’aide de dsamain. Pour se faire, il suffit de récupérer le chemin de la base ntds.dit en lançant  la commande « dsamain /dbpath {chemin de ntds.dit} /ldapport {port TCP} ». L’option DBPATH permet d’indiquer le chemin de notre fichier ntds.dit (le fichier par défaut de la base Active Directory) et LDAPPORT permet d’indiquer un port TCP spécifique pour pouvoir ensuite s’y connecter. Dans l’exemple ci-dessous, la commande est « dsamain -dbpath C:\$SNAP_201106202257_VOLUMEC$\WINDOWS\NTDS\ntds.dit -ldapport 51389 ».

{gallery}29_ADSNAPSHOT/02{/gallery}

 

 

 

 

 

 

Il peut arriver que vous rencontriez des problèmes lorsque vous essayer d’utiliser dsamain et plus particulièrement l’erreur « 10013 Une tentative d’accès à un socket de manière interdite par ses autorisations d’accès a été tentée ». L’errreur est causée, semble-t-il, par un problème d’allocation de ports et plus particulièrement lorsque vous tenter  d’utiliser l’outil sur un serveur faisant office de serveur DNS. Un simple redémarrage du service « Serveur DNS » devrait y remédier.

{gallery}29_ADSNAPSHOT/03{/gallery}

 

 

 

 

 

 

 

 

Explorer les clichés avec ADUC

Maintenant que notre base Active Directory est montée, nous allons donc l’explorer et pour cela nous allons simplement utiliser l’outil « Utilisateurs et ordinateurs Active Directory ». L’outil sera particulièrement utile lorsque vous aurez une idée claire sur le type d’information que vous recherchez comme un objet supprimé ou modifié. A partir de la console ADUC (Active Directory Users and Computers), faites un clic droit sur la racine et choisissez l’option « Changer de contrôleur de domaine ».

{gallery}29_ADSNAPSHOT/04{/gallery}

 

 

 

 

 

 

Sélectionner l’option « Ce contrôleur de domaine ou cette instance AD LDS » et indiquez l’adresse de votre serveur suivi du port. Dans notre exemple, nous choisissons « LOCALHOST:51389 » sachant que la base est montée avec dsamain sur la même machine.

{gallery}29_ADSNAPSHOT/05{/gallery}

 

 

 

 

 

 

 

Nous pouvons désormais naviguer dans la base montée depuis notre cliché instantané. Ci-dessous, nous voyons un exemple de comparaison entre une base montée depuis un cliché et la base de production. On pourra rapidement savoir à quel moment un compte a été créé et quel jeu de sauvegarde nous pourrons utiliser pour le restaurer par exemple et sans forcément passer par de multiples restaurations.

{gallery}29_ADSNAPSHOT/06{/gallery}

 

 

 

 

 

 

 

 

Une fois que l’objectif a été atteint avec dsamain et ntdsutil, pensez à fermer dsamain à l’aide de la combinaison CTRL+C et de démonter le ou les clichés instantanés à l’aide de la commande « unmount » depuis ntdsutil.

{gallery}29_ADSNAPSHOT/07{/gallery}

 

 

 

 

 

 

 

Présentation de l’outil DSCT

Nous avons vu que nous pouvions exploiter assez facilement notre cliché instantané à l’aide de la console ADUC cependant l’outil ne permet pas différencier efficacement les deux versions de notre base Active Directory n’y de pouvoir réaliser d’actions hormis la visualisation. Il existe cependant un outil nettement plus complet pour visualiser clairement les modifications entre le cliché instantané et la base Active Directory et surtout de pouvoir restaurer des attributs ou objets! L’outil est Directory Service Comparison Tool développé par Fredrik Lindström et est disponible ici. L’outil vous offrira, entre autres, les fonctionnalités suivantes :

  • Visualiser efficacement les différences entre les objets du cliché instantané et de la base Active Directory
  • Restaurer les attributs d’objets
  • Réanimer des objets supprimés
  • Restaurer l’appartenance d’un objet à des groupes ou les membres d’un groupe

L’outil propose également une prise en charge des journaux d’évènements relatifs aux audits Active Directory que nous ne verrons pas dans le cadre de cet article. Cette fonctionnalité permet simplement de lier une action à un évènement à condition d’avoir activer les fonctions d’audit Active Directory. Fredik Lindström présente cette fonctionnalité de manière graphique ici.

 

 

Explorer les clichés avec DSCT

Une fois DSCT téléchargé et installé, nous allons devoir passer par une MMC car l’outil n’est autre qu’un composant logiciel enfichable. Lancez donc « mmc » depuis « Démarrer » | « Exécuter » pour ensuite choisir depuis la MMC « Ajouter/Supprimer un composant logiciel enfichable… » depuis le « Fichier » dans la barre d’outils.

{gallery}29_ADSNAPSHOT/08{/gallery}

 

 

 

 

 

 

 

Dans la liste des composants logiciels enfichables disponibles, vous devriez donc trouver Directory Service Comparison Tool que vous allez ajouter dans votre console.

{gallery}29_ADSNAPSHOT/09{/gallery}

 

 

 

 

 

 

 

Le logiciel enfichable désormais disponible au sein de la console MMC, nous allons donc commencer par nous connecter conjointement à notre base Active Directory et à notre cliché instantané. Il faudra bien entendu et au préalable avoir monté le cliché instantané à l’aide de la commande « mount » depuis ntdsutil et d’initialiser la base à l’aide de dsamain.

Réaliser un clic droit sur « Directory Service Comparison Tool » et choisissez « Datasource Settings… ». Indiquez ensuite dans la partie « Directory Service » le nom ou l’IP d’un de vos contrôleur de domaine dans le champ Host et le nom de la partition « Default Naming Context » pour le champ Naming Context. Précisez ensuite pour la partie Snapshot, le nom d’hôte du serveur exécutant votre cliché instantané sans oublier le port relatif au paramètre LDAPPORT spécifié avec dsamain.

{gallery}29_ADSNAPSHOT/10{/gallery}

 

 

 

 

 

 

 

 

 

L’outil nous propose dans un premier temps et depuis l’onglet « Tree » l’aborescence de notre base Active Directory avec un code couleur permettant intuitivement de repérer les différents objets affectés par une manipulation entre la prise du snapshot et la base Active Directory actuel. Le code couleur étant le suivant :

  • Vert : les objets modifiés
  • Rouge : les objets supprimés
  • Noir : les objets ajoutés
  • Gris : les objets restés en l’état

Quant aux onglets « Modified », « Added » et « Deleted », ils regroupent les informations concernant les différents types de manipulation relatifs aux objets pour plus de clarté.

{gallery}29_ADSNAPSHOT/11{/gallery}

 

 

 

 

 

 

Nous voyons également dans la partie inférieure un récapitulatif de l’objet sélectionné depuis l’onglet « Attributes » afin de déterminer clairement le ou les attributs concernés par une modification. Cela peut s’avérer particulièrement intéressant lorsqu’un objet a été modifié et que l’on veut savoir sur quel attribut porte cette modification. Un deuxième onglet « Auditing » est disponible qui permet de mettre en relation les actions sur l’objet avec les entrées du journal d’évènements.

 

 

Restaurer un objet avec DSCT

Une des fonctionnalités particulièrement intéressante de DSCT est la possibilité de restaurer un objet dans son état antérieur à la date du cliché instantané. La restauration peut se situer au niveau de l’objet lui-même mais également au niveau d’un attribut. Cela offre un atout supplémentaire par rapport à la corbeille Active Directory proposé depuis Windows 2008 R2 qui est capable de restaurer un objet mais certainement pas un attribut.

Remarque: nous verrons dans la suite de notre article la restauration d’un attribut.

Pour restaurer un objet, il suffit simplement de se placer sur l’objet supprimé (code couleur rouge), et de sélectionner depuis le volet « Actions » placé sur la droite, l’option « Reanimate ». Après une demande de confirmation, notre objet est restauré dans son conteneur d’origine !

{gallery}29_ADSNAPSHOT/12{/gallery}

 

 

 

 

 

 

Une fois l’objet réanimé, ses appartenances aux groupes ne le sont pas. Il est nécessaire de passer par une étape supplémentaire par le biais de l’option « restore group membership… » depuis le volet « Actions ». Nous obtenons dès lors la liste des groupes anciennement liés à l’objet concerné et qu’il faudra sélectionner pour en restaurer l’appartenance.

{gallery}29_ADSNAPSHOT/13{/gallery}

 

 

 

 

 

 

Remarque: un objet restauré via DSCT est désactivé par défaut.

 

 

Restaurer un attribut avec DSCT

Restaurer un attribut avec DSCT est une opération simple à réaliser. Il suffit dans un premier temps de se placer sur l’objet qui sera assujetti à une restauration d’un de ses attributs. L’objet doit être détecté au préalable comme modifié par DSCT (code coleur vert). Une fois placé sur l’objet, il faudra cocher depuis l’onglet « Attributes » le ou les attributs à restaurer.

{gallery}29_ADSNAPSHOT/16{/gallery}

 

 

 

 

 

 

Une fois les attributs sélectionnés, nous allons cliquer  sur « Restore attribute values… » depuis le volet « Actions » placé à droite.

{gallery}29_ADSNAPSHOT/17{/gallery}

 

 

 

 

 

Après une demande de confirmation, nous obtenons la liste des attributs restaurés.

{gallery}29_ADSNAPSHOT/18{/gallery}

 

 

 

 

 

 

 

Restaurer un groupe avec DSCT

Lorsqu’un groupe est supprimé et qu’il est réanimé via DSCT, il est possible également d’en restaurer ses membres cependant le processus est un peu plus compliqué. En effet, un groupe réanimé ne dispose plus de ses membres et pour les récupérer il est nécessaire de restaurer l’attribut « member ». Malheureusement, lorsqu’un groupe est réanimé, l’attribut member étant null, il n’apparait pas dans DSCT. Il faut donc au préalable y ajouter un membre quelconque pour ensuite restaurer l’attribut « member ».

Prenons l’exemple du groupe « IT_Support » comprenant deux utilisateurs et que nous supprimons. Une fois l’objet réanimé, le groupe ne contient plus de membre et l’objet au sein de DSCT ne dispose pas de l’attribut « member ».

{gallery}29_ADSNAPSHOT/14{/gallery}

 

 

 

 

 

 

 

 

Afin de pouvoir restaurer les membres du groupe « IT_Support », nous allons devoir préalablement rajouter un membre, en l’occurrence le compte « Administrateur », pour que nous puissions avoir la possibilité de sélectionner l’attribut « member » du groupe « IT_Support » depuis DSCT et de restaurer cet attribut à l’aide de « Restore attribute values… ». Nous pouvons constater que les membres initiaux du groupe « IT_Support » ont été finalement restauré.

{gallery}29_ADSNAPSHOT/15{/gallery}

 

 

 

 

 

 

 

 

 

Conclusion

Nous avons donc vu ensemble dans le cadre de cet article comment explorer une base Active Directory depuis un cliché instantané ou une sauvegarde à l’aide de différents outils et en particulier DSCT, produit non estampillé Microsoft mais qui n’a pas d’équivalence entre son ergonomie et ses fonctionnalités.

Les clichés instantanés Active Directory sont encore trop méconnus des administrateurs mais devraient se démocratiser en vu de la réelle plus-value qu’ils apportent… sans les contraintes !

Snapshots AD: Gérer les clichés instantanés Active Directory

Sommaire

 

 

Introduction

Une des nouveautés introduites avec Active Directory sous Windows 2008 est la possibilité de gérer les clichés instantanés de votre base Active Directory. Ces derniers permettront en clair de disposer de plusieurs versions de votre base Active Directory et de pouvoir les exploiter rapidement pour divers besoins d’administration comme l’exploration ou la restauration.

Réelle avancée d’un premier abord, la nouveauté est toute relative car cette amélioration se situe principalement au niveau de l’outil ntdsutil et de l’apparition de dsamain. La fonctionnalité exploite principalement la technologie Volume Shadow Copy Service apparue dès les versions de Windows Server 2003 (vous pouvez consulter notre article relatif à ce sujet: Les clichés instantanés de dossiers partagés sous Windows 2008). Cependant cela n’en rend pas moins intéressant le sujet que nous vous proposons donc de découvrir ensemble.

Nous verrons dans ce premier article les moyens de gérer les clichés instantanés Active Directory pour ensuite nous consacrer dans notre second article Snapshot AD: Exploiter les clichés instantanés Active Directory à leur exploitation.

 

 

Pourquoi utiliser les clichés instantanés Active Directory ?

Réaliser des clichés instantanés de votre base Active Directory va vous apporter plusieurs avantages non négligeables :

  • Réaliser de façon régulière plusieurs points de sauvegarde de votre base Active Directory grâce à la faible consommation de ressources que les clichés génèrent et leur rapidité d’exécution.
  • Consolider votre plan de sauvegarde de l’annuaire et disposer d’une solution complémentaire.
  • Explorer à l’aide de la console Utilisateurs et ordinateurs Active Directory ou DSCT (Directory Service Comparison Tool) les clichés réalisés et en observer les différences.
  • Restaurer granulairement des objets ou même des attributs à l’aide de DSCT.

Remarque : les deux derniers points sont traités dans notre second article.

ATTENTION !!! Les clichés instantanés de la base Active Directory ne sont pas une alternative à votre solution de sauvegarde. Ils ne sont qu’un complément.

Concernant les pré-requis, la seule exigence pour exploiter les clichés instantanés Active Directory sera de disposer d’un contrôleur de domaine sous Windows Server 2008. Autre point intéressant est que la fonctionnalité s’appuye exclusivement sur le service Volume Shadow Copy et sur ntdsutil et qu’il n’y a donc aucune exigence particulière relatif au niveau fonctionnel du domaine.

 

 

Gérer les clichés instantanés de votre base Active Directory

Pour réaliser un cliché instantané (ou plus communément appelé snapshot) de la base Active Directory, il faudra passer par l’incontournable ntdsutil depuis un contrôleur de domaine sous Windows Server 2008. Nous allons donc commencer par lancer depuis une invite de commandes « ntdsutil » et saisir la commande « snapshot ».

{gallery}28_ADSNAPSHOT/01{/gallery}

 

 

 

 

 

Remarque : Pour des questions de sécurité, seul les membres du groupe « Administrateurs de l’entreprise » ou « Admins du domaine »  ont la capacité de réaliser un cliché instantané.

Une fois dans le menu « snapshot » de ntdsutil et pour d’obscures raisons, il faut préciser la base Active Directory à activer. En l’occurrence, nous allons donc saisir la commande « activate instance ntds ».

{gallery}28_ADSNAPSHOT/02{/gallery}

 

 

 

 

 

Il ne reste plus qu’à créer notre snapshot à l’aide de la commande « create » pour enfin disposer assez simplement d’un cliché instantané de notre base Active Directory.

{gallery}28_ADSNAPSHOT/03{/gallery}

 

 

 

 

 

Vous pourrez bien sûr répéter l’opération autant de fois que nécessaire sachant que la seule contrainte sera l’espace disponible sur votre disque et le nombre de clichés instantanés que vous voudrez conserver. Il est assez compliqué de l’évaluer car cela dépend de plusieurs critères mais un cliché instantané ne devrait pas dépasser quelques dizaines de méga-octets. En terme de performances, cela n’aura d’effet que durant la création du cliché instantané qui multipliera les entrées/sorties sur le disque stockant la base Active Directory.

Si nous retournons dans le menu « snapshot » de ntdsutil, vous pouvez également lister l’ensemble des snapshots disponibles à l’aide de la commande « list all ». Nous voyons ci-dessous que nous disposons de deux snapshots.

{gallery}28_ADSNAPSHOT/04{/gallery}

 

 

 

 

 

Comme nous l’évoquions précédemment, les clichés instantanés Active Directory s’appuient exclusivement sur le service Volume Shadow Copy déjà présent sur les systèmes Microsoft Windows depuis la version 2003. Nous pouvons le vérifier rapidement à l’aide de l’outil en ligne de commande « vssadmin ». Ouvrez une invite de commande et saisissez la commande « vssadmin list shadows » pour obtenir la liste des clichés instantanés présents et constater que les clichés créés depuis ntdsutil y sont listés.

{gallery}28_ADSNAPSHOT/05{/gallery}

 

 

 

 

 

 

 

Obtenir la liste des clichés instantanés à l’aide de la commande « list all » va nous permettre dans un premier temps de récupérer l’index du cliché à monter pour pouvoir l’exploiter par la suite. En effet, il est nécessaire dans un premier temps de monter un des clichés instantanés pour l’exploiter et pour cela nous allons utiliser la commande « mount {index} » ou « mount {GUID} ». Nous allons monter par exemple le cliché portant l’index 1 en saisissant la commande « mount 1 ».

Remarque : chaque cliché instantané est toujours associé à deux index. Le premier index représente le numéro du jeu de clichés instantanés et le deuxième index concerne l’ID du cliché instantané. Vous pouvez utiliser indifféremment  l’un ou l’autre.

{gallery}28_ADSNAPSHOT/06{/gallery}

 

 

 

 

 

Une fois le cliché monté, nous obtenons en résultat le point de montage qui est en l’occurrence dans notre exemple « C:\$SNAP_201106131831_VOLUMEC$\ » et que nous pouvons visualiser désormais depuis l’explorateur Windows. Cela nous permettra de pouvoir accéder au fichier de la base Active Directory « ntds.dit »  par la suite.

{gallery}28_ADSNAPSHOT/07{/gallery}

 

 

 

 

 

 

Remarque : vous pouvez monter plusieurs clichés simultanément.

Il vous est possible à tout moment de lister les clichés montés à l’aide de la commande « list mounted ». Cela vous permettra de vérifier si un snapshot a été monté et surtout de pouvoir le démonter à l’aide de la commande « umount {index} » après usage. La commande « unmount * » vous permettra de démonter l’ensemble des snapshots.

{gallery}28_ADSNAPSHOT/08{/gallery}

 

 

 

 

 

 

Vous pouvez enfin supprimer soit un snapshot en particulier à l’aide de la commande « delete {index} » soit l’intégralité des snapshots à l’aide de la commande « delete * ».

{gallery}28_ADSNAPSHOT/09{/gallery}

 

 

 

 

 

 

 

Automatiser la création

Remarque: je vous conseille de consulter l’article « Gérer efficacement la création des snapshots AD » (http://www.alexwinner.com/articles/divers/132-snapshotactivedirectory3.html) pour l’automatisation de la création de vos snapshots.

Il n’est pas possible par défaut d’automatiser la création des clichés instantanés Active Directory. La seule option que nous propose Microsoft est de créer une tâche planifiée pour exécuter la commande « ntdsutil snapshot  « activate instance ntds » create » de manière régulière. Le principal désavantage de cette solution est l’absence de gestion d’une rotation. En effet, avec cette solution il ne sera pas possible de définir le nombre de snapshots que vous désirez conserver et donc de supprimer les plus anciens.

Nous vous proposons donc une solution pour palier à cette déficience en passant par un script qui sera lancé régulièrement via le planificateur de tâche.

{codecitation style= »brush: PowerShell; »}

<#

Gestion des clichés instantanés Active Directory (Snapshots AD)

 

Automatisation de la création d’un snapshot et gestion de la rotation.

 

Auteur: Augagneur Alexandre

Date de création: 31/05/2011

#>

 

#Nombre de snapshots à conserver: valeur 0 désactive la rotation

$MaxSnapshots = 14

 

#——————————————————————

#Fonction comparant le nombre de snapshot à conserver par rapport

#à la valeur $MaxSnapshots (n’est pas appelé si la valeur est à 0)

#——————————————————————

function RemoveSnapshots()

{

#liste le nombre de snapshots

$Items = ntdsutil snapshot « activate instance ntds » « list all » quit quit

 

#verifie la présence de snapshots

If ($Items -eq « Captures instantanées introuvables. »)

{

Return

}

 

#applique un filtr et compte le nombre de snapshots

$NumItems= ($Items | where-object {($_ -like « *{*}* ») -and ($_ -like « */*/* »)}).count

 

#Supprime le(s) snapshot(s) le(s) plus ancien(s)

While ($NumItems -ge $MaxSnapshots)

{

ntdsutil snapshot « list all » « delete 1 » quit quit | Out-Null

$NumItems -= 1

}

}

 

#Appel la fonction RemoveSnapshots si la rotation est activée

if ($MaxSnapshots -ne 0)

{

RemoveSnapshots

}

 

ntdsutil snapshot « activate instance ntds » create quit quit | Out-Null

{/codecitation}

Il faudra donc récupérer l’intégralité du code ci-dessus pour l’intégrer dans un fichier ADSnapshots.ps1. La seule variable qui devra être modifiée selon vos convenances sera $MaxSnapshots qui vous permettra d’indiquer le nombre de snapshots que vous voudrez conserver. Le script est assez rudimentaire sans journalisation ni gestion d’exceptions mais devrait pouvoir convenir à la majorité des usages ou du moins vous servir de base pour pouvoir développer votre propre script.

Il sera également nécessaire d’autoriser l’exécution de scripts PowerShell en local sur le serveur. Pour cela taper la commande suivante depuis la console PowerShell : Set-ExecutionPolicy RemoteSigned.

 

 

Active Directory Snapshot Manager

Afin de simplifier la gestion au quotidien des clichés instantanés Active Directory et surtout pour offrir la possibilité de les gérer depuis une interface graphique, nous avons développer un front-end en Powershell. Le script est disponible depuis notre zone de téléchargement et fera sans doute l’objet de différents articles afin de vous montrer comment construire votre interface graphique à l’aide de Powershell.

Le script ne peut être exécuter que sur un contrôleur de domaine Windows Server 2008 ou 2008 R2 et nécessitera de disposer de Powershell 2.0.

A l’aide de ADSM, vous pourrez créer, supprimer ou monter un cliché instantané sur simple clic et même l’exposer en exploitant les fonctionnalités de Dsamain.

{gallery}28_ADSNAPSHOT/10{/gallery}

 

 

 

 

 

 

 

 

 

 

Conclusion

Nous avons donc vu dans un premier temps comment gérer la fonctionnalité des clichés instantanés sous Active Directory et automatiser leur création afin de pouvoir dans un second temps les exploiter. Nous vous invitons donc à poursuivre votre lecture en consultant notre second article Snapshot AD: Exploiter les clichés instantanés Active Directory.

Supprimer un contrôleur de domaine corrompu (Active Directory Metadata Cleanup)

Sommaire

 

 

Introduction

La suppression d’un contrôleur de domaine dans une architecture Active Directory doit absolument passer par une rétrogradation de ce dit contrôleur. Mais que faire s’il n’est plus possible de rétrograder le contrôleur de domaine à l’aide de DCPROMO? Il faudra réaliser manuellement la suppression des métadonnées relatives à ce contrôleur de domaine que l’on appelle donc communément  Metadata cleanup.

Le sujet est très largement traité et dispose d’une documentation déjà très complète comme, par exemple, l’article Technet Clean Up Server Metadata : Active Directory, cependant nous avons toutefois décidé de vous le proposer afin de permettre à tout un chacun de mieux appréhender cette opération qui peut paraître très obscure au premier abord.

Nous verrons donc ensemble les différentes méthodes qui vous permettront de réaliser cette opération, de la plus fastidieuse (méthode manuelle) à la plus efficace (méthode graphique introduite avec Windows 2008). Nous conclurons enfin en fournissant les moyens de post-vérifications possibles pour garantir le succès de l’opération.

 

 

La méthode manuelle: qu’est-ce qu’un Metadata Cleanup ?

Le nettoyage des métadonnées d’un contrôleur de domaine corrompu n’est pas une obligation mais plus que fortement recommandé. Tant que ce contrôleur de domaine n’est pas explicitement supprimer de votre annuaire, il sera soumis inlassablement à des problèmes (essentiellement de réplication), polluant vos journaux d’évènements et même pouvant rendre impossible la réalisation de certaines opérations (par exemple l’augmentation du niveau fonctionnel du domaine ou de la forêt).

Afin de mieux comprendre cette opération, nous allons voir, dans un premier temps, comment réaliser manuellement un nettoyage des métadonnées d’un serveur corrompu. L’opération est plutôt fastidieuse et par forcément très efficace en vue des outils que Microsoft met à notre disposition pour la réaliser cependant elle a une vertu éducative (cette méthode est très largement décrite depuis l’article Complete Step by Step to Remove an Orphaned Domain Controller que je vous conseille de consulter).

Pour mener à bien cette opération, nous allons utiliser exclusivement l’outil ADSI Edit disponible par défaut sur Windows Server 2008 mais qui nécessitera d’être installé sur les versions 2000 et 2003. L’outil est intégré dans Windows Server 2003 Service Pack 2 32-bit Support Tools ou Windows 2000 Service Pack 4 Support Tools que vous devrez télécharger et installer au préalable.

ATTENTION !!! Faites preuve de vigilance avec ADSI Edit car un mauvais usage pourrait entrainer des dommages irréparables sur votre annuaire. Soyez toujours sûr des opérations que vous réalisez… et d’autant plus avec cet outil.

 

Voici donc les actions à mener pour réaliser un Metadata Cleanup manuellement :

  • Saisie des maîtres d’opérations associés au contrôleur de domaine corrompu : Cette action ne fait pas partie à proprement parler de l’opération de Metadata Cleanup mais une partie des outils que nous présentons dans cet article vérifie que le contrôleur à « nettoyer » ne dispose pas de maîtres d’opérations et si nécessaire en force la saisie. Toutefois, il est en général de mise et même nécessaire de lancer la saisie dès que l’on constate l’indisponibilité d’un maître d’opérations. Je vous conseille de consulter pour cela notre article relatif à la saisie des maîtres d’opérations Localiser et déplacer les maîtres d’opérations Active Directory et plus particulièrement le chapitre relatif à la saisie Forcer le déplacement des maîtres d’opérations.
  • Suppression de l’objet NTDS Settings associé au contrôleur de domaine corrompu : L’objet NTDS Settings contient toutes les informations relatives à un contrôleur de domaine au sein de l’annuaire. Chaque contrôleur de domaine se voit donc associé à un objet NTDS Settings lors de sa promotion. Nous devons donc le supprimer ainsi que le conteneur associé. Nous allons commencer par lancer ADSI Edit en saisissant la commande « adsiedit.msc » depuis « Démarrer » | « Exécuter ». Une fois ADSI Edit lancé, réaliser un clic droit sur « Modification ADSI » et choisissez « Connexion… ». Depuis la fenêtre « Paramètres de connexion », sélectionnez le contexte d’attribution « Configuration » comme point de connexion. 

{gallery}27_ADMC/01{/gallery}

 

 

 

 

 

 

 

 

L’objet NTDS Settings est situé dans l’arborescence « CN=Sites » | « CN=[MONSITE] » | « CN=Servers » | « CN=[MONSERVER] » | « CN=NTDS Settings ». Nous allons simplement supprimer le conteneur qui porte le nom du serveur corrompu en réalisant un clic droit sur ce dernier et en choisissant « Supprimer ». Sécurité oblige, par deux reprises, ADSI Edit vous demandera de confirmer votre choix. En effet, selon le type d’objet que vous viendrez à supprimer, cela pourrait entrainer des effets désastreux sur votre annuaire. Soyez donc très vigilant !

{gallery}27_ADMC/02{/gallery}

 

 

 

 

 

 

  • Suppression de l’objet Ordinateur associé au contrôleur de domaine corrompu : Chaque contrôleur de domaine est associé à un objet de type Ordinateur situé dans l’unité d’organisation « Domain Controllers » et accessible depuis la console « Utilisateurs et ordinateurs Active Directory » ou appelé communément ADUC. Nous allons toutefois continuer à utiliser ADSI Edit car sous Windows Server 2008, supprimer l’objet depuis ADUC réalise automatiquement un Metadata Cleanup (Nous verrons cela un peu plus tard).

Depuis ADSI Edit, Accéder donc de nouveau à la fenêtre « Paramètres de connexion » mais cette fois-ci en sélectionnant le contexte d’attribution « Contexte d’attribution de noms par défaut ».  Naviguez jusqu’à L’objet Ordinateur situé dans « OU=Domain Controllers ».

{gallery}27_ADMC/03{/gallery}

 

 

 

 

 

 

 

 

Vous pourrez également vous rendre compte grâce à ADSI Edit et en double cliquant sur votre objet « CN=[MONSERVER] » qu’il est lui-même un conteneur pour les informations relatives à la souscription NTFRS ou DFSR pour la réplication du dossier SYSVOL. Ils sont sous la forme d’un objet « NTFRS-subscriber » ou « msDFSR-Subscriber » (sur un domaine de niveau fonctionnel 2008 avec réplication DFS-R pour le dossier SYSVOL) et permettent de définir l’appartenance d’un contrôleur de domaine à un jeu de réplication spécifique.

{gallery}27_ADMC/04{/gallery}

 

 

 

 

 

 

Comme précédemment, réaliser un clic droit sur votre l’objet « CN=[MONSERVER] » et choisissez l’option « Supprimer ».

{gallery}27_ADMC/05{/gallery}

 

 

 

 

 

 

  • Suppression de l’objet NTFRS-member ou msDFSR-Member associé au contrôleur de domaine corrompu : Un objet de type « NTFRS-member » ou « msDFSR-Member »  (sur un domaine de niveau fonctionnel 2008 avec réplication DFS-R pour le dossier SYSVOL) correspondant au jeu de réplication associé au dossier SYSVOL, doit être également supprimé pour qu’il n’y ait plus de référence à ce contrôleur de domaine dans le cadre de la réplication du dossier SYSVOL. Toujours depuis ADSI Edit et depuis le contexte d’attribution « Contexte d’attribution de noms par défaut », naviguez jusqu’à « CN=System » | « CN=File Replication Service » | « CN=Domain System Volume (SYSVOL share) » ou « CN=System » | « CN=DFSR-GlobalSettings » | « CN=Topology »  selon que vous utilisez du NTFRS ou du DFS-R et supprimez l’entrée correspondante à votre serveur à l’aide d’un clic droit et en sélectionnant « Supprimer ».

{gallery}27_ADMC/06{/gallery}

 

 

 

 

 

 

Nous avons enfin réalisé le Metadata Cleanup. En conclusion, l’opération de nettoyage des métadonnées d’un contrôleur de domaine corrompu n’est pas une opération si complexe une fois décortiquée. Il nécessite simplement la suppression de trois objets.

 

 

La méthode classique par ligne de commande

La méthode historique et la plus communément utilisée depuis l’apparition d’Active Directory est de réaliser l’opération de Metadata Cleanup par le biais de l’outil en ligne de commande Ntdsutil. Ce dernier a évolué avec l’apparition de chaque nouvelle version de Windows Server et s’est simplifié dans le cadre d’un Metadata Cleanup. Cela induit surtout que selon la version de Ntdsutil que vous utiliserez, vous n’aurez pas accès aux mêmes commandes.

En effet, bien qu’il soit désormais peu probable que vous soyez amené un jour à réaliser cette opération sur les versions Windows Server 2000 ou Windows Server 2003 RTM (non service packé), il peut être intéressant de savoir que la méthode est différente par rapport aux versions ultérieures. Sachant que cette section représente donc un intérêt très limité, nous nous contenterons de vous rediriger vers la base de connaissance Microsoft relative à ce sujet How to remove data in Active Directory after an unsuccessful domain controller demotion si vous êtes confronté à ce cas de figure.

Nous allons donc voir comme réaliser l’opération sur une version Windows Server 2003 SP1 ou ultérieure. Commencez par ouvrir une invite de commandes et saisissez « ntdsutil » pour invoquer l’outil. Il est intégré de base dans toutes les versions de Windows Server.

ATTENTION !!! Faites preuve de vigilance avec NTDSUTIL car un mauvais usage pourrait entrainer des dommages irréparables sur votre annuaire. Soyez toujours sûr des opérations que vous réalisez… et d’autant plus avec cet outil.

{gallery}27_ADMC/07{/gallery}

 

 

 

 

 

Une fois Ntdsutil lancé, nous allons exécuter la commande « metadata cleanup ».

{gallery}27_ADMC/08{/gallery}

 

 

 

 

 

Il ne reste plus qu’a saisir la commande « remove selected server [Distinguished Name du serveur à supprimer] on [FQDN du serveur réalisant l’opération] » (Nous donnons plus de détails sur ces deux paramètres ci-dessous).

Remarque: cette commande n’est donc pas accessible sur les versions antérieures à Windows 2003 SP1 tel que nous l’énoncions plus haut. 

Distinguished Name du serveur à supprimer : Il faut indiquer ce que l’on appelle le Distinguished Name du serveur concerné par le Metadata Cleanup qui est situé sur la partition de Configuration d’Active Directory. Si nous prenons l’exemple d’un serveur nommé WIN2003 sur le site Active Directory Default-First-Site-Name sur le domaine CORPNET.NET, nous aurons le Distinguished Name « CN=WIN2003,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=CORPNET,DC=NET ». Pour vous aider à le déterminer, vous pouvez facilement retrouver ces informations depuis la console Sites et services Active Directory ou l’éditeur Adsiedit.

FQDN du serveur réalisant l’opération : ce paramètre est optionnel et permet de préciser depuis quel serveur sera réalisée l’opération. Si vous ne précisez pas cette option alors l’opération sera tout simplement réalisée localement. Pour rappel, le FQDN et le nom DNS complet d’une machine sur un réseau constitué de [Hostname].[DomainName]. Par exemple, si vous nous devions réaliser l’opération sur un contrôleur ayant comme nom d’hôte WIN2008  et avec comme nom de domaine CORPNET.NET alors le FQDN du serveur est WIN2008.CORPNET.NET.

{gallery}27_ADMC/09{/gallery}

 

 

 

 

 

Ntdsutil vous demande de confirmer l’opération et de vous assurer que le serveur est définitivement hors connexion. Selon les cas, le retour d’un contrôleur de domaine ayant fait l’objet d’un Metadata Cleanup peut avoir des effets désastreux sur votre annuaire.

{gallery}27_ADMC/10{/gallery}

 

 

 

 

 

 

Ntdsutil a également la capacité de détecter que le contrôleur de domaine à supprimer hébergait des maîtres d’opérations. Si cela est le cas, il tentera dans un premier temps de les transférer ce qui normalement ne doit jamais fonctionner (le transfert de rôle nécessite la présence sur le réseau du détenteur du ou des maîtres d’opérations) et fera le cas échéant une saisie. Il est préférable de réaliser l’opération de saisie des rôles au préalable tel que nous le disions en première partie. 

{gallery}27_ADMC/11{/gallery}

 

 

 

 

 

Ntdsutil liste les opérations qu’il réalise durant le Metadata Cleanup et nous pouvons nous rendre compte qu’il ne procède pas différemment  de la méthode manuelle que nous avons vue en première partie. Il supprime le contrôleur de domaine en tant que membre FRS pour le dossier SYSVOL, l’objet Ordinateur et l’objet NTDS Settings.

{gallery}27_ADMC/12{/gallery}

 

 

 

 

 

Vous pouvez ensuite fermer Ntdsutil en saisissant par deux fois la commande  « quit ».

Il faudra toutefois réaliser encore la suppression de l’objet Server depuis la console Sites et Services Active Directory qui n’est certes pas d’une absolue nécessité mais sans doute plus propre.

{gallery}27_ADMC/13{/gallery}

 

 

 

 

 

 

 

 

La méthode introduite avec Windows 2008 : La console Utilisateurs et ordinateurs Active Directory

Depuis l’apparition des dernières versions des consoles Utilisateurs et ordinateurs Active Directory et Sites et Services Active Directory introduites avec Windows Server 2008 et également disponibles avec RSAT (Microsoft Remote Server Administration Tools), la procédure Metadata Cleanup s’est réellement simplifiée car il suffit simplement de supprimer l’objet associé à votre ancien contrôleur de domaine pour que le nettoyage de ses métadonnées soit réalisé.

En passant simplement par la mmc « Utilisateurs et Ordinateurs Active Directory », sélectionnez l’objet associé au contrôleur de domaine concerné par le Metadata Cleanup depuis le conteneur « Domain controllers » et sélectionner à l’aide d’un clic droit l’option « Supprimer ». Confirmez ensuite la demande de suppression.

{gallery}27_ADMC/14{/gallery}

 

 

 

 

 

 

La demande de suppression détecte que l’objet concerné est un contrôleur de domaine et vous invite à réaliser une rétrogradation à l’aide de l’assistant d’installation Active Directory (DCPROMO). Sachant qu’il nous est impossible d’exécuter l’assistant sur ce dit contrôleur, nous cochons la case « Ce contrôleur de domaine est définitivement hors connexion… ».

{gallery}27_ADMC/15{/gallery}

 

 

 

 

 

La méthode par interface graphique détecte également la présence d’un maître d’opérations ou de la fonction catalogue global (pour plus d’information sur le catalogue global, rendez-vous sur l’article Le catalogue global Active Directory). Il vous propose donc de forcer leur déplacement sur le serveur où est exécutée l’opération de Metadata Cleanup.

{gallery}27_ADMC/16{/gallery}

 

 

 

 

 

 

Pour finaliser l’opération de suppression, lancez à présent la console « Sites et services Active Directory » et supprimer l’objet de votre ancien contrôleur de domaine depuis le site concerné. En l’occurrence, sur l’exemple ci-dessous, il s’agit du site « Default-First-Site-Name ».

{gallery}27_ADMC/17{/gallery}

 

 

 

 

 

 

 

 

 

La méthode introduite avec Windows 2008 : La console Sites et services Active Directory

Comme nous le disions précédemment, il est également possible de réaliser le Metadata Cleanup depuis la console Sites et services Active Directory. La méthode est encore plus rapide qu’avec ADUC.

Pour réaliser le Metadata Cleanup, ouvrez la console « Sites et services Active Directory », naviguez jusqu’à l’objet NTDS Settings relatif au contrôleur de domaine corrompu et supprimer à l’aide d’un clic droit et en sélectionnant l’option « Supprimer ».

{gallery}27_ADMC/18{/gallery}

 

 

 

 

 

 

 

Confirmez la suppression de l’objet et cocher la case « Ce contrôleur de domaine est définitivement hors connexion… ».

{gallery}27_ADMC/19{/gallery}

 

 

 

 

 

Comme ADUC, la console Sites et services Active Directory détecte également la présence d’un maître d’opérations ou de la fonction catalogue global. Il vous propose donc de forcer leur déplacement sur le serveur où est exécutée l’opération de Metadata Cleanup.

{gallery}27_ADMC/20{/gallery}

 

 

 

 

 

 

Il ne vous reste plus qu’à supprimer le conteneur de l’objet NTDS Settings portant le nom de votre serveur corrompu et le Metadata Cleanup est terminée.

{gallery}27_ADMC/21{/gallery}

 

 

 

 

 

 

 

 

La méthode alternative par script

La dernière et ultime méthode est d’utiliser un script pour réaliser le Metadata Cleanup. Cette méthode pourrait être utile s’il est nécessaire de réaliser une suppression par lot ou de l’automatiser pour quelques obscures raisons. Vous avez le code  Remove Active Directory Domain Controller Metadata à disposition que vous pourrez utiliser et faire évoluer pour développer votre propre script. Cela nous laisse aussi l’occasion de vous introduire l’excellent site Microsoft Script Center qui dispose d’un référentiel de scripts très étoffé sur les diverses technologies Microsoft.

Concernant le script que vous nous proposons, il vous suffira de récupérer le code, de l’introduire dans un fichier de type vbs et de l’exécuter. Il vous propose de sélectionner un serveur parmi une liste de contrôleurs de domaine disponibles sur votre annuaire. Il vous demande ensuite de confirmer la suppression du contrôleur et réalise donc le Metadata Cleanup.

{gallery}27_ADMC/22{/gallery}

 

 

 

 

 

Contrairement aux outils de Microsoft et comme cela est le cas dans le cadre d’une suppression manuelle, le script ne réalise pas une éventuelle saisie des maîtres d’opérations. Veillez donc à ce que l’ancien contrôleur de domaine n’hébergait pas un de ces rôles. Il est d’ailleurs conseillé de vérifier que les rôles soient bien présent suite à une saisie pour éviter toutes mauvaises surprises tel que ci-dessous.

{gallery}27_ADMC/23{/gallery}

 

 

 

 

 

 

 

 

 

Le nettoyage des zones DNS

Afin de permettre la localisation d’un contrôleur de domaine au sein d’Active Directory, des enregistrements DNS de type SRV sont créés lors de la promotion d’un contrôleur de domaine et sont mis à jour régulièrement par le service NETLOGON de chaque contrôleur de domaine. Dans le cadre d’un Metadata Cleanup, il faudra donc supprimer tous les enregistrements DNS relatifs au contrôleur de domaine corrompu afin d’éviter qu’il soit localiser par les différents clients au sein de votre annuaire.

Depuis la console « Gestionnaire DNS » vous allez devoir parcourir vos différentes zones et supprimer tout enregistrement relatif au contrôleur de domaine corrompu qu’ils soient de type SRV, A ou CNAME depuis les zones _msdcs.[MONDOMAINE] et [MONDOMAINE].

{gallery}27_ADMC/24{/gallery}

 

 

 

 

 

 

 

 

 

Si vous ancien contrôleur de domaine faisait office de serveur DNS, il faut également faire en sorte qu’il ne soit plus considéré comme serveur de noms. Réalisez un clic droit sur la zone voulue, sélectionnez « Propriétés » et placez-vous dans l’onglet « Serveurs de noms ». Si le contrôleur corrompu apparait dans la liste des serveurs de noms, mettez l’enregistrement en surbrillance et cliquer sur le bouton « Supprimer ».

{gallery}27_ADMC/25{/gallery}

 

 

 

 

 

 

 

 

 

Une fois tous les enregistrements DNS supprimés, nous allons pouvoir tester que désormais ils ne posent plus de problème dans le cadre de la réplication Active Directory. Pour cela nous allons utiliser l’outil Dnslint  que vous pouvez télécharger ICI. Une fois l’outil récupéré, exécutez la commande « dnslint /ad /s localhost » directement sur un contrôleur de domaine faisant également office de serveur DNS où alors spécifiez une adresse IP respectant cette prérogative à la place de localhost. La commande générera un rapport HTML.

{gallery}27_ADMC/26{/gallery}

 

 

 

 

 

 

 

 

 

 

 

Post-vérification

Comme nous le disions en introduction, la majeur partie des problèmes que vous rencontrez avec un contrôleur de domaine corrompu est liée à la réplication. La meilleure manière de vérifier que le Metadata Cleanup a été réalisé avec succès sera de vérifier donc au niveau de la réplication. Pour cela, nous allons utiliser l’outil Repadmin, inclus par défaut sur Windows Server 2008 et disponible depuis les Supports Tools pour les versions Windows Server 2000 et 2003. Contrairement à Repadmin qui est un outil en ligne de commande, il existe l’application avec interface graphique  Replmon mais qui n’est désormais plus supporté sur Windows Server 2008 et que nous ne présenterons donc pas sachant que Repadmin fournis d’excellents résultats.

Depuis un invite de commandes, nous allons commencer par exécuter la commande « repadmin /showrepl » et vérifier qu’il n’y a pas d’erreurs ou de quelconques références à l’ancien contrôleur de domaine.

{gallery}27_ADMC/27{/gallery}

 

 

 

 

 

 

Vous pouvez également utiliser la commande « repadmin /replsum ».

{gallery}27_ADMC/28{/gallery}

 

 

 

 

Et si vraiment vous avez encore la moindre inquiétude, vous pouvez utiliser la commande « DCDIAG /test:replications /v » qui vous fournira un plus large éventail d’information sur les réplications au sein de l’annuaire et dont nous vous montrons ci-dessous qu’une petite partie.

{gallery}27_ADMC/29{/gallery}

 

 

 

 

 

 

 

 

 

Conclusion

La règle TIMTOWTDI (prononcé tim toady) pour « There Is More Than One Way To Do It » ou plus clairement en français « Il y a plus d’un moyen pour y arriver » et une définition générale au monde de l’informatique et qui se vérifie régulièrement sur Active Directory. En effet, il est possible de réaliser une grande majorité des opérations Active Directory  par Interface Graphique (GUI), par ligne de commande ou par script et comme nous avons pu le voir dans notre article, le Metada Cleanup ne déroge plus à cette règle.

Choisissez la méthode qui vous convient le mieux et selon les conditions (méthode manuelle, méthode en ligne de commande, méthode GUI ou méthode par script), faites le nécessaire pour le nettoyage de vos zones DNS et assurez-vous du succès de l’opération en vérifiant votre système de réplication.

RODC: partie 4 – Configuration de FAS et ARS

Sommaire

 

Introduction

Nous clôturons le sujet RODC par ce dernier article qui se consacre exclusivement à la configuration des filtrages d’attribut et la mise en place des délégations d’administration.

 

Filtered Attribute Set

Ayant pour anagramme FAS, cette seconde particularité de RODC permet à une liste d’attributs d’être filtrée pour ne pas être répliquée sur le RODC toujours pour des raisons de sécurité. FAS est assez proche de PRP à la différence qu’elle ne se cantonne pas exclusivement aux informations d’authentification mais à peu près tout type d’attribut que vous pourriez considérer comme sensible en cas de compromission de votre RODC. Veuillez simplement noter que certains attributs de base ne sont pas filtrables et en particulier ceux dont  la valeur d’attribut pour schemaFlagsEx est défini à 0x1 (system-critical attribute).

ATTENTION !!! Si vous voulez assurer pleinement le fonctionnement de FAS sur votre RODC, il faudra que le niveau fonctionnel de la forêt soit en 2008 car le RODC peut répliquer les attributs filtrés depuis un Windows Server 2003 ou antérieur.  En clair, le FAS n’est pris en compte qu’à partir de 2008.

Remarque: Toutes les modifications d’attributs et spécialement pour le filtrage doivent être réalisées sur un serveur 2008 disposant du maître d’opération maître de schéma.

A partir de la console ADSIEDIT et en ouvrant la partition de schéma,  si vous accédez aux propriétés de l’attribut « Computer » par exemple, nous pouvons voir que la valeur d’attribut systemFlags est défini sur 0x10 (16) et donc le filtrage ne sera pas possible.

{gallery}25_RODC_conf/10{/gallery}

 

 

 

 

 

 

 

 

 

Pour activer le FAS sur un attribut spécifique, il faut modifier le dixième bit de sa valeur d’attribut searchFlags. Par défaut cette valeur d’attribut est affichée en hexadécimal et les modifications passent par des valeurs décimales, donc pour plus de clarté, on considérera qu’il faudra ajouter la valeur décimale 512 à searchFlags.

  • Valeur décimale : 512
  • Valeur hexadécimal : 200
  • Valeur binaire : 1000000000 (le dixième bit est passé à 1)

Il est également recommandé par Microsoft de rendre l’attribut confidentiel et de modifier également le  septième bit de la valeur d’attribut searchFlags ce qui permettra entre autres de ne plus rendre lisible l’attribut par le groupe « utilisateurs authentifiés ». Il faudra donc ajouter la valeur décimale 128.

  • Valeur décimale : 128
  • Valeur hexadécimal : 80
  • Valeur binaire : 1000000 (le septième bit est passé à 1)

En conclusion, pour activer le filtrage et la confidentialité sur un attribut, il faut configurer la valeur d’attribut searchFlags à 640 (512+128) qui correspond à la valeur binaire 1001000000. Attention toutefois que la valeur searchFlags n’a pas toujours par défaut une valeur nulle donc il faudra combiner les différentes valeurs. Si l’attribut est indexé alors la valeur d’attribut searchFlags sera de 1. Si vous voulez le rendre confidentiel et le filtrer tout en conservant l’indexation, il faudra donc lui rentrer comme nouvelle valeur 641.  Vous avez la liste des différentes valeurs attribuables par défaut à searchFlags ici.

Nous ne l’avions pas cité précédemment mais 6 attributs sont filtrés et marqués comme confidentiels par défaut. Sachant qu’il faut que leur valeur searchFlags soit à 640, nous pouvons les localiser assez simplement. Pour cela ouvrez « ldp.exe » depuis « Exécuter ». Une fois ldp lancé, allez dans « Connexion » | « Se connecter… » et indiquez le FQDN du contrôleur de domaine où vous devez vous connecter. Si vous rencontrez des problèmes d’authentification, préciser les informations d’identification depuis « Connexion » | «  Lier… ».

{gallery}25_RODC_conf/11{/gallery}

 

 

 

 

 

 

 

 

Une fois connecté, sélectionner à partir du menu « Parcourir »  la fonction « Rechercher », placez-vous sur la partition de schéma et  entrez comme filtre de recherche « (SearchFlags:1.2.840.113556.1.4.803:=640) » pour afficher les attributs filtrés et confidentiels (valeur 640). A noter que la valeur 1.2.840.113556.1.4.803 est décrite depuis le KB Microsoft Comment faire pour interroger Active Directory à l’aide d’un filtre au niveau du bit. Cette information et de manière globale cette section  reprend l’article Enumerate The RODC FAS. Une fois que vous cliquez sur le bouton « Exécuter », vous obtiendrez le détail des attributs concernés.

{gallery}25_RODC_conf/12{/gallery}

 

 

 

 

 

 

 

Comme vous pouvez le constater, il y a 6 attributs qui sont configurés de base comme étant filtrés et confidentiels. Nous les détaillerons ici pas mais vous pouvez obtenir plus d’information depuis l’article Technet RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC.

Vous pouvez modifier les attributs à partir de divers outils tel que ADSIEDIT que nous avions utilisé précédemment. Il suffit simplement d’accéder aux propriétés de l’attribut et de modifier la valeur searchFlags.

{gallery}25_RODC_conf/13{/gallery}

 

 

 

 

 

 

 

 

 

 

Administrative Role Separation

La dernière fonctionnalité est ARS pour Administrative Role Separation. Grâce à ARS vous pourrez déléguer l’administration du RODC localement à un utilisateur ou un groupe d’utilisateurs sans droit supplémentaire au niveau de votre domaine. ARS est assez similaire au droit d’administrateur local que l’on peut retrouver sur un poste lambda.

Lors de l’installation du RODC, vous avez la possibilité de définir le groupe ou l’utilisateur ayant les droits d’administration sur le RODC. Par contre, si vous désirez modifier ces accès, il vous suffira simplement d’ouvrir la console « Utilisateurs et ordinateurs Active Directory », de vous rendre dans le conteneur où se trouve votre RODC et d’accéder aux propriétés à l’aide d’un clic droit (Bien entendu il faudra réaliser la manipulation depuis un contrôleur de domaine accessible en écriture). Une fois dans les propriétés, il faudra tout simplement se rendre dans l’onglet « géré par » et ajouter l’utilisateur ou le groupe voulu à l’aide du bouton « Modifier… ».

{gallery}25_RODC_conf/14{/gallery}

 

 

 

 

 

 

 

 

 

 

Conclusion

Nous en avons désormais fini avec RODC! Nous espérons que l’ensemble des articles sur le sujet vous aura permis de comprendre et d’appréhender correctement cette fonctionnalité qui est loin d’être un pis-aller. Il en a séduit et devra en séduire plus d’un !

RODC: partie 3 – Configuration de PRP

Sommaire

 

 

Introduction

Cet article fait suite aux deux articles RODC: partie 1 – Présentation et RODC: partie 2 – Préparatifs et installation et va être consacré essentiellement à l’approfondissement de ce que nous considérons comme étant la fonctionnalité la plus complexe de RODC : la stratégie de réplication des mots de passe. Nous allons donc voir dans le détail son fonctionnement et sa configuration.

Pour ceux qui auront déjà consulté notre article de présentation, certains éléments pourront vous paraître répétitifs cependant nous avons jugé nécessaire de les réincorporer pour permettre une meilleure compréhension.

 

 

Présentation

Par défaut un RODC transmet toutes les demandes d’authentification à un contrôleur de domaine accessible en écriture et donc en tout logique à travers un réseau WAN. Vos utilisateurs seront donc toujours assujettis à la lenteur d’une ouverture de session depuis un WAN  (hormis l’application des stratégies) et même tributaires en cas de dysfonctionnement. Pour pallier à cela et en particulier pour des comptes utilisateurs considérés comme peu sensibles, Microsoft a mis en place le PRP (Password Replication Policy).

Le PRP va tout simplement vous permettre de définir quels sont les mots de passe des comptes à mettre en cache sur le RODC. Configurer le PRP vous apportera les avantages suivants :

  • Il empêchera toujours la mise en cache des comptes sensibles pour une meilleure sécurité.
  • Il permettra une authentification rapide à partir du RODC pour les comptes utilisateurs dont la mise en cache des mots de passesa été activée (il faut mettre également en cache les comptes ordinateurs et de services associés).
  • Il offrira la possibilité aux utilisateurs de se connecter même en cas de ruptures de la liaison WAN ne nécessitant plus de faire appel à un contrôleur de domaine accessible en écriture.

ATTENTION !!! Pour que le PRP assure pleinement sa fonction, il faudra impérativement qu’il n’y ait plus de Windows Server 2000 et donc que le niveau fonctionnel de la forêt soit au minimum en 2003. Toutes données disponibles sur un 2000 sont accessibles par un RODC.

 

 

Gestion et fonctionnement du PRP

Dans un premier temps, nous allons voir comment accéder à la gestion de PRP. Pour cela, il suffit simplement d’ouvrir la mmc « Utilisateurs et ordinateurs Active Directory » depuis un contrôleur accessible en écriture. Ensuite vous devez vous rendre dans l’unité d’organisation « Domain Controllers » et sélectionner « Propriétés » à l’aide d’un clic droit sur le RODC concerné. Une fois que vous accédez aux propriétés du RODC, allez dans l’onglet dans « Stratégie de réplication de mot de passe ». Notez que chaque RODC présent dans votre infrastructure disposera de sa propre stratégie PRP.

{gallery}25_RODC_conf/1{/gallery}

 

 

 

 

 

 

 

 

 

Si vous cliquez sur le bouton « Avancé… », vous obtenez depuis l’onglet « Utilisation de la stratégie »  la liste des comptes mis en cache et la liste des comptes authentifiés. A noter que la liste des comptes stockés contient par défaut deux comptes qui sont le compte ordinateur du RODC et son compte spécial krbtgt. Le deuxième onglet « Stratégie résultante » vous permettra de vérifier si un compte est paramétré pour être mis en cache ou non.

{gallery}25_RODC_conf/2{/gallery}

 

 

 

 

 

 

 

 

Si nous revenons dans la fenêtre « Propriétés de » de votre RODC, dans l’onglet « Stratégie de réplication de mot de passe » vous avez la colonne « Paramètre » qui vous permettra de définir si un groupe ou un compte sera mis en cache en les intégrant soit dans une liste d’autorisation soit dans une liste de refus.  Elles sont tenues à disposition du RODC sous forme de deux attributs : msDS-RevealOnDemandGroup pour la liste d’autorisation et msDS-NeverRevealGroup pour la liste de refus.

Remarque: cette partie présente la gestion d’une partie de la stratégie de réplication de mot de passe au niveau du schéma Active Directory. Elle n’est pas une étape nécessaire à la configuration mais nous espérons qu’elle vous permettra de  mieux appréhender le sujet.

Pour accéder à ces deux attributs, ouvrez la mmc adsiedit. Faites ensuite un clic droit sur la racine « Modification ADSI » pour choisir « Connexion… » et sélectionnez depuis la fenêtre « Paramètres de connexion le point de connexion » le point de connexion « Contexte d’attribution des noms par défaut ».

{gallery}25_RODC_conf/3{/gallery}

 

 

 

 

 

 

 

 

Naviguez ensuite dans l’arborescence jusqu’à « OU=Domain Controllers,DC=corpnet,DC=net » pour atteindre l’objet « CN=RODC » où RODC correspond au nom de votre contrôleur de domaine en lecture seule. Réalisez un clic droit sur cet objet et sélectionnez « Propriétés ». Vous accédez directement depuis l’onglet « Editeur d’attributs » aux deux attributs que vous pouvez modifier en conséquence à l’aide du bouton « Modifier ».

{gallery}25_RODC_conf/4{/gallery}

 

 

 

 

 

 

 

 

 

msDS-RevealOnDemandGroup permettra de définir quel compte sera mis en cache. Par défaut, il contient une seule valeur qui est tout simplement le groupe « Groupe de réplication dont le mot de passe RODC est autorisé » situé dans le répertoires « Users » accessible depuis la mmc « Utilisateurs et ordinateurs Active Directory ».

{gallery}25_RODC_conf/5{/gallery}

 

 

 

 

 

 

Le second attribut msDS-NeverRevealGroup quand à lui contiendra les comptes qui seront explicitement rejetés de cette mise en cache. Par défaut, il contient le groupe « Opérateurs de compte », « Opérateurs de serveur », « Opérateurs de sauvegarde », « Administrateurs » et « Groupe de réplication dont le mot de passe RODC est refusé ». Ce dernier est situé au même droit que « Groupe de réplication dont le mot de passe RODC est autorisé » mais par contre il n’est pas vide comme son homologue et contient les groupes visibles depuis l’imprime écran ci-dessous. Il englobe par défaut tous les comptes les plus sensibles de votre forêt.

{gallery}25_RODC_conf/6{/gallery}

 

 

 

 

 

 

 

 

Remarque: PRP utilise également d’autres attributs que nous ne verrons pas ici. Si vous voulez en savoir plus sur ce point, une liste de liens exhaustifs vous est fournie en conclusion.

Idéalement, il faudra donc créé un groupe de type sécurité avec une étendue de domaine qui contiendra l’ensemble des comptes utilisateurs et ordinateurs à mettre en cache pour chacun de vos RODC. Bien entendu, si vous n’avez qu’un seul RODC par domaine, vous pourrez vous contenter des groupes proposés de base lors de l’installation du RODC. Pour reprendre notre maquette de l’article précédent, nous allons donc créer un groupe « Utilisateurs et Ordinateurs Marseille » que nous mettrons en cache sur le RODC.

Depuis l’onglet « Stratégie de réplication de mot de passe » de votre RODC, cliquez sur « Ajouter », choisissez « Autoriser la réplication des mots de passe du compte sur ce contrôleur de domaine en lecture seule (RODC) » pour ensuite sélectionner votre groupe créé au préalable. Tous les membres de ce groupe sera donc mis en cache au fur et à mesure et lors de leur première authentification.

Remarque: si un compte fait partir d’une liste autorisée et conjointement d’une liste de refus, la plus restrictive prendra le pas (donc la liste de refus).

{gallery}25_RODC_conf/7{/gallery}

 

 

 

 

 

 

 

 

 

 

Opérations diverses

Il est aussi possible de pré-remplir les objets ayant l’autorisation d’être mis en cache plutôt que d’attendre leur première authentification. Toujours depuis l’onglet « Stratégie de réplication de mot de passe », cliquez sur « Avancé… ». A partir de l’onglet « Utilisation de la stratégie », cliquez « Préremplir les mots de passe… » et sélectionnez le compte ordinateur ou utilisateur qui sera pré-rempli. Il n’est pas possible de réaliser cette étape par lot en sélectionnant un groupe. Il faudra passer malheureusement par un script. Vous aurez enfin un message d’alerte pour vous prévenir du risque que peut entrainer le pré-remplissage et vous invitant à faire la manipulation pour le compte ordinateur de l’utilisateur sélectionné.

{gallery}25_RODC_conf/8{/gallery}

 

 

 

 

 

 

 

 

Nous avons fait le tour du PRP hormis peut-être un cas particulier qui concerne la gestion des comptes mis en cache lors du vol de votre RODC. Ca ne devrait pas vous arrivez tous les jours cependant prenez note qu’il faudra réinitialiser tous les mots de passe des comptes mis en cache afin d’en assurer l’intégrité. Pour cela il suffira simplement de supprimer l’objet ordinateur correspondant à votre RODC pour que vous ayez à l’écran la fenêtre « Suppression du contrôleur de domaine »  avec la possibilité de réinitialiser les mots de passes utilisateurs et/ou ordinateurs.

{gallery}25_RODC_conf/9{/gallery}

 

 

 

 

 

 

 

Conclusion

Nous avons essayé de voir de manière exhaustive la fonctionnalité PRP et cet article devrait vous permettre de la gérer au mieux et d’en maitriser la majeure partie. Il peut être toutefois nécessaire d’approfondir le sujet et pour cela nous vous proposons de consulter les articles Technet suivants: