Lorsqu'on aborde la restructuration d'un système d'information, la fusion d'entreprises ou la consolidation de domaines, l'outil historique ADMT (Active Directory Migration Tool) de Microsoft vient immédiatement à l'esprit. Gratuit et éprouvé, il a accompagné des générations d'administrateurs système.
Pourtant, le paysage de la cybersécurité a radicalement changé. Entre les anciennes infrastructures (comme Windows Server 2008) et les versions modernes telles que Windows Server 2025 ou Windows 11, un fossé technologique s'est creusé. Appliquer aveuglément les anciennes méthodes de migration expose aujourd'hui l'entreprise à des risques majeurs ou à des blocages techniques stricts.
Voici une analyse technique approfondie des limites d'ADMT en 2026, des mécanismes de sécurité sous-jacents et des alternatives modernes à adopter.
1. Pourquoi ADMT bloque sur Windows Server 2025
Le cœur du problème ne réside pas dans l'interface d'ADMT, mais dans les protocoles d'authentification qu'il utilise en coulisses. Pour effectuer la migration des objets, la copie des mots de passe (via le service PES - Password Export Server) et surtout la liaison des machines, ADMT s'appuie sur des mécanismes d'architecture anciens.
Le problème critique de NTLMv1
ADMT nécessite le forçage du protocole NTLMv1 pour certaines opérations de communication inter-domaine lors des phases de transition. Or, Microsoft a entamé une guerre sainte contre NTLM au profit de Kerberos. Dans Windows Server 2025 et Windows 11, la sécurité par défaut a été considérablement durcie:
-
Les versions obsolètes de NTLM (notamment NTLMv1) sont désactivées ou totalement supprimées au niveau du noyau de sécurité.
-
Tenter de faire fonctionner ADMT pour la migration complète de serveurs ou de postes de travail modernes impose de modifier vos stratégies de groupe (GPO) pour abaisser volontairement le niveau de sécurité global de votre infrastructure (réactivation de protocoles vulnérables aux attaques par relais).
Une régression inacceptable dans un contexte de production moderne.
Si ADMT reste partiellement fonctionnel pour transférer des objets simples (utilisateurs, groupes) et leurs autorisations de base (grâce au SID History), il devient un véritable chemin de croix pour la migration des postes de travail et des serveurs récents.
2. Focus technique : SID History et Security Translation
L'un des grands points forts d'ADMT reste sa capacité à gérer la Translation Security et le SID History.
Lorsqu'un utilisateur est migré du domaine source vers le domaine cible, son identifiant unique (SID) change. Pour éviter que l'utilisateur ne perde instantanément l'accès aux serveurs de fichiers du domaine source après sa migration, ADMT attache l'ancien SID dans l'attribut sIDHistory du nouveau compte.
L'étape de Security Translation consiste ensuite à balayer les listes de contrôle d'accès (ACL) des serveurs de fichiers pour remplacer ou ajouter les nouveaux SID du domaine cible. Bien que cette étape fonctionne sur les serveurs de stockage traditionnels, la dépendance d'ADMT vers des instances SQL Server obsolètes ou des configurations RPC non chiffrées complique son installation sur Windows Server 2025.
3. L'alternative terrain : ForensiT pour les postes clients
Face aux blocages d'ADMT sur les systèmes d'exploitation modernes, la stratégie de migration doit être hybride. Pour la migration des postes clients, l'utilisation d'un outil tiers comme ForensiT (User Profile Wizard) s'impose comme l'alternative la plus pertinente et sécurisée.
Contrairement à ADMT qui tente de manipuler l'objet à distance via des protocoles réseau historiques, ForensiT s'exécute localement (ou via script) sur le poste client. Il reconfigure le profil utilisateur local existant pour le lier au nouveau compte du domaine cible, sans altérer les données de l'utilisateur et sans nécessiter la dégradation des paramètres NTLM de votre réseau. C'est une solution validée sur le terrain pour sa fluidité opérationnelle et son respect des barrières de sécurité modernes.
4. Boîte à outils du SysAdmin : Scripts de diagnostic
Avant de lancer votre migration, vous devez auditer votre niveau de sécurité NTLM et suivre l'état de vos utilisateurs migrés.
Script 1 : Auditer l'authentification NTLM sur vos serveurs
Ce script PowerShell vous permet de vérifier le niveau de compatibilité LAN Manager défini dans le registre de vos serveurs pour vous assurer qu'NTLMv1 n'est pas activé par erreur ou pour mesurer l'impact avant blocage.
# Vérification du niveau de compatibilité LM (LanManagerAuthenticationLevel)
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$ParamName = "LmCompatibilityLevel"
if (Test-Path $RegPath) {
$Value = Get-ItemProperty -Path $RegPath -Name $ParamName -ErrorAction SilentlyContinue
if ($Value) {
Write-Host "Niveau LM actuel : $($Value.LmCompatibilityLevel)" -ForegroundColor Cyan
if ($Value.LmCompatibilityLevel -le 2) {
Write-Warning "Attention : NTLMv1 est potentiellement autorisé (Niveau <= 2). Risque de sécurité."
} else {
Write-Host "Configuration conforme aux standards modernes (NTLMv2 ou Kerberos requis)." -ForegroundColor Green
}
} else {
Write-Host "Le paramètre LmCompatibilityLevel n'est pas défini (Comportement par défaut du système)." -ForegroundColor Yellow
}
}
Script 2 : Identifier les utilisateurs possédant un SID History
Après une phase de migration d'objets, utilisez ce script pour lister tous les comptes du domaine cible qui s'appuient sur l'attribut sIDHistory pour accéder aux ressources du domaine source.
# Requiert le module ActiveDirectory
Import-Module ActiveDirectory
Write-Host "Recherche des utilisateurs avec un historique de SID actif..." -ForegroundColor Option
$MigratedUsers = Get-ADUser -Filter 'SIDHistory -like "*"' -Properties SIDHistory
foreach ($User in $MigratedUsers) {
[PSCustomObject]@{
SamAccountName = $User.SamAccountName
CurrentSID = $User.SID
SIDHistory = $User.SIDHistory -join ", "
}
}
5. Références officielles Microsoft pour approfondir
Pour valider vos choix d'architecture et documenter vos livrables de migration, appuyez-vous sur le référentiels officiels de l'éditeur :
Conclusion
En 2026, l'outil ADMT ne peut plus être la réponse universelle à un projet de migration Active Directory. S'il conserve une utilité pour la copie initiale des objets structures (comptes/groupes), l'obligation de dégrader la sécurité réseau pour migrer des machines distantes doit vous pousser vers des alternatives modernes comme ForensiT. La clé d'une migration réussie réside désormais dans la capacité à faire cohabiter l'agilité technique et le respect absolu des politiques de sécurité.
