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

Imaginez un peu.

Au cours d'une migration de routine d'Active Directory, tout semble se passer comme prévu. Un compte de service est transféré sans encombre du domaine source vers le domaine cible. Les autorisations semblent correctes. Les appartenances aux groupes sont intactes. L'historique des SID est conservé.

Puis, une semaine plus tard, l'application associée à ce compte commence à présenter des dysfonctionnements intermittents. Au moment où quelqu'un établit le lien entre ces dysfonctionnements et la migration, le service d'assistance compte déjà 40 tickets ouverts. Et personne ne parvient à s'expliquer ce phénomène.

Qu'est-ce qui a changé ? Le compte disposait, à l'origine, de clés Kerberos utilisant uniquement le protocole RC4. Les outils de migration standard ont copié le hachage NTLM. Le domaine de destination — tout nouveau, mis à jour et configuré avec les paramètres AES par défaut — ne dispose d'aucune clé AES pour ce compte.

Et après le 14 avril 2026, les DC mis à jour ne basculeront plus implicitement vers le chiffrement RC4 pour les comptes ne disposant pas d'une configuration RC4 explicite. L'authentification cessera tout simplement.

Si vous menez actuellement un projet de migration, de consolidation ou de gestion des identités basé sur les relations de confiance dans Active Directory qui s'étend au-delà de la date limite d'application de la version RC4 fixée à juillet 2026, ce risque est peut-être déjà présent dans votre environnement.

Dans le blog Comment auditer votre environnement pour le chiffrement RC4, mes collègues Guido Grillenmeier et Rich Peckham fournissent des exemples de requêtes que vous pouvez utiliser comme modèles pour auditer votre environnement et identifier les comptes dépendant de RC4.

Ce dont vous avez besoin maintenant, c'est d'un plan d'action qui vous aide à prévenir ces éventuelles défaillances de compte.


Ce que vous apprendrez dans cet article

  • Où les échecs de migration liés à RC4 sont les plus probables
  • Les types de défaillances pouvant survenir — et les éléments à surveiller
  • Comment évaluer systématiquement votre environnement et identifier les comptes susceptibles de présenter des failles
  • Quels outils gratuits peuvent vous aider dans votre exploration ?
  • Mesures à prendre dès maintenant pour anticiper la transition vers l'AES

Pourquoi les projets de migration sont-ils particulièrement exposés aux modifications apportées à RC4 ?

Le calendrier de suppression progressive de RC4 est bien documenté.

  • Janvier 2026 : Microsoft a introduit l'audit et le RC4DefaultDisablementPhase clé de registre.
  • Avril 2026 : Microsoft a modifié le paramètre par défaut du KDC pour n'utiliser que l'AES pour les comptes qui ne disposent pas de msDS-SupportedEncryptionTypes attribut défini explicitement.
  • Juillet 2026 : Microsoft supprime le mode d'audit et cesse de prendre en charge le RC4DefaultDisablementPhase annuler complètement la clé de registre, de sorte que seuls les comptes bénéficiant d'exceptions RC4 explicites puissent encore recevoir des tickets RC4.

L'article de Semperis consacré à la simulation d'audit décrit en détail la phase de découverte en régime permanent. Ce que cette simulation ne couvre pas, c'est le scénario de migration, dans lequel le risque se manifeste de trois manières spécifiques :

  • Les migrations impliquent le transfert de comptes d'un environnement à un autre. Un compte qui s'authentifie correctement aujourd'hui dans l'environnement source peut échouer dès qu'il est transféré vers un environnement cible où les règles sont plus strictes, même si les règles de l'environnement source sont peu contraignantes.
  • Les outils de migration traitent les informations d'identification de manière asymétrique. Les outils de migration standard copient le hachage NTLM, mais ne copient pas les clés AES. La quatrième partie de la série « AD Hardening » de Microsoft le dit clairement : si le domaine cible ne prend pas en charge RC4, vous devrez réinitialiser le mot de passe du compte dans le domaine cible pour que Kerberos fonctionne. Cela vaut pour tous les comptes dont les clés côté source sont exclusivement au format RC4.
  • Les défaillances sont silencieuses. Les dépendances RC4 en régime permanent se manifestent sous la forme d'événements KDCSVC 201 à 209. Ce n'est souvent pas le cas des défaillances liées à la migration. Celles-ci se présentent plutôt sous forme d'erreurs d'application sans lien apparent avec le type de chiffrement. La cause profonde doit être déduite, et non observée.

