Réplication Active Directory avec Powershell et .NET

Dans cet article, nous allons regarder comment utiliser les fonctions de .NET à travers Powershell pour récupérer l’état de réplication  d’un annuaire Active Directory.

Nous allons regarder spécifiquement le namespace System.DirectoryServices.ActiveDirectory dans laquelle il y a les classes suivantes:

DirectoryContext : permet de créer un contexte de connexion de type « DirectoryServer », « Domain » ou « Forest ». Voici un exemple de création d’objet Powershell de type DirectoryContext avec connexion DirectoryServer pour se connecter sur DC en particulier:

Ou en utilisant des credentials alternatifs:

Ou vers un domaine Active Directory et là le type de contexte sera « Domain »:

Version de type « Domain » mais avec credentials alternatifs:

 

DomainController: permet de chercher un serveur parmis les domain controllers du domaine. Si le contexte créé est de type DirectoryServer nous pouvons nous connecter sur le DC ainsi

Si le contexte est de type « Domain » nous pouvons faire une recherche pour trouver un DC ainsi:

ou tous les DCs du domaine ainsi:

Une fois notre objet $dc créé nous pouvons utiliser sa méthode GetAllReplicationNeighbors pour trouver tous les partenaires de réplication

Le résultat sera un array de DCs, que nous pouvons parcourir avec un ForEach et le contenu de chaque élément sera ainsi:

Chose intéressante, nous avons l’état de réplication du DC en question avec code de résultat et message.

Avec la classe DomainController nous pouvons également récupérer les partitions de l’Active Directory

et pour chaque partition nous pouvons récupérer les cursors:

Les cursors de l’Active Directory sont des objets représentant l’état de réplication entre DCs. Chose formidable est que ces objets sont répliqués sur tous les DCs, donc en récupérant les cursors d’un DC, nous avons l’état complet de réplication d’une partition donnée selon ce DC.

L’Active Directory étant un système multi-maître, cette vue de DC sera potentiellement vite obsolète, mais donne quand même un état général proche de la réalité. Si un DC est en erreur, les cursors auront cette information.

Les données dans un cursor sont:

  • LastSuccessfulSyncTime: dernière synchronisation
  • PartitionName: le nom de la partition, Domaines, Schema, Configuration, mais potentiellement aussi les partitions DNS stockées dans l’AD, ou autres partitions applicatives.
  • SourceInvocationId: le GUID du DC source
  • SourceServer: le nom du DC source
  • UpToDatenessUsn: le dernier Update Sequence Number connu du DC source. Si un objet est modifié l’USN est augmenté, c’est ainsi que les DCs savent s’ils doivent répliquer ou pas.

Par exemple, voici les cursors d’un domaine avec deux DCs, DC1 et DC2:

Les cursors, comme les neighbors ont la propriété LastSuccessfulSyncTime, et avec cette information nous pouvons faire un calcul de latence de synchronisation sur toute la forêt.

Pour faire ceci, nous allons tout d’abord réarranger la table en ordre croissant par rapport à la propriété LastSuccessfulSyncTime

Ainsi nous avons une vue ordonnée qui peut être intéressante.

Nous pouvons également parcourir la table, générer un objet Time-Span (différence de temps) entre maintenant et le LastSuccessfulSyncTime, et analyser tout ça:

Si la différence est moins d’une heure, plus d’une heure mais moins d’une journée, moins de 7 jours, plus de 7 jours mais moins de 30, etc. on les organise comme on veut pour les regrouper.

Ensuite nous pouvons créer un objet qui contiendra ces arrays

Voici le résultat :

Et ainsi j’ai une idée globale de la latence de réplication.