Jason Jocobo Chef de produit

Personne ne retarde une migration d'Active Directory sous prétexte qu'il est difficile de copier des objets.

Demandez à n'importe quelle équipe chargée de la gestion des identités en entreprise pourquoi la consolidation de la forêt qu'elle avait prévue il y a trois ans n'a toujours pas eu lieu. Vous n'entendrez probablement pas qu'il était impossible de déplacer les objets avec les outils disponibles.

Vous entendrez autre chose : personne ne pouvait affirmer avec certitude ce qui allait casser.

Voilà à quoi ressemble réellement la migration d’Active Directory aujourd’hui. Il s’agit de projets impliquant des milliers d’utilisateurs, des dizaines de milliers de groupes, des autorisations que personne n’a vérifiées depuis la dernière réorganisation, et des applications étroitement liées à un annuaire dans lequel s’accumulent des décisions depuis 20 ans.

Le risque ne réside pas dans l'opération de copie elle-même. Le risque réside dans tout ce que cette opération de copie touche.

Les projets sont donc reportés. Puis retardés. Et, bien souvent, annulés — tandis que l'organisation continue de gérer un annuaire dont elle sait déjà qu'il constitue un handicap.

Entre-temps, le contexte dans lequel s'inscrit cette décision a complètement changé. La duplication des groupes, des comptes, des utilisateurs et des mots de passe, ainsi que le transfert de l'historique des SID d'un environnement à un autre, ont toujours comporté des risques. Mais procéder ainsi dans le contexte actuel des menaces est une opération fondamentalement différente de ce qu'elle était en 1999.

Active Directory constitue le principal vecteur d'attaque dans la plupart des intrusions au sein des entreprises, et une fenêtre de migration désigne une période durant laquelle les relations de confiance sont ouvertes, les comptes de service fonctionnent avec des privilèges élevés et les objets sont en cours de transfert entre deux environnements.

L'identité constitue le plan de contrôle régissant l'accès, la confiance et la continuité d'activité. Elle mérite davantage d'attention, de contrôle et de visibilité que la plupart des changements apportés à l'infrastructure.


La migration n'est pas un simple transfert de données. Il s'agit d'un événement lié à la sécurité des identités.

C'est le principe sur lequel repose Semperis Migrator 2.0, et il convient de le souligner clairement : chaque objet que vous migrez correspond à un franchissement de la frontière de confiance.

Les outils de migration sont généralement évalués en fonction de leur débit : combien d'objets, à quelle vitesse. Migrator transfère lui aussi les objets rapidement. Mais ce n'est pas le débit d'objets qui a fait que ces projets ont duré trois ans.

Ce qui accapare le calendrier, ce sont les retouches. Une synchronisation qui a eu un effet inattendu, et les deux semaines passées à la défaire. Un week-end de basculement reporté parce qu’une dépendance est apparue vendredi. Quatre heures passées un samedi soir à déterminer lequel des onze composants avait généré l’erreur. Une file d’attente de réinstallation pour des machines qui n’avaient jamais eu besoin d’être réinstallées au départ.

Les migrations sont rarement lentes. Elles s’arrêtent. Puis elles reprennent. Le frein n’est donc pas la vitesse du moteur, mais la part du programme que vous ne migrez pas.

Migrator 2.0 s'articule autour de trois questions.

  • Pouvez-vous deviner ce qui va changer avant que cela n'arrive ?
  • Est-il possible de déplacer des terminaux par lots sans les toucher physiquement ?
  • En cas de panne, êtes-vous capable de localiser le problème en quelques minutes ?

Ici, le contrôle n'est pas le prix à payer pour la sécurité ; c'est ce qui permet au projet d'avancer.


Quatre problèmes et comment Migrator 2.0 y remédie

Voici quelques-uns des principaux points de défaillance liés à la migration AD que Semperis permet de résoudre.


On ne peut pas prédire ce qu'une synchronisation va réellement faire.

Dans la plupart des installations d'usinage, le résultat d'une synchronisation dépend de l'expérience de l'opérateur et de la chance.

Migrator 2.0 propose désormais un rapport de prévisualisation: un aperçu complet des modifications prévues, validées par rapport à l'environnement de production, avant toute validation définitive.

Ce qui distingue cette opération d'un simple test, c'est qu'elle applique vos manipulations d'attributs. Si vous avez défini des règles pour réécrire un suffixe UPN, concaténer des valeurs ou appliquer une logique conditionnelle, le rapport de prévisualisation vous montre les valeurs obtenues — non pas la règle, mais le résultat. Modifiez la transformation, relancez la prévisualisation, observez le nouveau résultat. Vous répétez l'opération jusqu'à ce que l'aperçu corresponde exactement à ce que vous souhaitez, puis vous validez.

Cela permet d'éliminer l'étape la plus coûteuse d'un programme de migration : se rendre compte du problème après coup et devoir relancer toute la phase.

La synchronisation elle-même est désormais organisée en « ensembles de synchronisation d’annuaires» : des conteneurs au niveau du projet qui regroupent une source, une cible, les paramètres d’importation et de portée, la sélection des attributs, l’exécution et les résultats au sein d’un flux de travail contrôlé unique. Les équipes gérant plusieurs flux de travail simultanés bénéficient ainsi d’une véritable séparation, au lieu d’une configuration globale que personne n’ose modifier. Les scénarios multi-domaines, multi-forêts et à domaine unique s’exécutent tous via la même interface. Les transformations d’attributs — réécriture des suffixes UPN, mappage, règles conditionnelles et basées sur des formules — sont configurées directement dans le produit plutôt que dans une pile de scripts personnalisés dont personne ne veut se charger une fois les consultants partis.


C'est au niveau des points de terminaison que les migrations échouent réellement.