Tous ces facteurs font qu'une simple requête PowerShell ne suffit pas. Les équipes chargées de la migration ont besoin d'un processus de découverte structuré.


Quels sont les comptes exposés à un risque d'échec de migration lié à RC4 ?

Avant d'aller plus loin, un petit point de clarification. Les correctifs d'avril 2026 ont été déployés sans provoquer les dysfonctionnements généralisés que certains médias spécialisés avaient anticipés — du moins d'après ce que nous avons pu observer sur le terrain. Dans la plupart des environnements clients, le chiffrement Kerberos configuré est préservé et l'authentification se poursuit normalement.

Cet article ne prétend pas que le ciel va nous tomber sur la tête.
Ce qu'il souligne, c'est qu'un mode de défaillance spécifique et identifiable persiste — et que les basculements liés à la migration sont précisément les événements les plus susceptibles de le mettre en évidence.


Trois situations qui mettent un compte en danger

Les échecs de migration liés à Silent RC4 se produisent généralement lorsque les trois conditions suivantes sont réunies :

  • AES indiqué mais non livré. Le compte msDS-SupportedEncryptionTypes L'attribut est renseigné avec des bits AES ou est nul lorsque la valeur par défaut du domaine est définie sur AES. Le KDC interprète cela comme signifiant « AES est pris en charge » et tente d'émettre des tickets AES pour le compte.
  • Aucune clé AES n'est présente sur la cible. Les clés AES ne sont générées que lorsqu'un mot de passe est défini dans un environnement DFL 2008 ou supérieur. Les comptes présentant le plus grand risque sont les anciens comptes qui n'ont jamais été réinitialisés et les comptes migrés pour lesquels les identifiants ont été copiés sans régénération des clés AES. L'attribut indique « AES », mais les clés indiquent uniquement « RC4 ».
  • Le compte s'authentifie activement via Kerberos. L'échec n'apparaît que lorsque le compte demande un ticket Kerberos. À ce moment-là, le KDC tente d'utiliser AES (conformément à la condition 1), ne trouve aucune clé AES (conformément à la condition 2) et l'authentification échoue. Les comptes inactifs et ceux qui s'authentifient uniquement via NTLM restent invisibles, car cet état de dysfonctionnement n'est jamais déclenché.

Quels sont les types de comptes les plus exposés aux risques ?

Dans la plupart des entreprises, l'ensemble des comptes à risque n'est pas aléatoire. Il tend à se regrouper en cinq types de comptes — des catégories qu'il convient d'aborder lors de toute discussion préliminaire sur la portée du projet avant la migration.

  • Comptes de service hérités datant du déploiement initial d'Active Directory, créés entre 2000 et 2010 et dont les mots de passe n'ont jamais été renouvelés. Il s'agit de la catégorie la plus fréquente parmi les comptes à risque.
  • Comptes auprès de PASSWD_CANT_CHANGE ou DONT_EXPIRE_PASSWORD Les indicateurs UAC sont activés. Ces indicateurs sont étroitement liés aux mots de passe définis lors de la configuration initiale et qui n'ont jamais été modifiés.
  • Systèmes non Windows disposant d'informations d'identification Kerberos stockées localement — hôtes Linux avec des fichiers keytab, serveurs d'applications Java avec des identifiants codés en dur krb5.conf, les appliances NAS jointes au domaine, les périphériques réseau avec des identifiants mis en cache.
  • Comptes de service appartenant à des administrateurs ayant quitté leurs fonctions, pour lesquels les identifiants existent encore, mais dont on ne sait plus exactement à quoi ils servent au sein de l'établissement.
  • Comptes informatiques pour lesquels la rotation automatique des mots de passe ne fonctionne plus : machines hors ligne depuis longtemps, comptes orphelins, comptes avec PasswordNeverExpires mal réglé.

