par Stephen Downes et Pat Telford - Mis en ligne le 17/06/2002
Si vous devez recréer 10.000
comptes utilisateur, modifier 8.000 stations
de travail sur 30 sites, et reconstruire
200 serveurs sans que les utilisateurs
en tirent un avantage immédiat,
ce que vous pouvez espérer de mieux
est qu'ils s'aperçoivent à peine que
vous avez fait quelque chose.
Bienvenue dans le monde ingrat de
l'intégration d'infrastructure ...
Peu d'entreprises ont un environnement
limité un seul domaine à partir
duquel elles peuvent facilement migrer
vers une implémentation
Windows 2000 de type forêt unique/
domaine unique propre et nette. Les
acquisitions d'entreprise, les contraintes
de bande passante, les exigences
administratives, et la politique laissent
souvent un micmac de domaines et de
relations de confiance. Le plus souvent,
par conséquent, la première
étape du passage à Win2K est un sousprojet
chargé de fusionner les domaines
NT 4.0 Windows existants et
d'éliminer les désordres qui se sont accumulés
en chemin. Nous sommes
passés par ce cycle de migration et
pouvons vous guider au travers de
quelques écueils de l'intégration de
domaines, avec quelques techniques
utiles pour perturber le moins possible
les utilisateurs.
Les principes à appliquer pour une bonne fusion de domaines NT 4.0 sont
pratiquement les mêmes que ceux
d'une migration de NT 4.0 à Win2K.
Donc, endossez la cape de l'homme invisible
et commencez la fusion.
Dans NT 4.0, on ne peut pas simplement
déplacer un compte utilisateur
d’un domaine dans un autre. Chaque
compte utilisateur, groupe global,
groupe local, et station de travail dans
le domaine a un numéro unique, appelé
SID, lié au domaine. Un SID est
constitué d’un préfixe commun pour
l’ensemble du domaine, suivi d’un suffixe
unique pour le compte, appelé RID (Relative Identifier). Comme les
comptes sont associés à un domaine
particulier, on ne peut pas les déplacer
entre domaines. Pour changer de domaine,
il faut recréer à partir de zéro
dans le domaine cible, chacun des
comptes utilisateur, comptes de
groupe et comptes d’ordinateur du
domaine source. Ces nouveaux
comptes doivent conserver les propriétés
des comptes d’origine.
Win2K et la sécurité NT 4.0 utilisent
le SID d’un compte plutôt que son
nom. On trouvera des références aux
SID dans les entrées ACL. Le type
d’ACL le plus visible est la liste des autorisations
appliquées à un fichier ou à
un dossier, mais les SID apparaissent
aussi ailleurs. L’encadré « Savez-vous
où se trouvent vos SID ? » fournit la liste des emplacements de références SID.
Malheureusement, la prolifération
des SID fait que chacun de vos domaines
NT a probablement des centaines
de milliers, voire des millions de
références SID. Et, bien entendu, il faut
ajouter les mêmes autorisations pour
chaque compte nouvellement créé (et
chaque nouveau SID) dans le domaine
fusionné à chaque ACL sur lequel le
SID de l’ancien compte apparaissait. Il
faut donc un outil pour traiter les références
SID dans votre domaine pendant
la migration. Nous verrons les outils
de migration plus loin dans cet
article.
Téléchargez cette ressource
Guide Adobe Firefly, l’IA générative dédiée aux équipes créatives
Depuis plus d’une décennie, Adobe exploite l’intelligence artificielle (IA) pour proposer des solutions toujours plus performantes et innovantes aux équipes créatives. Comment le nouveau moteur d’IA générative Adobe Firefly permet-il aux entreprises de développer leurs capacités créatives et de tirer, dès à présent, tout le profit de l'IA générative ?
