Cet article est le troisième d’une série traitant d’un thème bien connu de tout SysAdmin qui se respecte (sauf les full linuxiens of course :-D), j’ai nommé : Active Directory (AD) !
Cette série est uniquement un survol du fonctionnement d’un AD et des éléments importants qui le composent car le sujet est extrêmement vaste… Cette petite “introduction à Active Directory” a été divisée en plusieurs parties car les notions ne sont pas toujours faciles à digérer…
Bon courage ! 
Sommaire :
1/8 – Introduction : Qu’est ce qu’Active Directory ?
2/8 – Comprendre la notion de domaine Active Directory
3/8 – Contrôleur de domaine et catalogue global
4/8 – Rôles FSMO
5/8 – Structure d’un domaine et unités organisationnelles
6/8 – Stratégies de groupe
7/8 – Gestion des groupes sous Active Directory
8/8 – Conclusion : l’Active Directory, l’épine dorsale d’une infrastructure
Contrôleur de domaine et catalogue global
Chaque domaine d’une forêt possède une copie de l’Active Directory (donc une copie de son propre domaine) sur un serveur appelé un « contrôleur de domaine ». Un contrôleur de domaine (DC) c’est le serveur Active Directory où seront stockées toutes les informations et paramètres dudit domaine, dans une base de données.
Un domaine ne connait que les ressources de son propre domaine dont voici pour rappel une illustration logique cette fois ci en triangle :
Dans le cas d’une entreprise avec plusieurs sous-domaines par exemple, ceci peut être problématique car cela signifie que tous les employés n’auront pas à accès aux mêmes ressources.
Imaginons qu’un serveur de fichiers soit sur le domaine Google.com. Les employés du sous-domaine google.paris.com n’y auront pas accès car le sous-domaine google.paris.com ne connait pas les ressources du domaine google.com !
Pour répondre à ce problème, Microsoft a mis en place le catalogue global. Un catalogue global (GC) fonctionne comme un index géant au niveau de toute la forêt et est situé sur le contrôleur de domaine.
Il va contenir tous les objets présents dans la forêt en version « light », c’est-à-dire en ne stockant que les attributs les plus importants de l’objet (son nom, sa localisation etc…).
Prenons pour exemple un employé du site de Paris qui veut accéder au serveur de fichiers de la société qui se trouve sur le domaine racine aux Etats-Unis.
L’employé va émettre une requête sur l’objet « serveur de fichiers » situé sur un autre domaine. Ce sera alors le catalogue global situé sur le contrôleur de son propre domaine, donc celui de google.paris.com, qui va effectuer la recherche sur l’ensemble de la forêt pour savoir dans quel domaine se situe l’objet serveur de fichiers, et par conséquent lui répondre et non les contrôleurs étrangers à son domaine. Le contrôleur de domaine de l’employé agit alors comme un intermédiaire.
Chaque domaine doit obligatoirement posséder au minimum un contrôleur de domaine ET un catalogue global.
Il est très fortement conseillé d’avoir deux contrôleurs de domaine dans un même domaine qui seront répliqués pour assurer la tolérance de panne et répartir la charge.
Il est possible d’avoir un contrôleur de domaine qui sera uniquement en lecture seule qu’on appelle « RODC ». Ce type de serveur peut s’avérer très utile par exemple pour un site distant qui ne comporte que peu d’employés mais qui ont besoin d’être authentifiés dans le domaine. Comme ce serveur est en lecture seule, il ne pourra pas être altéré. Il prendra ses informations directement depuis un contrôleur de domaine normal en répliquant les données selon une planification définie.
Le contrôleur de domaine joue donc un rôle essentiel dans la gestion des « objets » Active Directory. Mais ça ne s’arrête pas là car chaque contrôleur peut jouer un rôle particulier dans la gestion du « domaine » ou de la « forêt ».
Ces différents rôles, nommés “Flexible Single Master Operation”, ou plus rapidement, FSMO, seront expliqués dans le chapitre suivant.
Comprendre la notion de domaine Active Directory ⇐ : Accéder au chapitre précédent
Accéder au chapitre suivant : ⇒ Rôles FSMO