En moyenne, combien de comptes sont susceptibles d'être affectés par RC4 lors d'une migration vers Active Directory ?

D'après l'expérience acquise sur le terrain dans le cadre de projets de migration, la population de comptes à risque dans un environnement donné se situe généralement dans ces fourchettes.

Type d'environnementPopulation moyenne à risque
Environnements « greenfield » mis en place après 2010 et dotés d'une gouvernance rigoureuse en matière d'identité0 à 10 comptes
Entreprise de taille moyenne à grande, disposant d'une expérience d'au moins dix ans dans l'utilisation d'Active Directory20 à 200 comptes
Environnements créés à la suite de fusions-acquisitions sans consolidation d'identité ultérieureDe quelques centaines à quelques milliers
Environnements acquis dans lesquels l'organisation acquéreuse n'a pas encore achevé la rationalisation des identitésTrès variable, dépassant parfois la fourchette des fusions-acquisitions

REMARQUE : il s'agit là de points de départ pour définir le champ d'application des discussions, et non de chiffres précis. La population réelle ne pourra être confirmée qu'à l'issue du travail de découverte que nous allons mener ensemble.


Pourquoi la migration vers Active Directory concentre les risques

Ces comptes dépendant de RC4 peuvent rester actifs en production pendant des années sans présenter de défaillance. Leur authentification Kerberos repose sur des tickets mis en cache et des réauthentifications peu fréquentes, ce qui permet de masquer l'absence des clés AES pendant le fonctionnement normal.

La bascule de migration change la donne. Elle invalide simultanément les identifiants mis en cache pour l'ensemble de la population, impose l'envoi de nouvelles requêtes AS-REQ et TGS-REQ dans un délai très court, et fait apparaître le mode de défaillance précisément au moment où les connaissances des responsables sont obsolètes et où l'analyse des causes profondes s'avère la plus difficile.


Les deux types de défaillance que vous recherchez

Avant d'aborder la méthodologie d'analyse, il est utile de définir les deux catégories distinctes de risques de rupture que vous cherchez à mettre en évidence.

  • Déviation latente de la configuration. Il s'agit des comptes qui semblent fonctionner correctement aujourd'hui, mais qui présenteront des défaillances en cas d'application des règles — c'est-à-dire la population à risque définie ci-dessus. Les attributs Active Directory indiquent une chose, tandis que les clés de chiffrement réelles en indiquent une autre. Cette divergence ne peut être détectée en interrogeant uniquement les attributs Active Directory.
  • Risque lié au mécanisme de migration. Des défaillances qui découlent spécifiquement de la manière dont la migration transfère les données d'identité. Celles-ci n'apparaissent pas dans les données de télémétrie en régime permanent, ni d'un côté ni de l'autre, et comprennent :
    • Dépendances historiques du SID
    • Scénarios à double exécution dans lesquels la même identité logique s'authentifie à partir des deux domaines
    • Valeur cible DFL inférieure à celle de 2008 (se déclenche discrètement à chaque réinitialisation de mot de passe après la migration)
    • Incohérences au niveau des attributs de confiance.

Ces deux catégories nécessitent des preuves pour être identifiées. Aucune d'entre elles ne peut être mise en évidence de manière fiable par des outils qui ne prennent en compte qu'une seule source de données.


Comment se préparer au passage du RC4 à l'AES : une méthodologie de migration en six étapes

Comprendre le contexte dans lequel évoluent vos comptes dépendant de RC4 — ainsi que les types de défaillances potentiels auxquels vous pourriez être confronté — vous fournit un cadre de référence sur lequel vous appuyer tout au long du processus de recensement de ces comptes et de leur configuration pour AES.

Voici la séquence éprouvée sur le terrain que nous utilisons avec nos clients dans le cadre de projets de migration. Chaque phase fournit des éléments qui viennent alimenter la matrice finale des scénarios de rupture.


