1. Qu’est-ce qu’Active Directory ?

Active Directory (AD) est un service d’annuaire dédié aux entreprises, disponible sur les serveurs
Windows, qui va permettre de centraliser toutes les ressources d’une entreprise.

Il peut être comparé à un annuaire téléphonique comme les pages jaunes puisqu’il va regrouper des
informations concernant une entreprise. Ces informations peuvent par exemple être : qui sont les
employés ? Dans quel service travaillent-t-ils ? Quelle est leur adresse mail ? Leur numéro de
téléphone interne ? Où se situe cette imprimante ? et encore beaucoup d’autres attributs.

L’objectif principal d’Active Directory est de fournir des services centralisés d’identification et
d’authentification à un réseau informatique et par conséquent une organisation hiérarchisée. Il
répertorie les éléments d’un réseau administré tels que les comptes des utilisateurs, les serveurs, les
postes de travail, les imprimantes, etc, qui seront appelés des « objets » et qui seront virtuellement
stockés dans une base de données.

On pourrait donc dire que l’Active Directory mémorise tous les objets de l’entreprise et leurs
caractéristiques. La présence de ces objets et leurs caractéristiques respectives définissent le schéma
Active Directory, c’est-à-dire la structure même de la base de données.

Active Directory est un service propriétaire de Microsoft qui se base sur le protocole standardisé
LDAP : Lightweight Directory Access Protocol. Ce protocole définit la méthode utilisée par le client
pour l’interrogation de la base de données et permettra aux utilisateurs, entre autres, de se
connecter/déconnecter au sein de ce qu’on appelle un domaine, mais également de modifier les
services d’annuaires.
 2. Comprendre la notion de domaine Active Directory
L’intérêt d’avoir un Active Directory dans son réseau est qu’il va permettre de hiérarchiser les
ressources de l’entreprise. Il va apporter une vision structurée de ses moyens en les organisant
par domaine.

La notion de domaine est fondamentale dans la compréhension d’Active Directory. Un domaine par
définition est une « entité », un ensemble logique d’objets qui vont se partager le même annuaire. Il
définit une zone d’administration dans le parc informatique. C’est sur ce domaine que les objets,
utilisateurs, ordinateurs etc… seront authentifiés et donc, c’est à ce domaine qu’ils vont appartenir.

Lorsque l’on paramètre un domaine, il faut le nommer de la même manière qu’un nom de domaine
sur internet comme yahoo.fr. On retrouvera donc l’extension du domaine (.net, .fr, .com, .org…) et
le nom du domaine à proprement dit (google.fr, wikipedia.org, facebook.com…). Le domaine est
intimement lié au service de résolution de noms : le DNS. Il sera impossible de construire un domaine
sans serveur DNS qui va gérer la zone du domaine.

Info + : pour posséder un nom de domaine valide, c’est-à-dire accessible sur internet, il faut au préalable en
faire l’inscription auprès d’un organisme gestionnaire appelé un « registrar » (OVH, AWS, 1and1…).
Dans le cas où le domaine n’a pas besoin d’être accessible il peut simplement être appelé « mondomaine.lan »,
« mondomaine.loc » ou même « mondomaine.toto » si vous le souhaitez.

Le premier domaine créé dans une entreprise sera le domaine « racine » de ce que l’on appelle une
« forêt » . On pourra par la suite y greffer des « sous-domaines ». Ces sous domaines pourront par
exemple représentés les différentes zones géographique couvertes par une entreprise à travers le
monde.

La représentation visuelle la plus simple pour visualiser un AD est justement un arbre dans une
forêt. En effet, un arbre possède une racine, des branches, qui elles-mêmes possèdent d’autres
branches, qui elles-mêmes possèdent des feuilles, tout cela à la manière d’un arbre généalogique.