Les objets, c'est la partie la plus simple. Les incidents qui donnent lieu à des tickets d'assistance surviennent au niveau du poste de travail et du serveur de fichiers : une liste ACL défectueuse, une imprimante introuvable, un compte de service qui ne s'authentifie plus, un profil qui n'a pas suivi l'utilisateur.

L'agent « Secure Access and Control » de Migrator gère la migration sur place. Pas besoin de recréer les objets informatiques, pas de réinstallation d’images, pas de file d’attente de machines en attente d’une équipe chargée des postes de travail. Les terminaux sont organisés en groupes de migration et déplacés par vagues dont la taille est adaptée aux lots d’entreprise, ce qui permet au programme de fonctionner en continu plutôt que de s’accumuler au fil d’une série de week-ends de migration.


La coexistence est le mode de fonctionnement habituel, et non un cas particulier.

Il n'y a pratiquement plus aucune migration d'entreprise qui se fasse en une seule fois. Les véritables projets se déroulent par étapes, sur plusieurs mois, l'environnement source et l'environnement cible fonctionnant tous deux en production, tandis que les utilisateurs sont répartis entre les deux.

Migrator version 2.0 considère cela comme le scénario normal : les workflows de synchronisation sont planifiés dans des créneaux horaires adaptés aux opérations métier, les vagues s'exécutent par incréments contrôlés, et les opérateurs peuvent les mettre en pause, corriger les problèmes et les reprendre en fonction des résultats en temps réel. Un problème survenant dans une vague vous fait perdre uniquement cette vague — cela n'entraîne pas une annulation générale ni un redémarrage du programme.


Quand un problème survient à 23 h, on est généralement dans le flou.

Les systèmes distribués connaissent des défaillances de manière distribuée, et la première heure d'un incident survenant pendant la nuit est généralement consacrée à déterminer quel composant interroger.

Migrator 2.0 regroupe les journaux des agents, des services, de la console Web, de la base de données et de l'infrastructure au sein d'une interface unique permettant d'effectuer des recherches, grâce à des identifiants de corrélation reliant les entrées associées entre les différents composants, à un filtrage par niveau de gravité, à une recherche en texte intégral et par motif, ainsi qu'à des fonctionnalités d'exportation.

C'est là toute la différence entre un triage qui se mesure en heures et un triage qui se mesure en minutes.

La validation du déploiement vérifie la connectivité réseau, les certificats, le DNS et l'état des services avant le début du déploiement ; ainsi, les problèmes qui apparaissent généralement en cours de migration sont détectés dès la phase de configuration.


Et en parallèle de tout cela : un suivi en temps réel de l'avancement.

Nombre d'objets par État, taux de réussite et d'échec par type d'objet, débit, temps écoulé, liste consultable des objets ayant échoué avec détails sur l'erreur et possibilité de nouvelle tentative, ainsi que l'historique des SID et les résultats de la synchronisation des mots de passe. Pendant la phase la plus critique du projet, il devrait suffire de quelques secondes pour savoir « où en sommes-nous actuellement », sans avoir à appeler le support technique.

Tout cela ne compromet en rien la rapidité. C'est justement de là que vient cette rapidité : moins de réexécutions, pas de file d'attente pour la recréation des images, des vagues qui ne s'arrêtent jamais et des défaillances détectées en quelques minutes.

Ce raisonnement s'applique également au lancement d'un programme : c'est un déploiement simplifié et reproductible qui permet de réduire le délai entre la signature du contrat et la migration du premier objet. Migrator s'exécute sur un environnement Kubernetes géré par le client, que ce soit dans le cloud ou sur site.


La place de la migration AD dans le contexte global…

La migration est une étape délicate du cycle de vie de l'identité, et non pas son aboutissement. Les environnements sont en pleine transition, les autorisations peuvent évoluer et des lacunes en matière de visibilité apparaissent.

C’est pourquoi Semperis intègre la migration dans un modèle axé sur la sécurité plutôt que de la considérer comme un événement isolé, ce qui permet de réduire les risques avant la migration, d’assurer la stabilité des opérations pendant la phase de transition et de renforcer la sécurité dans l’environnement de destination par la suite.

Dans ce modèle, le rôle du migrateur se situe au milieu : faire évoluer l'identité et l'accès par étapes contrôlées, veiller à ce que chaque changement soit intentionnel et traçable, et laisser la destination dans l'état que vous avez choisi plutôt que dans celui dont vous avez hérité.

Les capacités d'évaluation, de surveillance et de rétablissement de la plateforme Semperis— ainsi que les informations plus approfondies sur les risques liés à la migration prévues dans notre feuille de route — sont ce qui rend les étapes qui la précèdent et la suivent tout aussi mûrement réfléchies.

L'identité n'est pas figée. Elle évolue à mesure que les organisations fusionnent, se séparent, se modernisent et renforcent leur sécurité. La mobilité fait partie intégrante de ce cycle de vie, et elle devrait être un processus récurrent plutôt qu'une situation d'urgence survenant une fois tous les dix ans.


…et comment Migrator peut vous être utile

Migrator for Active Directory est conçu pour :

  • Migration, consolidation et modernisation d'AD vers AD
  • Intégration post-fusion-acquisition et cession d'activités
  • Consolidation multi-domaines et multi-forêts
  • Modernisation et restructuration du domaine
  • Reconstructions axées sur la sécurité
  • Migration des succursales ou du personnel en télétravail

Vous souhaitez découvrir comment la version 2.0 d’ Migrator for Active Directory aidera vos équipes à planifier, mettre en œuvre et suivre la migration en toute sérénité ? Demandez une démonstration personnalisée.


Lectures complémentaires (le cas échéant)