Phase 0 : Définir le cadre

Avant de rechercher les problèmes, documentez à la fois l'environnement source et l'environnement cible. L'asymétrie entre les deux constitue en soi une source de risque majeure.

Pour chaque domaine, indiquez :

  • Niveau fonctionnel « Forêt et domaine »
  • Version du système d'exploitation de chaque serveur de domaine
  • Dernière mise à jour cumulative
  • La valeur de RC4DefaultDisablementPhase sur chaque contrôleur de domaine (DC)

Il se peut que certains centres de distribution ne disposent pas de RC4DefaultDisablementPhase ou DefaultDomainSupportedEncTypes n'est pas défini du tout. Cela signifie généralement que le paramètre n'est pas configuré explicitement et que le contrôleur de domaine suit le comportement par défaut actuel correspondant à son système d'exploitation et à son niveau de correctifs.

Ce qui importe ensuite, c'est de savoir si ce comportement efficace est cohérent à l'échelle du domaine et entre la source et la cible.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Recherchez les cas d'asymétrie : si un domaine source à DFL 2003 dont la phase n'est pas définie est associé à une cible à DFL 2016 déjà en phase 2, cela signifie que tous les comptes migrés ne disposant pas de clés AES cesseront de fonctionner lors de la bascule.

Remarque à l'attention des centres de données exécutant Server 2012 ou 2012 R2 dont l'ESU a expiré : ceux-ci ne recevront pas les correctifs de juillet 2026 et constitueront des sources RC4 inamovibles.

Si les clés de registre sont manquantes : vérifiez la version du système d'exploitation du contrôleur de domaine, le niveau de correctifs, et si d'autres contrôleurs de domaine du même domaine affichent des valeurs explicites. Le signal d'alerte n'est pas l'absence de la clé en soi, mais un environnement hétérogène où certains contrôleurs de domaine se trouvent effectivement dans un état de fonctionnement donné tandis que d'autres en sont dans un autre.

Considérer les divergences entre la source et la cible comme un signal d'alerte : l'absence de clés dans la source associée à des paramètres de phase explicites dans la cible, ou des valeurs par défaut nulles d'un côté et des exceptions RC4 explicites de l'autre, sont précisément les combinaisons qui masquent les scénarios de rupture de migration jusqu'au basculement.

Documenter la relation de confiance liée à la migration : Une fiducie avec msDS-SupportedEncryptionTypes La valeur 0x4 (RC4 uniquement) constitue un point de rupture garanti en juillet 2026. Une entité de confiance dotée de l'attribut null suit le nouveau comportement par défaut de l'AES et a beaucoup moins de chances d'atteindre ce point de rupture qu'une entité de confiance explicitement verrouillée sur RC4.


Étape 1 : Vérifier que les deux domaines peuvent voir le trafic RC4

On ne peut pas retrouver ce qui n'est pas consigné. Vérifiez l'audit Kerberos sur chaque contrôleur de domaine dans les deux domaines :

      auditpol /get /subcategory:« Service d'authentification Kerberos »
auditpol /get /subcategory:« Opérations sur les tickets de service Kerberos »

Les deux doivent signaler les réussites et les échecs. Si ce n'est pas le cas, appliquez l'objet de stratégie de groupe (GPO) d'audit Kerberos standard à l'unité d'organisation (OU) du contrôleur de domaine avant de poursuivre.

Sur les contrôleurs de domaine (DC) mis à jour jusqu'en janvier 2026 ou après, le journal système devrait également enregistrer les événements KDCSVC du fournisseur numérotés de 201 à 209. L'absence totale de ces événements dans un environnement comportant des applications héritées connues indique généralement une lacune dans la journalisation plutôt qu'un environnement exempt de vulnérabilités ; il convient donc de vérifier l'état des correctifs et la collecte des données avant de conclure à l'absence d'exposition au RC4.

Faites également attention aux cas de visibilité partielle : l'audit peut être activé sur certains contrôleurs de domaine mais pas sur d'autres, les événements peuvent ne provenir que d'une partie du parc, ou les périodes de conservation peuvent être trop courtes pour permettre de détecter les comptes de service à faible fréquence.


