Mike Masciulli Directeur général, Produits et services de migration

La migration de votre AD n'a pas renforcé votre sécurité. Dans de nombreux environnements, c'est même tout le contraire.

« Comment le sais-tu ? »

C'est la question délicate qui revient sans cesse lorsque je m'entretiens avec des entreprises qui envisagent des fusions, des migrations vers le cloud ou des projets de modernisation.

Trop souvent, les entreprises dépensent des millions dans un projet de migration et de consolidation d'Active Directory (AD) et le traitent comme un simple transfert de données : elles transfèrent les utilisateurs, les groupes et les applications vers une nouvelle forêt, déclarent mission accomplie et partent du principe que le plus dur est fait.

Mais si vous reproduisez les mêmes erreurs de délégation, d'imbrication de groupes, de relations de confiance et de comptes dotés de privilèges excessifs, vous risquez de recréer les mêmes vecteurs d'attaque dans un nouvel environnement — et parfois de les rendre plus difficiles à détecter. Une migration réussie ne garantit pas pour autant une posture de sécurité irréprochable.

Voici onze risques courants que je constate souvent lors des migrations AD classiques. En abordant la migration AD avec une approche axée sur la sécurité, vous pouvez réduire les vulnérabilités héritées du système existant au lieu de les reporter dans le nouvel environnement.


1. Privilège administratif hérité

Une migration Active Directory peut se transformer en vecteur d'escalade de privilèges lorsque des droits d'administrateur de domaine ou d'administrateur d'entreprise hérités sont transférés vers l'environnement cible sans être vérifiés. Ce qui semble être une simple continuité n'est en réalité que le transfert d'anciennes erreurs administratives vers un nouvel environnement qui aurait dû être conçu selon les pratiques de sécurité actuelles.

J'ai vu des migrations perpétuer des structures de privilèges vieilles de plusieurs décennies. Si les anciens privilèges perdurent, les anciens risques perdurent eux aussi.


2. Reconstitution des voies d'attaque existantes

Si vous conservez les raccourcis liés à l'imbrication des groupes, à la délégation et à la coexistence sans analyser les relations entre les privilèges avant la bascule, les attaquants pourront continuer à emprunter les mêmes voies de déplacement latéral qu'auparavant. La migration peut se dérouler sans heurts sur le plan opérationnel, mais du point de vue de la sécurité, les mêmes voies d'attaque subsistent.

Dans certains cas, la migration peut avoir des conséquences encore plus graves : elle peut créer un pont entre un environnement source compromis et l'environnement cible. Ce que vous omettez de vérifier pendant la migration devient souvent, par la suite, un incident pour quelqu'un d'autre.


3. Divulgation des identifiants lors de la migration

Les fenêtres de migration sont instables. Les identifiants sont partagés, des relations de confiance sont ajoutées, la synchronisation s'étend, et les modifications légitimes génèrent suffisamment de bruit pour dissimuler des activités malveillantes à la vue de tous.

En avril 2026, Microsoft a modifié le paramètre par défaut du KDC Kerberos afin de privilégier l'AES pour les comptes ne disposant pas de paramètres de chiffrement explicites. Ce changement peut entraîner la défaillance des comptes de service dépendant de RC4 en période de coexistence si les équipes n'ont pas identifié ces dépendances au préalable. Comme l'explique mon article intitulé « RC4 et migration AD : découvrez les scénarios de défaillance cachés dans votre domaine source », les projets de migration sont particulièrement exposés, car les outils standard peuvent déplacer un compte tout en conservant ses paramètres de chiffrement d'origine.

Si l'on ajoute à cela le risque que des pirates exploitent les relations de confiance — voire créent des « forêts fantômes » pour récolter des identifiants pendant que les équipes se concentrent sur la migration —, il apparaît clairement que la fenêtre de migration constitue l'une des phases les plus risquées du cycle de vie des identités.


4. Utilisation abusive de SID-History

L'attribut SID-History est utile pour assurer la continuité, mais peut s'avérer dangereux en l'absence de mesures de gouvernance. Des testeurs d'intrusion l'ont utilisé plusieurs mois après la migration pour accéder à des ressources héritées via des identités qui n'auraient plus dû avoir d'importance.

Concrètement, un pirate peut attribuer l'historique des SID d'un compte administratif à un compte disposant de privilèges moindres et ainsi retrouver un accès effectif à l'environnement d'origine. Pire encore, ces anciens SID persistent souvent pendant des années, car les entreprises ne les suppriment jamais complètement.


5. Des conditions d'accès (ACL) défectueuses ou trop laxistes

La traduction des listes de contrôle d'accès (ACL) sans validation est l'un des moyens les plus rapides de provoquer une dérive des autorisations. Des données sensibles relatives aux ressources humaines ou aux finances peuvent ainsi devenir accessibles à de larges groupes d'utilisateurs, et les entreprises ne s'en rendent souvent compte que lorsqu'un audit échoue ou qu'un utilisateur a accès à des données auxquelles il n'aurait jamais dû avoir accès.

Dans les grands environnements chaotiques où les groupes sont nombreux, on risque facilement de s'égarer si l'on ne fait pas le tri pour déterminer ce qui doit vraiment être mis en avant.


6. Défaillances des comptes de service et privilèges cachés