Imaginons qu’une entreprise mondiale comme Google possède des bureaux, des « sites », dans
différents pays. Voici comment graphiquement nous pourrions représenter le domaine de
l’entreprise par un arbre avec ses racines et ses branches :
Ajoutons maintenant un nouveau domaine (et non un « sous-domaine »), avec un espace de nom
différent. Prenons pour exemple notre société Google qui fusionne avec la société Yahoo pour ne
devenir plus qu’une seule et même structure. Google et Yahoo possèdent déjà chacun leur propre
arbre, avec leur domaine, sous-domaine, objets etc…

Afin de faciliter la gestion, on va « rapprocher » de façon logique les deux entreprises et établir
une relation d’approbation entre les deux domaines. Cette relation d’approbation, ou de
« confiance » va permettre au domaine Yahoo.com, d’accéder aux ressources du domaine
Google.com. En langage usuel, on pourrait traduire cette relation d’approbation par « je t’approuve
mais j’approuve aussi les domaines que tu décides d’approuver », ou encore plus simplement, « les
amis de mes amis sont mes amis ».

Dans ce cas, nous aurons donc une forêt avec plusieurs arbres qui vont travailler ensemble.
Et pour que tout ce petit monde réussisse à communiquer, nous aurons besoin d’un catalogue
global.

3. 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.
 4. Les rôles FSMO
Les rôles FSMO, ou Flexible Single Master Operation, ont été implémentés dans les environnements
Active Directory par Microsoft afin de délimiter les responsabilités de chaque serveur “contrôleur
de domaine”, et donc par conséquent, d’en améliorer la sécurité.

Info + : Pour rappel, il est plus que conseillé de posséder, à minima, au moins 2 contrôleurs de domaine dans un
environnement AD, afin d’assurer la tolérance de panne mais également la répartition des charges.

Les rôles FSMO, au nombre de 5, ont chacun des objectifs bien précis qui sont d’assumer certaines
tâches au sein d’un domaine ou d’une forêt. Ces tâches sont des modifications spécifiques qui
peuvent être apportées aux données contenues dans l’annuaire Active Directory.

Petit tour d’horizon des 5 rôles FSMO :

1. Maître du schéma (SM)

Comme déjà évoqué, le schéma définit la structure de l’annuaire Active Directory. Pour une bonne
compréhension entre les contrôleurs, il est impératif qu’ils reposent tous sur le même schéma. Le
rôle du contrôleur maître du schéma sera donc de veiller à l’unicité au sein de la forêt. Il sera le seul
à pouvoir initier des changements au niveau de la structure de l’annuaire. Exchange par exemple, le
service de messagerie de Microsoft, va exiger des objets bien particuliers dans Active Directory. Pour
incorporer ces objets à l’AD, donc modifier la structure initiale, le rôle maître du schéma sera
impérativement nécessaire.

C’est également lui qui assure les réplications sur l’ensemble des contrôleurs de domaines.

Ce rôle doit être unique au sein d’une forêt et installé avec les rôles Maître d’attribution des noms de
domaine et PDC Emulator.

2. Maître d’attribution des noms de domaine (DNM)

Ce rôle est relativement simple puisqu’il va être chargé de s’assurer de l’unicité des noms de
domaine au niveau de la forêt. Il est également en charge de la création et/ou suppression
de relations avec les domaines externes. S’il n’est pas disponible, aucun ajout ou suppression de
domaine ne sera possible dans la forêt.

Ce rôle doit être unique au sein d’une forêt et installé avec les rôles Maître du schéma et PDC
Emulator.

3. Maître des Identifiants Relatifs (RID)

Les objets dans une infrastructure Active Directory sont identifiables par un numéro unique. Lorsque
qu’AD traite un objet, il travaille en réalité avec son identifiant.

Le rôle du maître RID sera d’attribuer à chaque objet (utilisateur, ordinateur, groupe, etc…)
un identifiant unique de sécurité (SID) qui sera structuré de la façon suivante :

o Un numéro de révision