Phase 2 : Découverte de la couche de configuration

Cette phase identifie les scénarios de rupture détectables uniquement à partir des attributs AD. La solution la plus rapide est l'open source RC4-ADAssessment Module PowerShell, à exécuter sur les deux domaines :

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

Ce module permet de saisir :

  • Configuration du cryptage DC
  • Chiffrement de confiance
  • Durée de validité du mot de passe KRBTGT
  • Tous les comptes de service marqués comme « RC4 uniquement » ou « DES activé »
  • Comptes auprès de la USE_DES_KEY_ONLY Indicateur UAC
  • Comptes comportant des exceptions RC4 explicites
  • Comptes dont les mots de passe sont périmés

Chaque résultat est exporté avec des commandes de correction prêtes à être copiées-collées. Considérez ce résultat comme une liste de cas prioritaires plutôt que comme une preuve définitive. La phase 2 vous indique les points à examiner, mais ce sont les données d'événements et le contexte de l'application qui permettent de confirmer l'existence d'un véritable problème de migration.

Portez une attention particulière aux comptes de service dont PasswordLastSet date d'avant la mise à niveau du domaine source vers DFL 2008. Il s'agit de candidats hautement prioritaires parmi la population à risque définie ci-dessus ; leur profil doit être vérifié à la lumière des données sur les événements et de leurs antécédents migratoires.


Phase 3 : Découverte comportementale

La configuration vous indique ce qui est autorisé. Les événements vous indiquent ce qui se passe réellement. Il arrive souvent qu'ils ne concordent pas.

Exécutez l'évaluation en activant l'analyse du journal des événements ou interrogez directement Sentinel ou Splunk :

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

Le résultat le plus significatif est la corrélation entre une configuration AES et l'utilisation effective de RC4 : il s'agit des comptes pour lesquels AD indique « Je prends en charge AES », mais dont les journaux d'événements montrent que des tickets RC4 sont émis. C'est précisément ce décalage qui constituera le mode de défaillance susceptible d'apparaître lors de la migration.

En ce qui concerne plus particulièrement les projets de migration, récupérez également les requêtes TGS inter-réaux. Parmi les 4 769 événements, recherchez les tickets de service où ServiceName se trouve dans l'autre monde et TicketEncryptionType est 0x17. Le trafic RC4 inter-domaines sert d'indicateur précoce des défaillances du chemin de confiance lors de la migration sous contrainte, et même les incidents de faible ampleur méritent une enquête approfondie, car l'application concernée peut être essentielle à l'activité.

Pensez également aux comptes de service qui ne s'authentifient que pendant les fenêtres de traitement par lots, les opérations de fin de mois ou les tâches planifiées; ils passent facilement inaperçus lors des fenêtres de collecte courtes et sont souvent à l'origine des surprises les plus désagréables lors de la migration.


Phase 4 : Découverte au niveau de la couche application

C'est là que la plupart des migrations échouent, et que les outils compatibles avec Active Directory offrent le moins de visibilité.

Effectuez une analyse de chaque hôte Linux, Java et appareil réseau utilisant Kerberos basé sur Active Directory.

Répertorier les fichiers keytab; tout ce qui ne contient que arcfour-hmac Les entrées sont verrouillées via RC4. Il faut s'attendre à ce qu'au moins quelques systèmes non Windows utilisent encore des keytabs générés il y a plusieurs années.

Vérifier /etc/krb5.conf pour les valeurs fixes default_tkt_enctypes ou permitted_enctypes en ne mentionnant que RC4. Les deux cesseront de fonctionner après juillet 2026, quelle que soit la décision d'AD — et la mise à jour du keytab pour le domaine cible nécessite que le compte migré dispose de clés AES, ce qui nous ramène aux conclusions de la phase 2.

Pour chaque application utilisant l'authentification Kerberos, guidez le propriétaire à travers les étapes suivantes :

  • Le compte de service actuellement utilisé et son msDS-SupportedEncryptionTypes valeur
  • Où l'application est hébergée
  • Si un keytab est utilisé et quand il a été généré
  • Si la documentation du fournisseur précise les types de chiffrement Kerberos requis
  • Si la pré-authentification utilise le mode RC4-pinned

