Domaines et forêts. Un ou plusieurs ?

la mise en oeuvre de multiples
domaines.

La racine de la forêt doit rester vide. Si vous prévoyez de créer
plusieurs domaines, il vous faudra sans doute garder la racine de la forêt (le
premier domaine créé dans un conteneur d’infrastructure) libre d’utilisateurs
de production. Ce domaine jouant un rôle particulier dans une infrastructure –
celui d’héberger les groupes Enterprise Admins et Schema – il est communément
réservé à  quelques administrateurs approuvés.

Limitez les déplacements vers d’autres approbations. Lorsque
des utilisateurs accèdent à  des ressources dans un domaine autre que celui auquel
ils appartiennent, ils traversent une relation d’approbation (même dans Windows
2000) et encourent une pénalité de performance. C’est pourquoi, une conception
multidomaine, qui oblige les utilisateurs à  faire de fréquents déplacements entre
les relations d’approbation, peut ralentir leur temps de réactivité. C’est en
particulier vrai si les GPO sont créés dans un domaine auquel les utilisateurs
doivent se relier à  partir d’un autre domaine. Pour atténuer les problèmes de
performances dans une grande forêt, vous pouvez créer des relations de  » raccourcis
 » entre les domaines fréquemment accédés, afin de réduire le nombre de tronçons
à  parcourir par une communication entre domaines.

Définissez une stratégie de sécurité pour chaque domaine. Le
domaine reste toujours la limite de sécurité dans Windows 2000. Une stratégie
de sécurité (par exemple le comportement du verrouillage des comptes, la longueur
des mots de passe) doit donc toujours être explicitement définie dans chacun des
domaines, et non pas pour un domaine en pensant qu’elle protègera également les
autres domaines.

Limitez la duplication entre contrôleurs de domaines. Puisque
le domaine est une limite de duplication, il faut envisager la possibilité de
créer de nouveaux domaines pour limiter la quantité de données dupliquées entre
les contrôleurs de domaines – en particulier sur des liaisons WAN lentes. La duplication
des données peut dans une certaine mesure être contrôlée par le biais de la mise
en oeuvre des sites (nous verrons comment plus loin), mais il peut être nécessaire
de partitionner de toutes façons les domaines vraiment étendus à  cause des contraintes
de bande passante du réseau.

Dans presque tous les cas, il faut s’orienter vers une forêt unique dans

une infrastructure AD de production

Combien de forêts faut-il ? C’est une question à  laquelle il est facile de répondre.
Dans presque tous les cas, il faut s’orienter vers une forêt unique dans une infrastructure
AD de production. (Hormis une forêt de test ou de développement servant à  tester
les changements apportés à  AD). Les raisons de privilégier le choix d’une unique
forêt sont très simples. Windows 2000 n’offre aujourd’hui aucun moyen facile d’intégrer
plusieurs forêts dans un même environnement. Souvenez-vous qu’une forêt AD Windows
2000 partage un schéma commun, un Catalogue global (CG) commun et des approbations
de sécurité Kerberos communes. Si une seconde forêt est crée, elle représente
un environnement complètement étranger et il faut dans ce cas créer des approbations
non transitives explicites du type NT 4.0 pour permettre le partage entre les
deux forêts.