o Un identificateur de sécurité du domaine (domaine SID), c’est-à-dire une suite de numéros,

propre et unique à chaque domaine.

o Un RID (Relative Identifier), une plage de chiffres (un « pool » qui agit comme une plage
DHCP) incrémentale qui va suivre le SID du domaine et donnera l’identifiant final d’un objet.

Voici un exemple d’identifiant unique qui peut être celui d’un objet utilisateur :

S-1-5-21-2401410526-1208469522-549608361-500

La partie en rouge représente le SID du domaine et la partie verte le RID de l’objet. Le RID sera
incrémenté à chaque ajout d’un objet sur le domaine alors que le SID du domaine restera identique.

Ce rôle doit être placé de préférence avec le PDC Emulator et doit être unique dans un domaine.
4. Maître d’Infrastructure (IM)

La mission du maître d’infrastructure sera d’assurer la propagation des objets, ou des modifications
apportées sur un objet (supprimé, renommé), au travers de tous les domaines de la forêt. Ce rôle
s’appuie sur le contrôleur de domaine qui est Catalogue Global pour maintenir à jour les références
d’objets entre les différents domaines.

Ce rôle est unique au sein d’un domaine. S’il n’est pas disponible, les réplications entre les domaines
ne seront plus effectives.

5. Emulateur du contrôleur principal de domaine (PDC)

L’émulateur PDC assure diverses missions liées à la sécurité telles que la gestion du verrouillage des
comptes, les changements de mot de passe ou encore les modifications des stratégies de groupe afin
d’éviter les conflits ou les écrasements.

Il joue également par défaut le rôle de serveur de temps pour l’ensemble du domaine. Il est en effet
très important que l’heure et la date soient bien synchronisées dans un domaine afin d’éviter de très
nombreux dysfonctionnements.

Ce rôle est unique au sein d’un domaine.

Le premier contrôleur de domaine d’un domaine détiendra par défaut les cinq rôles FSMO. Il sera
cependant possible par la suite de transférer les rôles si vous souhaitez les répartir entre plusieurs
contrôleurs de domaine.
 5. Structure d’un domaine et unités organisationnelles

L’architecture d’un domaine est généralement le reflet de la structure de l’entreprise.

La structure Active Directory est hiérarchique et ne sera pas si différente d’un système de fichiers.
Nous l’avons vu précédemment, il s’agit d’une forêt, de domaines, de sous-domaines et d’objets.
Ceci forme donc une arborescence.

On peut voir la forêt comme un répertoire de base, un « container » qui contient des dossiers, qui
eux-mêmes contiennent des dossiers, qui contiennent au final, des fichiers. Sur un domaine, le
principe est le même. Le container principal du domaine sera le domaine lui-même.

Dans ce conteneur, on va trouver d’autres conteneurs qui sont créés par défaut sur Active Directory
et qui vont contenir, entre autres, les groupes et utilisateurs spéciaux pour l’administration et le
serveur qui est le contrôleur de domaine.

Les conteneurs qui vont nous permettre de grouper les objets suivants nos besoins s’appellent des
« Unités d’organisation » (UO ou OU en anglais). Une OU est un groupe d’objets, similaire à un
dossier, qui va contenir des fichiers. Il s’agit en réalité d’un container où l’on va placer des objets.

Les unités organisationnelles vont aider à représenter la structure organisationnelle de l’entreprise.

Elles vont regrouper des utilisateurs et/ou ordinateurs en fonction de critères définis comme : leur
zone géographique, leur fonction, leur service…

Si nous créons une Unité d’Organisation qui va regrouper les différents services de l’entreprise, nous
allons y trouver à l’intérieur, d’autres Unités d’Organisation, en général une par service.

Et dans l’OU de chaque service, on devra logiquement y trouver tous les employés du dit service. On
peut également y ajouter les groupes liés à ce service et les ordinateurs si on le souhaite.
Ce qui nous donnera par exemple une arborescence de ce type :