Il faut s'attendre à des lacunes dans la documentation. De nombreux propriétaires ne sauront pas quand le keytab a été généré ni si le fournisseur prend correctement en charge l'AES, et cette incertitude constitue en soi un indicateur de risque utile.

Recherchez également les configurations de chiffrement codées en dur dans les zones où la découverte des attributs AD ne parvient pas à atteindre la sécurité du réseau :

  • Les Network security: Configure encryption types allowed for Kerberos Paramètres GPO
  • Serveurs liés SQL Server
  • Identités des pools d'applications IIS avec des mots de passe périmés
  • Applications Java avec -Dsun.security.krb5.permitted_enctypes Options de la JVM

Phase 5 : Risques liés à la migration

Les scénarios de rupture que nous allons mettre en évidence au cours de cette phase ne se manifestent que pendant la phase de basculement de la migration. Ils sont inhérents au mécanisme de migration plutôt qu’à l’un ou l’autre des domaines en régime permanent.

Évaluez la gestion des mots de passe par votre outil de migration. Si l'outil copie les mots de passe, il copie toutes les informations d'identification existantes. Un compte ne contenant que des clés RC4 dans l'environnement source se retrouve avec uniquement des clés RC4 dans l'environnement cible. La mesure de sécurité standard — la réinitialisation forcée des mots de passe après la migration — peut perturber le fonctionnement des services dépendants si l'application est en cours d'exécution.

Chaque compte de service doit disposer d'un plan de réinitialisation post-migration documenté, assorti d'une fenêtre de maintenance.