Les dépendances liées à l'identité des services sont souvent mal documentées, ce qui explique pourquoi les applications métier peuvent tomber en panne plusieurs jours après une migration. Mais les problèmes liés aux comptes de service ne se limitent pas à des questions de disponibilité. Ils révèlent souvent des mots de passe obsolètes, des droits excessifs, des dépendances non documentées et des chemins d'authentification que personne n'avait prévu de conserver.

Si vous ne configurez pas correctement les comptes de service, ne mettez pas à jour les listes de contrôle d'accès (ACL) sur les services et les objets COM, et ne tenez pas compte des identités gérées par le système, vous risquez d'arrêter la source et de vous rendre compte trop tard que des applications critiques de la cible en dépendent toujours. À ce stade, la « migration terminée » se transforme en « perturbation des activités en cours » — et d'anciens privilèges peuvent encore être intégrés dans la couche de services.


7. Conflits d'identités et erreurs de mappage

Une logique de mise en correspondance défaillante peut entraîner de dangereuses confusions d'identité. Prenons un exemple simple : associer le PDG d'une société rachetée à une personne portant un nom similaire au sein de l'environnement cible. La mauvaise personne risque alors d'hériter d'un pseudonyme, d'une adresse e-mail ou d'appartenances à des groupes qui ne lui reviennent pas.

Il ne s'agit pas seulement d'une question d'organisation des répertoires. Un mauvais mappage des objets entraîne des accès inappropriés, la divulgation de données et des problèmes d'authentification difficiles à retracer, qui sapent la confiance dans l'ensemble de la migration.


8. Une coexistence qui aggrave les conséquences d'une violation

La connectivité pendant la phase de migration peut amplifier l'impact d'une intrusion. Si la source et la cible ne sont pas suffisamment isolées pendant la période de coexistence, l'infrastructure de migration elle-même peut servir de passerelle aux attaquants pour étendre la compromission de l'ancienne forêt à la nouvelle.

La coexistence est utile sur le plan opérationnel, mais elle peut s'avérer dangereuse si on la considère comme fiable par défaut. Une forêt reconstruite n'est pas automatiquement une forêt sécurisée.


9. Lacunes en matière de conformité et d'audit

Lorsque les auditeurs demandent qui avait accès au système pendant la migration, pourquoi les autorisations ont été modifiées ou quand l'historique des SID a été ajouté, « nous ne savons pas » n'est pas une réponse acceptable.

Si la migration ne s'accompagne pas de processus vérifiables et de rapports clairs, les équipes de sécurité ne peuvent pas prouver qu'elles maîtrisent les modifications d'identité. Cela rend particulièrement difficile les échanges avec les auditeurs, les équipes juridiques et les assureurs cyber, qui exigent des preuves et non des suppositions.


10. Lacunes en matière d'analyse judiciaire après la mise en service

La journalisation est indispensable pendant la migration. Si une activité suspecte est détectée plusieurs semaines plus tard et que les journaux sont incomplets, obscurs ou manquants, vous ne serez plus en mesure de reconstituer le déroulement des événements ni de déterminer comment l'attaquant a pu s'introduire dans le système.

Si vous ne pouvez pas quantifier le chemin d'attaque avec certitude, vous ne pouvez pas non plus prouver que vous l'avez comblé. C'est une position difficile à défendre après un incident.


11. Une nouvelle forêt aux vieilles portes dérobées

Ces risques plus généraux découlent tous de la même erreur : reporter les défauts parce que personne ne veut rien changer pour l'instant.

Les comptes inactifs, les identifiants SID orphelins et les configurations douteuses survivent au transfert. La dette de sécurité reste cachée jusqu’à ce qu’un audit ultérieur, un projet cloud ou une violation de données vienne mettre le problème en évidence.

Et c'est là l'hypothèse la plus dangereuse de toutes : croire qu'une forêt reconstituée est sûre simplement parce qu'elle est nouvelle. Le véritable test d'une migration AD ne consiste pas à vérifier si les utilisateurs peuvent se connecter le lundi. Il s'agit plutôt de déterminer si le nouvel environnement est nettement plus difficile à compromettre que celui qu'il a remplacé.


Faites de votre migration Active Directory une transformation en matière de sécurité

Les migrations vers AD constituent l'une des meilleures occasions qui s'offrent à une entreprise pour réduire les vecteurs d'attaque, éliminer les vulnérabilités héritées et moderniser la sécurité des identités. Mais cela n'est possible que si la sécurité est intégrée dès le départ au plan de migration, et non pas considérée comme une simple tâche de mise au point à effectuer après la bascule.

Si votre entreprise prévoit une migration Active Directory, l'intégration d'une fusion-acquisition ou un projet de modernisation de la forêt, c'est le moment de déterminer si vous vous contentez de déplacer votre infrastructure ou si vous comptez améliorer sensiblement votre niveau de sécurité.

Chez Semperis, nous considérons la migration comme un événement de sécurité, et non comme un simple transfert de systèmes. Nous aidons les entreprises à réduire les risques liés aux systèmes hérités pendant la migration, plutôt que de les reporter et d'en payer le prix plus tard. Découvrez nos services de migration Active Directory.


En savoir plus sur la migration réussie vers AD