ADMT Compatibilité Windows Server 2016

Bonjour,

Petit article sur le retour d’expérience du produit ADMT avec des serveurs AD 2016.

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 client 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.

 

Transition ADMT

 

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 champ SID History à 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://connect.microsoft.com/site1164/program8540

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.
  • Établisser 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ésactiver 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:no

Sur 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.

Ajouter le dans le groupe Builtin Administrators et Administrateurs du domaine de la forêt cible.

Ajouter 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 🙂

 

 

About the Author

Damien CHARBONNEL

No Comments

Laisser un commentaire

This blog is kept spam free by WP-SpamFree.