Évaluez objectivement les différentes méthodes de synchronisation des mots de passe. Certains outils de migration proposent des filtres de synchronisation des mots de passe qui détectent les modifications sur les contrôleurs de domaine (DC) sources et les répercutent sur la cible. Ceux-ci résolvent certes le problème de génération de clés AES sur la cible, mais ils :

  • Installer un chemin d'exécution privilégié sur les contrôleurs de domaine source
  • Exposer temporairement du texte en clair en mémoire
  • Ne déclencher l'alerte qu'en cas de modification du mot de passe (en ignorant complètement les comptes inactifs et les comptes de service dont le mot de passe n'est pas renouvelé)
  • S'exposer à un risque opérationnel si le filtre présente une défaillance silencieuse

L'utilisation de tels outils est légitime dans le cadre de périodes de coexistence délimitées où les compromis sont clairement définis et acceptés, mais elle ne saurait se substituer au travail de découverte décrit ci-dessus.

Répertoriez les scénarios de double fonctionnement. Pendant la fenêtre de migration, les utilisateurs et les services peuvent exister à la fois sur le système source et sur le système cible. Identifiez les cas où une même identité logique s'authentifie des deux côtés — généralement dans le cadre de relations de confiance inter-domaines, d'une fédération ou d'un tenant Entra ID synchronisé.

Chacun d'entre eux constitue un point de rupture potentiel, car la négociation du chiffrement varie d'un côté à l'autre.

Répertorier les dépendances liées à l'historique des SID. L'historique des SID préserve l'accès aux ressources ; toutefois, les clés de chiffrement sont indépendantes. Une application qui s'authentifie via l'historique des SID mais qui émet des tickets à l'aide des clés du compte cible peut rencontrer des problèmes si ces clés sont uniquement de type RC4.

Vérifiez que le niveau fonctionnel de domaine (DFL) cible est au moins 2008. Lors de consolidations impliquant des environnements acquis, il arrive parfois que le niveau fonctionnel de domaine (DFL) cible soit inférieur à celui prévu. En dessous du DFL 2008, la réinitialisation des mots de passe ne génère pas de clés AES, ce qui entraîne l'échec silencieux de l'ensemble du plan de réinitialisation post-migration. Effectuez cette vérification avant la bascule, et non pendant celle-ci.

Le véritable risque à ce stade réside dans les combinaisons, et non dans les faits pris isolément. Par exemple :

  • Migrations avec copie des mots de passe sans délai de réinitialisation documenté
  • Identités à double exécution sans vérification chemin par chemin
  • L'historique SID considéré comme une solution d'authentification
  • Un problème lié à la DFL n'a été détecté qu'après la mise en service de la phase pilote

Ce sont ces schémas propres à la migration qui transforment des résultats gérables en scénarios de panne.


Étape 6 : Élaborer la matrice des scénarios de rupture

Le résultat des cinq premières phases n'est pas une simple liste de risques. Il s'agit d'une matrice de scénarios de rupture : une ligne pour chaque cause identifiable d’échec de la migration. Veillez à ce qu’elle reste concise. Pour chaque ligne, décrivez le scénario, ce qui le déclenche, comment il se manifestera et les mesures à prendre avant la bascule.

Les résultats des phases 2, 3 et 4 constituent généralement les premières lignes.

La phase 5 inclut les scénarios de migration uniquement qui n'apparaissent pas dans l'analyse en régime permanent.

Une fois remplie, cette matrice sert de tableau de suivi de la transition et constitue la base de la décision de poursuivre ou d'abandonner le projet.

ScénarioDéclencheur Comment cela se manifesteMesures à prendre avant la mise en service
Compte de service migré avec AES configuré, mais sans clés AESBasculement ou première requête KerberosL'authentification de l'application échoue après la migration ; les tâches planifiées ou les services commencent à échouer une fois que les tickets mis en cache ont expiréRéinitialisez le mot de passe sur le système cible, vérifiez la génération de la clé AES, testez à nouveau l'application et planifiez la mise en œuvre de cette modification pendant une fenêtre de maintenance
Hôte Linux ou Unix avec un keytab utilisant uniquement RC4Mise en œuvre ou basculement vers le domaine cible en juillet 2026L'authentification Kerberos échoue depuis l'hôte non Windows ; le service bascule vers un autre mode ou s'arrêteRégénérer le keytab avec des identifiants compatibles AES après avoir vérifié que le compte migré dispose bien de clés AES
Confiance inter-domaines explicitement liée à RC4Entrée en vigueur en juillet 2026Les demandes de tickets inter-domaines échouent en cas de coexistence ou d'accès par étapesSupprimez le paramètre de confiance « RC4 uniquement » et vérifiez le comportement de confiance à l'aide d'un trafic de test direct avant la bascule
Domaine cible inférieur à DFL 2008Plan de réinitialisation après la migration La réinitialisation du mot de passe semble aboutir, mais les clés AES ne sont jamais générées et l'application continue de ne pas fonctionner Augmenter le DFL cible avant la migration, ou repenser le plan de correction avant le premier projet pilote
Configuration Kerberos en code dur pour Java, les appliances ou les installations locales, utilisant l'algorithme RC4Mise en service, application ou première demande de nouveau ticket Un niveau d'application tombe en panne alors que les paramètres côté AD semblent correctsSupprimer le verrouillage RC4, vérifier la prise en charge d'AES par le fournisseur et tester le chemin d'accès exact de l'application avant la mise en production
Authentification d'identité à double exécution avec des méthodes différentes entre la source et la ciblePériode de coexistence ou vague de migration progressiveLe comportement d'accès varie selon le domaine, l'hôte ou le chemin d'accès, ce qui entraîne des conséquences inégales pour les utilisateurs Documenter le comportement de chaque chemin, réduire les chevauchements dans la mesure du possible et tester explicitement la coexistence des chemins

Ce que vous trouverez réellement

Dans le cadre des projets liés à la migration, les conclusions les plus fructueuses relèvent généralement de quatre catégories :

  • Comptes de service pour lesquels l'AES est configuré mais qui ne disposent pas de clés AES. Il s'agit souvent de comptes anciens qui n'ont jamais été réinitialisés ou de comptes migrés pour lesquels les informations d'identification ont été copiées sans régénération des clés AES. L'attribut AD est erroné. La corrélation des journaux d'événements de la phase 3 est le seul moyen fiable de les identifier. Ce sont également les plus faciles à corriger. Une réinitialisation de mot de passe dans un environnement DFL 2008 ou supérieur génère les clés AES. Il est parfois recommandé d'effectuer deux réinitialisations consécutives avec un délai entre les deux, par mesure de sécurité pour la réplication.
  • Hôtes Linux utilisant des keytabs RC4 uniquement. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL avec GSSAPI — toutes ces solutions sont courantes et génèrent des fichiers keytab en fonction des types de chiffrement disponibles au moment de la génération. La solution consiste à régénérer les clés pour le domaine cible après la migration, mais cela nécessite que le compte migré dispose au préalable de clés AES.
  • Le DFL de l'environnement acquis réserve des surprises. Lorsque la cible est la plus petite des entités acquises, ou lorsque les consolidations se font dans le mauvais sens, le DFL se retrouve inférieur à celui de 2008 et personne ne s'en rend compte avant la mise en service. Vérifiez-le lors de la phase 0 ; revérifiez-le avant chaque vague de migration.
  • Fiducies dotées d'attributs RC4 explicites. Moins courante que les autres, mais d'un impact considérable lorsqu'elle est présente. Une fiducie avec msDS-SupportedEncryptionTypes = 0x4 entraînera l'échec du mécanisme de migration lui-même, et pas seulement de certains comptes.

Si le temps disponible est limité, privilégiez la corrélation de la phase 3 (configuration AES mais utilisation de RC4) et l'inventaire des fichiers keytab de la phase 4. À elles deux, ces étapes permettent généralement d'identifier 60 à 80 % de la liste réelle des comptes compromis.


Outils et ressources

Les tâches de détection décrites ci-dessus peuvent être mises en œuvre à l'aide d'outils open source et de commandes natives d'Active Directory. Voici quelques ressources fiables pour la détection et la correction des comptes dépendant de RC4 ; toutes sont disponibles gratuitement.

Pour les organisations qui mènent cette évaluation dans le cadre d'un projet de migration en cours, Semperis Professional Services met régulièrement en œuvre cette méthodologie en tant que mission préalable à la migration. La communauté des spécialistes de la migration travaille également activement à l'élaboration d'approches visant à réduire les coûts liés aux perturbations subies par les utilisateurs lors de la réinitialisation des mots de passe après la migration — un prochain article abordera ces approches à mesure qu'elles mûriront.


Par où commencer cette semaine ?

Si vous avez un projet de migration prévu pour juillet 2026 et que vous n'avez pas encore commencé les travaux, commencez par suivre ces quatre étapes :

  • Lancez la phase 0 aujourd'hui. Il s'agit d'un exercice de 30 minutes par domaine qui met en évidence les asymétries entre le DFL et l'état des correctifs, lesquelles déterminent tout le reste.
  • Vérifiez que la surveillance est activée dans les deux domaines (phase 1). Si ce n'est pas le cas, corrigez cela cette semaine. Chaque jour où les données de télémétrie font défaut représente un jour de risque de panne que vous ne pouvez pas détecter.
  • Courir RC4-ADAssessment avec -AnalyzeEventLogs pour les deux domaines (phases 2 et 3 confondues). La catégorie de résultats « Configuré pour AES mais utilisant RC4 » est celle qui présente la plus grande valeur.
  • Planifiez les visites sur site avec les responsables des applications pour la phase 4. C'est le maillon faible. Commencez dès maintenant et menez-les en parallèle avec toutes les autres tâches.

La transition vers le nouveau système et la date limite d'application fixée à juillet 2026 sont deux événements distincts. Le travail de préparation qui vous permet de vous adapter à l'un vous prépare également à l'autre.

Commencez dès maintenant et la matrice que vous créerez servira de tableau de bord opérationnel pour les deux.

Vous avez des questions sur cette méthodologie ou sur la manière dont Semperis peut vous aider dans le cadre d'un projet de migration en cours ? N'hésitez pas à nous contacter : nous sommes là pour vous aider.