Avant-propos
Attention, le produit ADMT 3.2 a été installé sur un serveur Windows 2012 R2, l’article ne parle pas du produit installé sur un serveur Windows 2016 mais bien du transfert d’objets vers un domaine de niveau fonctionnel AD 2016.
Officiellement, il n’y a pas de support de la part de Microsoft pour la migration de comptes, de groupes ou de comptes machines vers un environnement AD en génération 2016 : niveau forêt AD et domaine en Windows 2016 (donc ne comprenant que des contrôleurs de domaines de génération Windows 2016).
Dans le cadre d’une migration chez un groupe souhaitant rationaliser différentes forêts en une seule. Nous avons dû tester la compatibilité du produit ADMT entre une forêt source en AD 2008R2 et en cible AD 2016.
Résultats: Nous n’avons rencontré aucun problème de transfert de comptes vers les DCs 2016 🙂
Les options de génération du SID History et de transfert des mots de passe ont été cochés.
Les comptes sont bien transférés avec tous les attributs remplis (évidemment sauf ceux exclut de base par ADMT, voir documentation). Le champs SID History a bien été rempli avec le SID du compte de l’ancien domaine –> Ceci permettra de s’authentifier sur les ressources qui n’ont pas été migrées dans la forêt source (Serveur de fichiers, applications métiers…).
Le mot de passe de l’utilisateur est bien identique, mais malheureusement le produit ADMT coche explicitement la case « User must change this password on next logon » (en FR: « Forcer l’utilisateur à changer son mot de passe à la prochaine connexion »), ce qui est vite dérangeant dans le cadre d’une migration transparente des utilisateurs.
Heureusement une petite commande PowerShell résout le problème rapidement. Exécuter la commande ci-après pour décocher la case de tous les utilisateurs présents dans l’UO. Par exemple, si les nouveaux comptes utilisateurs migrés arrivent dans l’OU MigratedUsers/Cible.local :
Get-ADUser -filter * -searchbase "OU=MigratedUsers,DC=Cible,DC=Local" | Set-ADUser -ChangePasswordAtLogon:$false
Pour que la migration se passe de façon optimum, il est important que les points suivants soient respectés en prérequis. Ces points sont abordés dans le guide ADMT (Page 46):
- Prendre la dernière version d’ADMT 3.2 et lire tout le guide ADMT 😊 (nécessite de s’inscrire sur le site de Microsoft) : https://www.microsoft.com/en-us/download/details.aspx?id=56570
ADMT Guide (ici: ADMTV32MigGuide )
- Installer le produit sur une VM dédiée avec sa base SQL Express pour optimiser les performances
- Mettez en place des DNS croisés inter domaines afin que tous les DCS et ordinateurs du domaine puissent communiquer librement entre le nouveau et l’ancien domaine.
- Etablissez une relation d’approbation bi directionnelle au niveau du domaine et non de la forêt afin de pouvoir ensuite désactiver le SID History (impossible en mode Forêt).
Désactivez le SID History le temps de la migration (cette option pose un problème de sécurité sur le long terme….) . Il faut utiliser la commande netdom.exe:
Sur un DC du domaine de destination :
netdom trust {FQDN of target domain} /domain:{FQDN of source domain} /enablesidhistory:yes
netdom trust {FQDN of target domain} /domain:{FQDN of source domain} /quarantine:noSur un DC du domaine de Source :
netdom trust {FQDN of source domain} /domain:{FQDN of target domain} /enablesidhistory:yes
netdom trust {FQDN of source domain} /domain:{FQDN of target domain} /quarantine:no- Activer les audits des authentifications sur les DCs (GPO Domain Controller). A appliquer sur le domaine source et cible !
Policy -> Computer configuration -> windows settings -> security policy -> local policy -> auditing policy -> Audit Accountmanagement (failure and success)- Activer l’authentification NTLM V2 (GPO Domain Controller). A appliquer sur le domaine source uniquement.
Policy -> Computer configuration -> windows settings -> security policy -> local policy -> security options -> Network Security: LAN Manager Authentication- Créer un compte de service dédié pour la migration (SVC_ADMT par exemple) dans la forêt cible.
- Ajoutez le dans le groupe Builtin Administrators et Administrateurs du domaine de la forêt cible.
- Ajoutez le dans le groupe Builtin ADministrators de la forêt Source.
- Ajouter la clé de registre suivante seulement sur le serveur PDC du domaine source (et redémarrer !) . Pour déterminer facilement le serveur PDC: CMD / netdom query FSMO
REG DWORD
hkey_local_machine\system\currnetcontrolset\control\lsa\tcpipclientsupport à 1- Créer un groupe de sécurité LOCAL (attention surtout pas global ou universel) dans le domaine source avec pour nom :
NOMNETBIOSDUDOMAIN$$$ (3 Dollars de suite)Laissez le groupe vide mais précisez une petite description pour éviter qu’un de vos collègues administrateurs ne le supprime en cas de ménage AD…. Il servira pour faire migrer le SID History.
Par exemple, pour le domaine SOURCE.lan , le nom de groupe sera: SOURCE$$$ .
Attention, à bien vérifier le nom NETBIOS dans les options du domaine, car dès fois celui-ci n’a rien à voir avec le nom DNS!
- Sur le serveur ADMT se logguer avec le compte de service dans le nouveau domaine (CIBLE\svc_admt).
- Créer le certificat de chiffrement entre ADMT et le serveur PES avec la commande :
admt key /option:create /sourcedomain:source.lan /keyfile:keyfile_source_lan.key /keypassword:"Private2017!"- Transférer le fichier sur le serveur accueillant le futur service d’export des mots de passe du domaine source.
- Installer le serveur d’exportation des mots de passe (PES V3.1) en 64 bits ou 32 bits sur un des DC du domaine source. Il n’y a pas de pertinence spécifique à l’installer sur plusieurs DCs sauf si vous voulez profiter de la haute disponibilité.
Préciser lui le certificat de chiffrement avec le mot de passe associé.
- Finaliser l’installation et redémarrer ce DC (nécessaire pour que les DLLs s’inscrivent sur le service Active Directory).
Tester la migration de comptes et groupes utilisateurs et voila !
