Migration des comptes utilisateur

test. Cette option,
qu ‘ aucundes
autres wizards ne
propose, permet
de configurer tous
les paramètres
concernant la migration
des utilisateurs,
le test de la migration et la visualisation
d’un rapport montrant les
éventuels problèmes potentiels. Je
conseille d’exécuter le wizard en mode
test afin de pouvoir éliminer d’abord
les problèmes concernant la migration
des comptes utilisateur puis de passer
aux étapes de configuration de migration
des mots de passe (que je décris
dans la section suivante), puis d’exécuter
à  nouveau le User Account
Migration Wizard pour procéder à  la
migration des comptes utilisateur et
des mots de passe.
Ensuite, le User Account Migration
Wizard vous demande de fournir les
domaines source et cible. A noter que
le wizard ne recherche que les domaines
AD et n’inclut pas le domaine
NT 4.0 avec lequel nous avons établi
une relation de confiance dans la boîte
déroulante des domaines disponibles.
Vous devez taper le nom du domaine
NT 4.0.
L’écran suivant sert à  sélectionner
les comptes utilisateur. En cliquant sur
Add, on ouvre une boîte de dialogue
succincte pour sélectionner les objets
AD. Si vous ne voulez pas taper le nom
de chaque utilisateur, cliquez sur
Advanced pour voir une boîte de dialogue
Select Users étendue, illustrée figure
2. Cliquez sur Find Now pour
dresser la liste de tous les comptes présents
dans le domaine cible. Malheureusement,
vous ne pouvez pas éliminer
par filtrage les comptes intégrés
comme Administrator et Guest, donc
vous devez soit éviter de sélectionner
ces comptes, soit les enlever de la liste
quand vous revenez au wizard.
Après avoir sélectionné les
comptes à  faire migrer, l’étape suivante
consiste à  vérifier l’emplacement dans
le domaine cible, dans lequel vous voulez
créer ces comptes. Le wizard affiche
le FQDN de l’emplacement et vous
pouvez modifier l’OU (organizational
unit) cible pour les comptes.
Une fois l’emplacement spécifié,
l’écran suivant, illustré figure 3, vous
permet de préciser la manière de traiter
les mots de passe des comptes utilisateur.
L’option par défaut, Complex
passwords, crée de nouveaux mots de
passe complexes fondés sur une suite
de caractères aléatoires. Vous pouvez
aussi choisir de créer des mots de
passe identiques aux noms de
comptes. Dans les deux cas, le wizard
crée un fichier historique qui associe
chaque compte utilisateur à  son nouveau
mot de passe et vous devrez demander
aux utilisateurs de changer
leurs mots de passe après s’être
connectés au domaine. Troisième possibilité
: transférer les mots de passe
des comptes utilisateur à  partir du domaine
source ; mais, tant que vous
n’aurez pas effectué les étapes décrites
dans la section suivante de cet article l’option Migrate password ne sera pas
vraiment disponible. Si vous la sélectionnez
et cliquez sur Next, vous obtiendrez
des messages d’erreur. Pour
l’instant, acceptez les valeurs par défaut
et passez à  l’écran wizard suivant.
L’écran suivant présente des options
d’activation de compte, comme
le montre la figure 4. Je conseille de sélectionner
l’option Target same as
source afin que ADMT crée des
comptes dans le domaine cible avec le
même état d’activation qu’ils ont dans
le domaine source. Ce paramétrage garantit
que même si vous faites migrer
par inadvertance un compte non souhaité
et désactivé, le compte restera
désactivé. Vous pouvez aussi choisir de
confier à  ADMT le soin de repérer les
comptes source pour la désactivation.
Une autre option de l’écran permet de
faire migrer les SID des comptes utilisateur.
Par défaut, quand ADMT crée
un compte utilisateur dans le domaine
cible, AD attribue un nouveau SID au
nouveau compte et déconnecte du
nouveau compte les privilèges et limitations
de l’utilisateur, comme défini
dans le domaine source. Le fait de sélectionner
l’option Migrate user SIDs
to target domain copie le SID d’un
compte source dans un historique associé
au nouveau compte. Windows
utilise ensuite cette valeur historique
pour lier le nouveau à  l’ancien et permettre
à  l’utilisateur de maintenir les
mêmes privilèges et limitations qu’il
avait dans le domaine source. En sélectionnant
cette option on déclenche
aussi certaines exigences d’audit, que
le wizard active automatiquement sur
les domaines source et cible. On l’aura
compris, la migration des SID est judicieuse
si l’on veut des privilèges dans
le domaine cible pour les mêmes
groupes qui sont définis dans le domaine
source.
Le choix de faire migrer les SID
ajoute une étape supplémentaire au
processus : le wizard vous demande de
fournir des références administrateur
valides pour le domaine source (IKDOM01).
En effet, ADMT a besoin de
références explicites parce que l’accès
aux SID des comptes est une opération
privilégiée.
L’écran User Account Migration
Wizard suivant, que montre la figure 5,
vous permet de définir d’autres options
utilisateur, y compris deux options
importantes liées aux groupes.
Sélectionnez la première option –
Migrate associated user groups – pour
faire migrer, en même temps que les
comptes utilisateur, les groupes custom
définis dans le domaine source
que vous n’avez pas définis dans le domaine
cible. Sélectionnez aussi la sousoption
d’accompagnement – Update
previously migrated objects – pour informer
ADMT de ceci : après qu’il ait
créé un groupe custom pour le premier
utilisateur migré qui est un
membre du groupe, il doit mettre à 
jour ce groupe plutôt que d’en créer
un nouveau quand il fait migrer
d’autres utilisateurs dans ce groupe.
ADMT maintiendra automatiquement
les appartenances des utilisateurs dans
les groupes custom ; si vous faites aussi
migrer les SID, toutes les permissions
resteront en l’état.
L’option associée au second
groupe est Fix user’s group memberships
qui attribue les comptes utilisateur
aux groupes existants appropriés
dans le domaine cible, d’après leur appartenance
au domaine source. (De ce
fait, fix dans ce cas signifie rattacher
plutôt que réparer.) Par exemple, si un
compte utilisateur appartient au
groupe Domain Administrators dans
IKDOM01, le nouveau compte aura
une appartenance dans le groupe
Domain Administrators dans IKDOM02
après la migration. ADMT est
suffisamment malin pour ne pas créer
des doubles de tels groupes intégrés
(lors de la migration des groupes) et il
vous permet de choisir si oui ou non
de telles attributions doivent être
transférées automatiquement.
Le dernier écran vous demande de
définir une option par défaut pour
renommer les éventuels comptes utilisateur
qui dupliquent des comptes
existants dans le domaine cible. Cela
fait, cliquez sur Finish pour commencer la migration ou pour tester le processus
de migration. Pendant la migration,
une fenêtre d’état montre ce que
le wizard a fait migrer et les éventuelles
erreurs survenues. Le wizard génère
aussi un fichier log que vous pourrez
examiner au terme de la migration. Ce
fichier log n’est disponible que jusqu’à 
ce que vous fermiez l’affichage du wizard.
Une fois l’affichage fermé, vous
ne pourrez accéder qu’aux rapports
générés par ADMT.