ADMT est l’outil de Microsoft qui permet de restructurer les annuaires Active Directory (migration des ressources d’un domaine Active Directory A vers un domaine Active Directory B).
Cet article a pour but de vous présenter 10 retours d’expérience sur cet outil :
- Comment se former sur ADMT ?
- Est-il possible d’utiliser ADMT 3.2 si on dispose de contrôleurs Windows 2012 R2 dans l’annuaire Active Directory source ou dans l’annuaire cible ?
- Quelle édition de SQL Server dois-je utiliser avec ADMT ?
- Quelle est la valeur ajoutée des commandes ADMT USER, ADMT COMPUTER et ADMT GROUP ?
- Pourquoi est-il nécessaire de sauvegarder le serveur ADMT et comme le sauvegarder ?
- Comment configurer les attributs à migrer avec ADMT ?
- ADMT prend-il en charge la migration des données sur une baie NETAPP ?
- A quoi sert l’option « Translate Roaming profile » au niveau de l’assistant de migration d’un compte utilisateur
- Comment migrer les profils itinérants si les données sont hébergées sur un NAS NETAPP ?
- Pourquoi et comment supprimer le SID History ?
Comment se former sur l’outil ADMT ?
Avant de se lancer dans un projet ADMT 3.2, nous vous invitons à lire la documentation officielle disponible à cet emplacement :
Je vous invite aussi à lire cet article qui contient de nombreux retours d’expérience sur l’outil :
Est-il possible d’utiliser ADMT 3.2 si on dispose de contrôleurs Windows 2012 R2 dans l’annuaire Active Directory source ou dans l’annuaire cible ?
La réponse est OUI. Il faut pour cela télécharger la dernière version d’ADMT 3.2 sortie en juin 2014 à cet emplacement : http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx
Quelle édition de SQL Server dois-je utiliser avec ADMT ?
La page 19 du guide ADMT indique qu’il est possible d’utiliser n’importe quelle version de SQL Server : “You can use any version of SQL Server for the ADMT database”.
En réalité, c’est beaucoup plus compliqué !
ADMT 3.0 :
L’installation d’ADMT 3.0 permet de déployer automatiquement SQL Server Express. Avec ADMT 3.2 cette fonctionnalité a été retirée. C’est donc à l’administrateur de choisir la version de SQL Server à installer.
Nous vous invitons à déployer SQL Server Express Advanced car cette édition est gratuite, permet de disposer d’une base de données de 10 Go maximum (suffisant pour ADMT) et de disposer de l’outil d’administration SQL Server Management Studio. Ce dernier permet de sauvegarder la base ADMT, de visualiser son contenu et/ou de la gérer (reconstruction des index, défragmentation en ligne…).
SQL Server Express :
SQL Server Express autorise les connexions distantes (depuis des machines distantes). Cependant comme expliqué à la page 54 du guide de déploiement, l’installation d’ADMT ne prend en charge qu’une base de données SQL Express installée sur le serveur ADMT. Cette contrainte ne s’applique pas à SQL Server Standard / Enterprise (version complète payante).
“If you use SQL Server Express, the ADMT console must be installed and run locally on the server that hosts the SQL Server Express database instance. If you use a full version of SQL Server, you can install and run the ADMT console on a remote computer, and you can run multiple ADMT consoles on different remote computers”. Ce point est aussi évoqué dans l’article ci-dessous :
http://blogs.technet.com/b/askds/archive/2010/07/09/admt-3-2-common-installation-issues.aspx
Si vous souhaitez utiliser les commandes ADMT USER, ADMT GROUP et ADMT COMPUTER, il est nécessaire d’installer ADMT sur un contrôleur de domaine ! En effet dans le cas contraire, il ne sera pas possible de migrer le SID History comme expliqué à la page 82 du guide ADMT.
“When you start a user migration with SID history from the command line or from a script, you must perform the migration on a domain controller in the target domain. It is recommended that you use a full version of SQL Server when you install ADMT on a domain controller.”Il n’est pas recommandé d’installer SQL Server Express sur un contrôleur de domaine. L’installation d’ADMT refuse l’utilisation d’un serveur SQL Server Express distant. En conséquence, pour utiliser les commandes ADMT USER, ADMT COMPUTER et/ou ADMT GROUP, il est recommandé d’utiliser une base SQL Server complète (version Standard ou Entreprise) sur un serveur A et de déployer ADMT sur un contrôleur de domaine B.
Ce dernier devra disposer d’une interface graphique (pas de serveur Core).
Pour plus d’informations sur les différentes éditions de SQL Server :
- http://www.microsoft.com/fr-fr/server-cloud/products/sql-server-editions/sql-server-express.aspx
- http://msdn.microsoft.com/library/cc645993.aspx
Quelle est la valeur ajoutée des commandes ADMT USER, ADMT COMPUTER et ADMT GROUP ?
Ces commandes intègrent les mêmes options que l’interface graphique d’ADMT. Elles permettent cependant :
- D’écrire des scripts de migration avec des actions de pré-migration et de post-migration par exemple.
- A un utilisateur qui ne disposent d’aucun droit dans l’annuaire de lancer les tâches de migration ADMT. Pour effectuer cela, il faut créer des tâches planifiées qui vont lancer les commandes ADMT USER, ADMT GROUP et ADMT COMPUTER dans le contexte du compte de migration ADMT. Pour rappel, le compte de migration ADMT nécessite par défaut des droits Admins du domaine au niveau du domaine source pour migrer le SID History.
Pourquoi est-il nécessaire de sauvegarder le serveur ADMT et comment le sauvegarder ?
Lorsque vous migrez un compte utilisateur avec ADMT, une entrée est ajoutée à la base de données ADMT. Cette entrée associe le SID du compte utilisateur du domaine Active Directory source avec le compte utilisateur du domaine Active Directory cible. C’est le même principe pour la migration des comptes ordinateurs et des groupes.
Lorsque les agents ADMT s’exécute sur les machines pour traduire les permissions au niveau des fichiers / clés de registres, ce sont ces entrées qui sont utilisé par ADMT pour déterminer les permissions / ACL qu’ADMT doit ajouter ou remplacer.
Pour sauvegarder le serveur ADMT, il est nécessaire de sauvegarder la base ADMT. Cette action peut être effectuée avec SQL Server Management Studio. Il est aussi possible d’utiliser Windows Server Backup, l’outil intégré de base dans Windows Server 2008 et versions ultérieures. Je vous invite alors à configurer une sauvegarde complète du serveur sur un disque dédié.
Cela vous permettra de restaurer très facilement le serveur ADMT en démarrant le serveur depuis le DVD d’installation de Windows Server 2008 ou versions ultérieures et en sélectionnant l’option « Réparer ».
En cas de perte du serveur ADMT, si vous ne disposez pas de sauvegarde de la base ADMT, il est nécessaire de migrer de nouveau toutes les ressources (comptes utilisateurs, groupes et comptes ordinateurs). Il n’est heureusement pas nécessaire de supprimer les ressources (comptes utilisateurs, groupes, comptes ordinateur) dans le domaine Active Directory cible car ADMT autorise la fusion avec un compte utilisateur / groupe ou un comptes ordinateur qui existe déjà.
Comment configurer les attributs à migrer avec ADMT ?
ADMT dispose d’une liste d’attribut dit « SYSTEM » exclus par défaut. Il est possible de modifier cette liste à l’aide d’un script fournis par Microsoft disponible à cette adresse :
http://support.microsoft.com/kb/937537/en-us
Attention, il faut utiliser le « CSCRIPT » dans C:windowssysWOW64 pour que le script fonctionne sur une machine 64 bits comme Windows Server 2008 R2.
Pour lancer le script (appelé attributsexclus.vbs), taper la commande suivante :
c:windowsSysWOW64cscript.exe C:_admAttributsExclusattributsexclus.vbs
Par défaut, ADMT exclut les attributs suivants de la migration :
- Mail, OtherMailbox, manager
- LegacyExchangeDN, objectSid, sAMAccountName, Rid, pwdLastSet, userPrincipalName, , managedBy, isCriticalSystemObject, legacyExchangeDN, lastLogonTimestamp, dNSHostName, msDS-AuthenticatedAtDC
- Les attributs userPassword, ObjectSID et Member sont migrés de manière spécifique par ADMT.
En cas d’update de schéma, il est nécessaire de mettre à jour la liste des attributs exclus car les nouveaux attributs seront disponibles par défaut comme expliqué à la page 41 du guide ADMT 3.2.
“The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications. For more information about creating a script to exclude system attributes, see article 937537 (http://go.microsoft.com/fwlink/?LinkId=207024) in the Microsoft Knowledge Base.”ADMT 3.2 prend-il en charge la migration des données sur une baie NETAPP ?
ADMT 3.2 ne supporte pas la traduction des permissions sur des fichiers hébergés sur un NAS NETAPP comme expliqué dans l’article Microsoft ci-dessous :
http://technet.microsoft.com/en-us/library/cc974389%28v=ws.10%29.aspx
Il est cependant possible de contourner cette limitation avec l’outil SUBINACL. Cet outil peut être téléchargé à cette adresse :
http://www.microsoft.com/en-us/download/confirmation.aspx?id=23510
SUBINACL permet :
- D’afficher les permissions (ACL, DACL, SACL) et le propriétaire d’un fichier, d’une entrée de registre.
- De changer les permissions sur un partage de fichiers (partage SMB).
- De Changer le propriétaire d’un fichier, d’une entrée de registre.
- De Remplacer les permissions sur un fichier ou une entrée de registre
SUBINACL dispose de très nombreux paramètres :
- Changedomain=oldDomainName=NewDomainname : permet de remplacer toutes les permissions d’objet d’un domaine source par un objet du domaine cible.
- Migratetodomain=sourceDomain=DestinationDomain : permet de copier les ACL du domaine source en ACL du domaine cible. Les ACL du domaine source sont conservées.
- Suppresssid=DomainNameaccount : supprimer les permissions associés à l’objet domainname account.
- Replace=[DomainName]OldAccount=[DomainName]NewAccount : permet de migrer les permissions d’un objet utilisateur uniquement.
- Cleandeletedsidsfrom : supprime les permissions avec un SID défini.
- Subdirectories C:TEMP* : permet d’analyser tous les fichiers dans le dossier et les sous dossiers de c:Temp.
- Share : permet d’analyser les permissions de partage.
- Subkeyreg : permet d’analyser une clé de registre et tout son contenu (sous-clés ou entrées de registre).
- Le mode /changedomain permet de créer un fichier de mappage. Cela permet de gérer le cas où les ressources auraient été renommées dans le domaine cible.
Pour que SUBINACL traduise les permissions de fichier sur une baie NETAPP, il faut :
- Que les deux domaines disposent d’une relation d’approbation.
- Que l’outil SUBINACL soit lancé depuis une machine membre du domaine source.
- Mapper un lecteur réseau vers le partage du NAS NETAPP. Dans l’exemple ci-dessous, ce lecteur aura la lettre Z.
- Mapper le lecteur Z créé précédemment en tant que Y à l’aide de la commande ci-dessous :
Subst Y: Z:Le lecteur Y apparaît et est vu comme un lecteur local.
- Lancer la commande suivante :
"C:Program FilesWindows Resource KitsToolssubinacl.exe" /subdirectories Z:PARTAGE* /migratetodomain=MSREPORTOLD=MSREPORTNEWDans l’exemple ci-dessous MSREPORTOLD est le nom du domaine NETBIOS du domaine source, MSREPORTNEW est le nom NETBIOS du domaine cible.
A quoi sert l’option « Translate Roaming profile » au niveau de l’assistant de migration d’un compte utilisateur ?
Cette option sert pour les comptes utilisateurs disposant d’un profil itinérant.
Quand on coche cette option, ADMT effectue lors de la migration d’un compte utilisateur les actions suivantes :
- Analyse le champ Profil d’un compte utilisateur. Si ce dernier n’est pas vide, ADMT se connecte sur le dossier réseau.
- ADMT duplique alors les ACL du domaine source en ACL du domaine cible.
- ADMT change le propriétaire du dossier.
- ADMT charge le fichier NTUSER.DAT et modifie les permissions sur les entrées de registre. Il modifie aussi les entrées ProfileImagePath pour associer les profils existants aux comptes utilisateurs du domaine cible.
On retrouve les entrées suivantes dans le fichier de log ADMT.
2014-09-12 13:07:30 Starting Account Replicator.
2014-09-12 13:07:30 CN=Msreportuser1 - Created
2014-09-12 13:07:31 CN=Msreportuser1 - Strong password generated.
2014-09-12 13:07:31 WRN1:7874 Disabled the "password never expires" account option for account 'CN=Msreportuser1'.
2014-09-12 13:07:45 Processing \DC2003BC$ProfilesMsreportuser1.v2
2014-09-12 13:07:45 Updated user rights for CN=Msreportuser1
2014-09-12 13:07:45 Operation completed.Comment migrer les profils itinérants si les données sont hébergées sur une baie NETAPP ?
Deux solutions :
- Le contournement : migrer la machine de l’utilisateur et son compte utilisateur dans le domaine cible. Renommer le dossier correspondant à la copie du profil itinérant de l’utilisateur sur le NAS NETAPP. Recréer uniquement un dossier vide sur le NAS NETAPP. Demander à l’utilisateur d’ouvrir sa session. Lors de l’ouverture de la session, les données sont recopiées vers le partage sur le NAS NETAPP. Attention, cela peut s’avérer très couteux en bande passante !
- La prise de tête : utiliser la commande SUBINACL pour traduire les permissions sur les fichiers et modifier manuellement les permissions sur les entrées de registre et modifier les entrées ProfileImagePath dans le fichier NTUSER.DAT pour réassocier les utilisateurs avec le bon dossier profil.
Pourquoi et comment supprimer le SID History ?
Lorsque l’utilisateur ouvre une session, Windows génère un TGT avec les SID / SID History du compte utilisateur et de tous les groupes auxquels l’utilisateur appartient directement ou indirectement (utilisateur membre du groupe A qui est membre du groupe B qui est membre du groupe C).
Hors la limite maximum est de 1014 SID par TGT après modification de la clé MaxTokenSize. Je vous invite à lire cet article Microsoft qui traite du problème :
Il n’est pas possible de supprimer le SID History avec l’outil ADMT ou via ADSIEDIT.MSC. Pour effectuer cette action, il faut :
- Télécharger les outils ADFIND et ADMOD et les installer dans le dossier c:_admtools sur le serveur ADMT. Ils sont disponibles à ces adresses :
- Lancer PowerShell et taper la commande suivante pour supprimer le SID History pour l’utilisateur Guillaume MATHIEU
C:_admtoolsadfind -b "CN=Guillaume MATHIEU,OU=USERS,OU=IT,DC=MSREPORT,DC=LAN" sidhistory -adcsv | .AdMod.exe -sc csh –unsafe