L’arborescence peut être déclinée selon le besoin. On pourrait également choisir d’avoir un
conteneur où ne seront stockés que les postes de travail et un autre que pour les utilisateurs. Cette
politique est à définir et adapter selon le besoin.

Mieux notre Active Directory sera structuré, plus il sera simple à administrer.

6. Stratégies de groupe

L’intérêt d’utiliser des Unités d’Organisations pour structurer son Active Directory, c’est de pouvoir y
appliquer des stratégies de groupe.

Les stratégies de groupe (GPO) sont des outils très puissants de configuration de
l’environnement applicables sur des ordinateurs et/ou des utilisateurs membres d’un domaine Active
Directory.

Voici quelques exemples d’utilités des stratégies de groupe dans un domaine

o Déployer, mettre à jour, désinstaller un logiciel

o Lancer des scripts automatisant des tâches au démarrage/arrêt d’une machine

o Imposer des stratégies de compte (longueur d’un mot de passe, complexité…)

o Déléguer des tâches d’administration

o Empêcher le plug de médias amovibles

o Paramétrer la sécurité (pare-feu, stratégie VPN, Wifi…)

o Et bien plus encore…

Des milliers de GPO sont disponibles sur un serveur et ce nombre augmente avec les versions de
Windows. Par exemple, un serveur Windows 2016 regroupe entre 3500 et 4000 stratégies de
sécurité.

Les stratégies de groupe ne s’arrêtent pas aux systèmes Windows mais peuvent aujourd’hui
permettre aux administrateurs de configurer des logiciels comme les navigateurs Internet Chrome et
Firefox, mais aussi les différentes versions du Pack Office.

Microsoft met pour cela à disposition des modèles d’administration qui sont un ensemble de fichiers
au format « ADMX » contenant des paramètres de stratégie. C’est l’intégration de ces fichiers au
sein du serveur Active Directory qui va permettre d’effectuer des configurations sur des logiciels par
exemple.

Les fichiers ADMX fournis par Microsoft concernent également des paramètres de stratégie pour
des systèmes d’exploitation Windows différents de la version du serveur contrôleur de domaine.
Vous pourrez importer des paramètres qui existait sous Windows 7 ou Windows Server 2008 et
ainsi gérer votre parc de façon plus ciblée.

Info + : Pour en savoir plus sur les fichiers modèles d’administration et leur intégration dans un environnement
Active Directory, se référer à la procédure officielle de Microsoft accessible par ce lien : Support Microsoft –
magasin central pour GPO

Le gros avantage d’utiliser une stratégie de groupe directement sur une Unité d’Organisation (OU)
c’est de pouvoir cibler son application. Par exemple, nous pouvons par une stratégie définir que tous
les utilisateurs du service RH doivent avoir des mots de passe bien plus complexes que ceux des
utilisateurs du service Logistique.

Comme nous avons bien structuré notre Active Directory, nous allons appliquer la stratégie à l’Unité
d’Organisation qui contient tous les employés du service RH et ainsi, aucun autre employé ne sera
impacté.

Théoriquement, une GPO s’applique sur un domaine, un site ou une unité d’organisation. Mais
techniquement, elle s’applique à un groupe, comme son nom l’indique. Si l’on crée une GPO sur une
Unité d’Organisation, elle sera appliquée directement à un groupe par défaut « Utilisateurs
authentifiés » c’est-à-dire, « Utilisateurs contenues dans cette OU ».

Mais imaginons que nous ayons structuré notre domaine comme ceci :
Comme tous les utilisateurs, quel que soit leur service, se trouvent dans la même Unité
d’Organisation, comment faire pour que seuls les employés du département RH aient un mot de
passe fort ? Si nous appliquons une GPO sur toute l’OU des utilisateurs, tout le monde devra avoir un
mot de passe fort ! (Ce qui en soit est une bonne idée mais ce n’est pas ce que nous voulons dans
notre cas précis…)

