Mettre en oeuvre Active Directory

Pour mettre en oeuvre une infrastructure AD, il faut commencer par décider comment
organiser l’espace de noms (c’est-à -dire comment organiser les ressources réseau
dans AD). Dans NT 4.0, les choix pour l’espace de noms sont simples et peu nombreux.
Les domaines ne supportent que deux niveaux de hiérarchie, il n’existe pas de
limites de délégation dans un domaine, et NetBIOS ne supporte pas le nommage hiérarchique.
Avec l’avènement d’AD – service d’annuaire hiérarchique basé sur des concepts
X.500 et utilisant DNS comme service de noms – les choix sont beaucoup plus complexes.
L’espace de noms d’AD a trois niveaux principaux : les domaines, les arborescences
de domaines et les forêts.

Les domaines. Dans AD, tout comme dans NT 4.0, un domaine est
une limite de sécurité. Un domaine AD partage une stratégie de sécurité commune
et les mêmes groupes de sécurité, comme les groupes locaux et globaux de domaines.
Un domaine est également une limite de duplication : AD ne duplique les objets
du domaine A que dans les contrôleurs de domaines du Domaine A.

Les arborescences de domaines. Windows 2000 introduit un nouveau
concept : l’arborescence de domaines. Il s’agit d’une hiérarchie de domaines appartenant
à  un espace de noms DNS contigu. Par exemple, le domaine de niveau supérieur acme.com
peut avoir deux domaines enfants : est.acme.com et ouest.acme.com. A eux trois,
ils forment une arborescence de domaines AD. Acme.com peut aussi créer la filiale
acmebis.com et une arborescence de domaines séparée avec l’espace de noms DNS
acmebis.com.

Les forêts. Nouvelle fonction AD elle aussi, une forêt est un
ensemble réunissant une ou plusieurs arborescences de domaines partageant un schéma
et une limite de sécurité Kerberos. Chaque forêt ne peut avoir qu’un schéma, définissant
les objets et les propriétés AD. Les approbations Kerberos transitives connectent
tous les domaines d’une forêt. Une forêt traite les domaines qui lui sont extérieurs
de la même manière que les domaines NT 4.0 se traitent mutuellement par rapport
aux approbations. S’il existe deux forêts dans une entreprise, il faudra, pour
partager des ressources entre elles, utiliser des relations d’approbation non
transitives, comme c’était le cas dans le bon vieux système NT 4.0. De plus, on
ne peut pas actuellement fusionner deux forêts.

La Figure 1 montre les relations entre domaines, les arborescences de domaines,
et les forêts dans AD. Notez l’approbation Kerberos transitive bi-directionnelle
en place entre acme.com et acmebis.com. Selon une des fonctions caractéristiques
d’AD, les approbations transitives connectent tous les domaines d’une forêt.

En cas d’infrastructure NT 4.0 existante, il faut aussi décider si elle
doit être reproduite ou s’il convient d’améliorer cette structure de domaines

La conception de l’espace de noms logique est un exercice qui permet
de décider le nombre de domaines, d’arborescences de domaines et de forêts dont
on a besoin et comment les nommer. En cas d’infrastructure NT 4.0 existante, il
faut aussi décider si elle doit être reproduite ou s’il convient d’améliorer cette
structure de domaines dans le nouvel espace de noms. Grâce à  la capacité d’AD
de déléguer l’administration par le biais d’unités organisationnelles (UO), le
nombre de domaines devrait en principe être beaucoup plus limité dans un système
Windows 2000 que dans NT 4.0. En outre, lorsqu’il faut créer un nouveau domaine,
ce n’est pas tant par nécessité de déléguer l’administration que pour des questions
de duplication et de sécurité (nous évoquerons brièvement ces problèmes plus loin).

Des facteurs autres qu’un modèle de domaine NT existant, influencent également
la conception de l’espace de noms. Au fur et à  mesure que le nombre de domaines,
d’arborescences de domaines ou de forêts, nécessaires à  une implémentation AD
se précise, il faut aussi prendre en compte d’autres facteurs : politiques et
organisationnels, géographiques et techniques.

Facteurs politiques et organisationnels. La conception de l’espace
de noms respectera-t-elle et préservera-t-elle les frontières politiques existant
dans l’organisation ? Si la réponse est non, il est aisé de comprendre que moins
on veut de domaines, plus il faut faire preuve de compétences diplomatiques. Ne
sous-estimez pas les conséquences politiques résultant de la fusion de plusieurs
domaines existants en un seul.

La conception de l’espace de noms AD devrait essayer de faire abstraction de l’organisation
pour lui permettre de survivre aux caprices de fréquents remaniements d’organisation.
Par exemple, si une grande partie du service commercial de la région Est fusionne
avec le service commercial de la région Ouest, il n’est pas nécessaire de déplacer
des unités organisationnelles ou des utilisateurs entre des domaines. Il suffit
de basculer les utilisateurs d’un groupe d’utilisateurs à  un autre. Autre facteur
à  prendre en compte avec Windows 2000, il est extrêmement difficile de renommer
les domaines et absolument impossible, dans tous les cas, de renommer le domaine
racine de la forêt. Sachez par conséquent, que si votre espace de noms dépend
de votre capacité à  modifier les noms de domaines, vous serez obligé de reconsidérer
votre approche.

Le modèle de support technique – centralisé ou décentralisé – utilisé par une
entreprise affecte la conception des UO. Pour créer une délégation plus granulaire,
il faut, soit créer davantage d’UO, soit utiliser des groupes de sécurité au sein
d’une UO. En choisissant de créer plus d’OU, on risque d’alourdir la tâche, chaque
fois qu’il s’agit d’introduire un changement s’appliquant à  toutes les UO, et
d’augmenter la complexité de l’espace de noms AD. L’utilisation de groupes de
sécurité pour contrôler la délégation exige de comprendre parfaitement le modèle
de sécurité d’AD et ne permet pas de voir sur l’écran où se situent les lignes
de délégation aussi clairement que des UO séparées.

Les facteurs géographiques. Si vous travaillez pour une multinationale
ou une entreprise avec des aspirations internationales, essayez de concevoir votre
espace de noms en prévoyant comment AD pourrait s’étendre au-delà  des frontières
nationales, comment vous traiterez les nouvelles acquisitions ou les structures
de support séparées ?

Facteurs techniques. Microsoft a fait du bon travail en mettant
en oeuvre un service d’annuaire complet dans Windows 2000, mais il reste quelques
problèmes techniques de nature à  influencer la mise en oeuvre de l’espace de noms.
J’en décris brièvement quelques-uns plus loin, mais pour l’instant, sachez qu’il
est indispensable d’avoir de bonnes notions des limites d’AD avant de concevoir
un espace de noms.

Il est indispensable d’avoir de bonnes notions des limites d’AD avant de concevoir
un espace de noms

Il peut être nécessaire également de tenir compte dans sa conception de certaines
autres fonctions de Windows 2000. Par exemple, l’utilisation des Group Policy
objects (Objets stratégie de groupe – GPO) peut influencer la mise en oeuvre de
l’espace de noms AD. C’est pourquoi, avant de prendre les décisions définitives
sur l’espace de noms, il importe de connaître le fonctionnement des Stratégies
de groupe et leur impact sur la conception.