Migrer vers Windows 2003 avec Active Directory Migration Tool Version 2.0

Notons tout d’abord celle qui était la
plus attendue, la migration des mots
de passe.
L’application « Password migration
DLL » permet de migrer d’un domaine
à  un autre, mais aussi d’une forêt à  une
autre en gardant le même mot de
passe. Les domaines sources peuvent
être NT4, Windows 2000 ou Windows
2003. Les domaines cibles doivent être
Windows 2000 ou 2003.
Un jeu de certificat est utilisé entre
les deux domaines pour transférer de
manière sécurisée passer les mots de
passe codés. ADMT utilise un PES
(Password Export Server) sur le domaine
source pour réaliser la migration.
Ce PES est matérialisé par une
DLL qui donne la main au système
pour tourner dans le contexte de la
LSA (Local Security Authority), plutôt
qu’être réalisé directement par ADMT,
ce qui permet de travailler dans un environnement
plus sécurisé. Concrètement,
comment cela se passe-t-il ?
Le PES pourra être installé sur un
contrôleur de domaine du domaine
source (BDC ou PDC). L’ADMT crée un
clone et un mot de passe complexe
temporaire. Il fait alors une requête de
mise à  jour du mot de passe. Celui-ci
est configuré directement par la LSA
sur le PES du contrôleur de domaine
cible. Aucun processus en mode utilisateur
(même pas l’ADMT) ne verra le
mot de passe.
Autre nouveauté, la plupart des
opérations de migration peuvent être
réalisées par interface scriptable ou via la nouvelle ligne de commande :
admt.exe. Un exemple de script est installé
dans le répertoire d’installation de
l’ADMT. Il s’agit du script TemplateScript.
vbs. Toutes les explications
sont précisées dans ce script en commentaire.
On notera toutefois une petite
limitation sur les scripts : ils ne supportent
pas les opérations de retour
arrière comme pourrait le faire le wizard.
Un autre changement concerne les
fichiers de logs. Avec la version précédente,
un seul et unique fichier était
utilisé pour l’ensemble des opérations
de migration réalisé. Désormais, un
nouveau fichier est créé à  chaque
opération. Ce fichier est appelé migration.
log. Quand une nouvelle opération
est réalisée, le fichier migration.
log est renommé pour prendre le
format migrationxxxx.log où xxxx est le
prochain numéro de séquence. Le fichier
le plus récent est celui dont le
numéro xxxx est le plus grand. Par défaut,
le nombre de fichiers de log est limité
à  20. Ce paramètre est modifiable
dans la base de registre sur la clé
HKEY_LOCAL_MACHINE\SOFTWAREMicrosoft\ADMT\LogHistory: 20.
Du nouveau également sur les credentials
nécessaires pour les opérations
de migration : ADMT v1 vérifiait
lui-même que le compte qui exécutait
ADMT était un administrateur des
deux domaines : source et cible. Ce
n’est plus le cas sur la nouvelle version
où cette opération n’est plus effectuée
par ADMT mais par l’operating system
directement.
Autre caractéristique importante
de la version 2, les extensions de traduction
de la sécurité. Celles-ci permettent
de mettre à  jour les ACL des fichiers,
partages ou autres ressources
précédemment migrés d’un domaine
NT4/Windows 2000/2003 vers Active
Directory.
Pour exemple, les profils locaux
étant indexés sur le SID de l’utilisateur,
un utilisateur migré reçoit un nouvel
SID et perdra donc l’accès à  son profil
local. ADMT v2.0 permet grâce au
« Security Translation Wizard » de faire
la translation du profil en l’associant au
nouveau compte utilisateur migré
après la migration des comptes utilisateurs.
Désormais, des exclusions d’attributs
Windows 2000 sont possibles
pour les migrations interforêt. En effet,
une liste d’attributs qui peuvent être
définis pour être exclus dans une migration
de comptes d‘utilisateurs, de
groupes ou d’ordinateurs.
Avec la V2, il n’est plus nécessaire
de fournir des noms d’utilisateur et
mot de passe pour l’agent de dispatch.
Auparavant, ADMT demandait à  l’utilisateur
une authentification utilisée
par l’agent pour reporter ses résultats
à  l’ADMT. Avec le changement d’architecture
des agents, ADMT va à  présent
retrouver les résultats des agents
lui-même. Les demandes d’authentification ne sont donc plus requises.
On a également la possibilité de
passer sur la restauration des memberships.
En effet, une option « Fix users’s
group memberships » (figure 2) a été
ajoutée dans l’assistant de migration
des utilisateurs et des groupes, ce qui
permet de gagner un temps précieux si
l’on n’a pas le souhait de recréer les
groupes dans le nouveau domaine auquel
appartient l’utilisateur migré.
Dans ce cas, on décoche l’option.
Le dernier point sur les améliorations
de la version 2 par rapport à  la
précédente concerne la désinstallation
du domaine source. L’ADMT v1 communiquait
avec le domaine source du
compte référencé sur un ACL (Access
Control Lists) Si le domaine source
n’existait plus, la translation de la sécurité
échouait. A présent, toutes les informations
nécessaires sont stockées
dans la base de données. Résultat : le
domaine source peut être supprimé,
les translations de sécurité continueront
à  fonctionner.