Dans ce cas, il faut créer un nouveau groupe sur le domaine. Ce groupe devra contenir uniquement
les employés du département RH.

Il faudra ensuite appliquer un filtrage de sécurité sur la stratégie en supprimant le groupe

« Utilisateurs authentifiés » présent par défaut et en y ajoutant uniquement le groupe
« Groupe_RH ». Ainsi, les autres employés ne seront pas soumis à cette stratégie.
 7. Gestion des groupes sous Active Directory

Dans un environnement Active Directory, il existe deux types de groupe : les groupes de « Sécurité »
et les groupes de « Distribution ».

Les groupes de distribution sont spécifiques et ne peuvent en aucun cas être associés aux
permissions que l’on attribuerait sur un répertoire partagé car ils ne disposent pas de « SID »,
d’identifiant de sécurité. Ils justifient leur existence généralement pour des besoins applicatifs avec
un serveur de messagerie électronique comme Microsoft Exchange.

Grâce à ce type de groupe, on pourrait envoyer un mail à plusieurs personnes qui en sont membres,
en même temps, sans avoir besoin de renseigner leurs adresses mails respectives une par une.

Les groupes de sécurité vont être utilisés pour organiser les utilisateurs et ordinateurs du
domaine mais aussi et surtout pour fixer des permissions d’accès sur des ressources.

Prenons le cas d’un répertoire réseau qui doit être accessible pour l’ensemble du personnel du
département Logistique (100 employés). Pour que chaque utilisateur dispose de droits d’accès à ce
répertoire, il faudrait les ajouter un à un et les autoriser à interagir dans ce dossier, ce qui est long et
fastidieux pour un administrateur et entraînerait une mauvaise gestion et un mauvais suivi par la
suite.

La meilleure solution, qui est d’ailleurs une « bonne pratique » préconisée par
Microsoft, serait d’ajouter tous les employés du service Logistique dans un groupe de sécurité et
appliquer des droits à ce répertoire réseau, directement au groupe. Ceci va permettre à un
administrateur de travailler efficacement et lui apporter un gain de temps non négligeable en cas de
modifications des permissions.

Les groupes de sécurité sont eux répartis en 3 catégories distinctes que l’on appelle des
« étendues ».

Ces étendues de groupes de sécurité vont pouvoir agir différemment et contenir différents objets
membres soit, au sein du domaine, soit, au sein de toute la forêt. Voici les 3 étendues de groupes de
sécurité existantes :
 o Groupe de domaine local (GDL): utilisé dans le domaine créé uniquement

o Groupe global (GG): utilisé sur toute la forêt et dans les domaines approuvés

o Groupe universel (GU): utilisé sur l’ensemble de la forêt.

8. Conclusion
Les services d’annuaire sont une source d’informations très précieuse pour l’entreprise et
sont essentiels au bon fonctionnement d’un réseau Microsoft.
Outre la gestion des objets, l’Active Directory va permettre de garantir la sécurité au sein du
réseau. Il va certes, authentifier les utilisateurs et ordinateurs du parc mais il va aussi
permettre l’application de stratégies sur les objets afin de sécuriser l’environnement de
travail des utilisateurs comme par exemple limiter leur champ d’action sur leur machine au
niveau des configurations du système.
Active Directory peut aussi servir pour les administrateurs à la gestion du parc, au
déploiement de logiciels/mise à jours directement depuis un point central.

Les possibilités qu’offre un annuaire AD dans un réseau sont exponentielles car Microsoft
étend ses services et fonctionnalités à chaque nouvelle version de serveurs pour répondre aux
besoins croissants des entreprises.
La gestion centralisée, le référencement des ressources et l’authentification unifiée
qu’apporte une infrastructure Active Directory est un point clé et ne doit pas être négligé
dans une entreprise.