• Windows Server

Toutes les entreprises travaillant avec des serveurs en environnement Microsoft utilisent les services de domaines Active Directory disponibles sous Windows Server.

Mais, qu'est-ce qu'un Active Directory au fait ? C'est ce que vous allez découvrir dans cet article.
Grâce à notre article, vous aurez toutes les informations nécessaires pour débuter avec ces services de domaines Active Directory et savoir ce que signifie et ce que représente les contrôleurs de domaines, les forêts, les domaines, les sites Active Directory, ...

  1. Contrôleurs de domaines
    1. Contrôleur de domaine (DC)
    2. Contrôleur de domaine en lecture seule (RODC)
    3. Catalogue global (GC)
  2. Composants de l'Active Directory
    1. Domaine Active Directory
    2. Arborescence de domaines Active Directory (ou arbre Active Directory)
    3. Forêt Active Directory
    4. Schéma Active Directory
    5. Partitions
    6. Sites Active Directory
  3. Rôles FSMO (Maître d'opérations)
    1. Rôles FSMO uniques au niveau de la forêt
      1. Maître de schéma
      2. Maître d'attribution des noms de domaines (ou maître de nommage)
    2. Rôles FSMO uniques au niveau du domaine
      1. Maître d’opérations RID
      2. Emulateur PDC (Emulateur de contrôleur de domaine principal)
      3. Maitre d'infrastructure
  4. Relations d'approbation
    1. Approbations unidirectionnelles et bidirectionnelles
      1. Approbations unidirectionnelles
      2. Approbations bidirectionnelles
    2. Approbations transitives et non transitives
      1. Approbations transitives
      2. Approbations non transitives
    3. Approbations de forêts
      1. Fonctionnement des approbations de forêts
      2. Conditions pour créer des approbations de forêts
    4. Approbations externes (approbations de domaines)

1. Contrôleurs de domaines

Pour créer un environnement Active Directory sous Windows Server, la 1ère chose que vous installerez est un contrôleur de domaine.
Notez qu'il faut minimum un contrôleur de domaine par domaine Active Directory (domaine, sous-domaine, ...).

Un contrôleur de domaine peut être installé de 3 façons :

  1. en tant que contrôleur de domaine (ou DC en anglais pour Domain Controller)
  2. en tant que contrôleur de domaine en lecture seule (ou RODC en anglais pour Read Only Domain Controller)
  3. en tant que serveur de catalogue global (ou GC en anglais pour Global Catalog)

1.1. Contrôleur de domaine (DC)

Un contrôleur de domaine est un serveur qui contient une copie complète de la configuration Active Directory du domaine dans lequel il se trouve, ainsi que le dossier système : SYSVOL.
Notez que dans le cas d'un DC, cette copie est utilisable en lecture et écriture, contrairement à celle du RODC qui est accessible uniquement en lecture.

Pour le dossier SYSVOL, il contient notamment :

  • tous les fichiers liés aux stratégies de groupe (aussi appelées GPO en anglais pour Group Policy Objects)
  • les éventuels scripts de démarrage, d'ouverture de session, ... que vous auriez créés et ajoutés dans vos stratégies de groupe

Source : Microsoft TechNet

1.2. Contrôleur de domaine en lecture seule (RODC)

Un contrôleur de domaine en lecture seule (RODC) est la même chose qu'un contrôleur de domaine (DC) excepté qu'il contient cette fois-ci une copie en lecture seule de la configuration Active Directory du domaine dans lequel il se trouve.

L'utilisation d'un contrôleur de domaine en lecture seule (RODC) permet notamment :

  • d'améliorer la sécurité : étant donné que la copie qu'il contient n'est disponible qu'en lecture seule, elle ne peut donc pas être modifiée.
  • accélérer les ouvertures de sessions
  • améliorer les accès aux ressources du réseau

Source : AD DS: Read-Only Domain Controllers

1.3. Catalogue global (GC)

Si le contrôleur de domaine est configuré en tant que catalogue global, celui-ci contient une copie partielle en lecture seule des attributs de tous les objets de la forêt. Ce qui est aussi appelé "PAS" en anglais pour Partial Attribute Set.

Les catalogues globaux sont intéressants pour réduire les temps d'accès à une infrastructure Active Directory.
Néanmoins, cela n'est nécessaire que si :

  • une application requiert la présence d'un catalogue global. Ce qui est notamment le cas pour Microsoft Exchange et Message Queuing (MSMQ) de Microsoft.
  • vous avez + de 100 utilisateurs afin de réduire l'utilisation de la bande passante WAN
  • l'ouverture de session est lente sur vos postes clients

L'utilisation d'un catalogue global permet d'accélérer les recherches sur les attributs d'un objet pour un domaine différent de la forêt où vous vous trouvez. Ce qui est nécessaire, par exemple, pour accélérer les requêtes effectuées par Microsoft Exchange.

Sources :

2. Composants de l'Active Directory

Un environnement Active Directory est composé de plusieurs choses contenues les unes dans les autres.

2.1. Domaine Active Directory

Pour commencer, un domaine Active Directory contient une série d'objets, tels que :

  • des objets ordinateurs qui identifient un ordinateur du réseau qui a joint votre domaine
  • des utilisateurs
  • des groupes
  • des unités d'organisation ou des conteneurs (que vous pouvez comparer pour le moment à des dossiers)
  • etc

Cette notion de domaine permet de créer une limite administrative pour la gestion des différents objets.
En effet, par défaut, l'administrateur d'un domaine Active Directory (par exemple : corp.informatiweb.lan) n'a pas accès la gestion des autres domaines (ex : rh.informatiweb.lan).
Néanmoins, vous verrez un peu plus tard que cela est tout de même possible si on le souhaite grâce aux délégations de contrôle Active Directory.

Notez qu'il faut au moins 1 contrôleur de domaine Active Directory par domaine, comme vous pouvez le voir sur le schéma ci-dessous.

2.2. Arborescence de domaines Active Directory (ou arbre Active Directory)

Une arborescence de domaines est un ensemble de domaines partageant un espace de noms commun.
Par exemple, "corp.informatiweb.lan" et "rh.informatiweb.lan" font partie d'une même arborescence de domaines et l'espace de nom commun est "informatiweb.lan".

Source : support Microsoft.

2.3. Forêt Active Directory

Comme vous l'aurez deviné, une forêt Active Directory est un ensemble d'arbres Active Directory.

2.4. Schéma Active Directory

L'Active Directory est une base de données dans laquelle on peut créer de nombreux objets (de type ordinateur, utilisateur, ...).
Pour créer ces objets, l'Active Directory repose sur un système de classes et d'attributs qui permet de créer ces différents types d'objets et de définir de nombreuses propriétés sur ceux-ci.
Par exemple : le nom d'un utilisateur, le groupe dans lequel il se trouve, ...

Source : Active Directory Schema (AD Schema)

2.5. Partitions

Lorsque vous créez un contrôleur de domaine Active Directory, sa configuration est stockée dans différentes partitions :

  • configuration : cette partition contient tous les objets de configuration de la forêt.
    Les objets de configuration contiennent des informations à propos des sites Active Directory, des services d'annuaires (domaines, liste des contrôleurs, ...) et des partitions elles-mêmes.
    Pour voir le contenu de cette partition "configuration", vous pouvez utiliser le programme ADSI Edit disponible sous Windows Server.
  • schéma : cette partition contient le schéma Active Directory (expliqué précédemment).
    Pour voir son contenu, vous devez utiliser la console mmc "Schéma Active Directory". Néanmoins, cette console n'est pas activée par défaut.
  • domaine : cette partition contient les objets ordinateurs, utilisateurs, ... pour le domaine concerné par ce contrôleur de domaine.
    Pour voir son contenu, utilisez la console "Utilisateurs et ordinateurs Active Directory".

Grâce à ce système de partitions de l'Active Directory, vous pouvez profiter notamment du système de réplication de l'Active Directory pour d'autres services. Tels que le DNS qui une fois intégré, vous permet de répliquer automatiquement vos zones DNS grâce aux partitions "ForestDnsZones" et "DomainDnsZones" qui y seront crées.

Pour ce qui est de la réplication de ces partitions Active Directory :

  • les modifications effectuées sur les partitions "configuration" et "schéma" sont répliquées sur tous les contrôleurs de domaine de la forêt concernée.
  • les modifications effectuées sur la partition "domaine" sont répliquées uniquement sur les contrôleurs de domaines du même domaine.
  • pour les partitions d'applications, vous pouvez ne pas les répliquer ou les répliquer dans différents domaines de la forêt si vous le souhaitez.

Cela signifie que le contenu de la partition "domaine" est donc différent d'un domaine à l'autre, contrairement au contenu des 2 autres partitions qui est identique (car répliqué) sur tous les contrôleurs de domaine de la même forêt.

Pour finir, sachez que ces partitions se trouvent toutes dans la base de données stockée sous la forme d'un fichier nommé "NTDS.DIT" dans le dossier "C:\Windows\NTDS" de votre serveur Active Directory.

Source :

2.6. Sites Active Directory

Les sites Active Directory permettent de gérer la réplication des données entre les différents contrôleurs de domaine Active Directory.
Depuis la console "Sites et services Active Directory", vous pourrez gérer l'emplacement réseau et géographique de vos différents contrôleurs de domaines.

3. Rôles FSMO (Maître d'opérations)

Lorsque vous implémentez plusieurs contrôleurs de domaines dans une infrastructure Active Directory, vous devez désigner un maître d'opérations pour les différents rôles FSMO (Flexible Single Master Operation) existants.

Une infrastructure Active Directory repose toujours sur 5 rôles FSMO (bien qu'il y en ait un qui peut devenir inutile dans certains cas).
Certains de ces rôles FSMO sont uniques par forêt et d'autres sont uniques par domaine, et permettent de désigner certains types de contrôleurs de domaine.

Source : Planification de l’emplacement des rôles de maître d’opérations

3.1. Rôles FSMO uniques au niveau de la forêt

3.1.1. Maître de schéma

Le contrôleur de domaine possédant le rôle de "Maître de schéma" sera le serveur s'occupant des modifications et des mises à jour effectuées sur le schéma Active Directory.
Pour que cela soit possible, le serveur devra faire partie du groupe de sécurité "Administrateur du schéma".

3.1.2. Maître d'attribution des noms de domaines (ou maître de nommage)

Le contrôleur de domaine possédant le rôle de "Maître de nommage" sera responsable des ajouts et des suppressions de domaines et de partitions dans la forêt Active Directory.

3.2. Rôles FSMO uniques au niveau du domaine

3.2.1. Maître d’opérations RID

Le contrôleur de domaine possédant le rôle de "Maître d’opérations RID" sera responsable d'allouer (ou attribuer) des pools de RID (Relative ID) à chaque objet Active Directory qui a besoin d'un ID de sécurité (SID), tels que les objets ordinateur, utilisateur, ...
Ce Maître d’opérations RID n'agit que sur les contrôleurs de domaines du domaine dans lequel il se trouve et s'assure ainsi que chaque objet et chaque contrôleur de domaine du domaine actuel possède un identifiant de sécurité (SID) unique.

Ces ID de sécurité sont structurés avec :

  • un numéro de révision
  • l'identifiant de sécurité du domaine (aussi appelé "domaine SID")
  • un RID (qui signifie : relative ID)

3.2.2. Emulateur PDC (Emulateur de contrôleur de domaine principal)

Pour ce qui est du rôle "Emulateur PDC", le contrôleur de domaine possédant ce rôle sera responsable de la mise à jour et de la réplication des mots de passe.

Pour synchroniser l'horloge des différents contrôleurs de domaine et des différents PC clients, Active Directory a besoin d'une source fiable avec laquelle se synchroniser.
Dans une forêt Active Directory, si un contrôleur de domaine possède ce rôle d'émulateur PDC, celui-ci sera considéré comme la meilleure source de temps (la source la plus fiable).
Cette synchronisation des horloges est très importante pour l'authentification (des utilisateurs notamment), car chaque paquet Kerberos est horodaté et si une trop grande différence de temps est présente, l'authentification ne peut plus fonctionner correctement.

L'émulateur PDC joue aussi un rôle dans le support des clients NT4 et ceux inférieurs à Windows 2000, car il peut être configuré pour émuler un contrôleur de domaine NT4 et ainsi supporter ces anciens clients.

Comme vous l'aurez compris, sans ce rôle "Emulateur PDC" :

  • la synchronisation des horloges peut ne plus fonctionner correctement. Ce qui pourra provoquer des problèmes d'authentification via Kerberos.
  • les utilisateurs de PCs clients sous Windows NT4 ou inférieurs à Windows 2000 ne pourront plus se connecter
  • etc

Sources :

3.2.3. Maitre d'infrastructure

Le contrôleur de domaine désigné comme "maître d'infrastructure" s'occupe de mettre à jour les références (aussi appelées "principaux de sécurité") d'objets entre les différents domaines.
Ainsi, si un utilisateur d'un domaine "A" est ajouté à un groupe d'un domaine "B", puis que l'on modifie cet utilisateur (sur le domaine "A"), les contrôleurs de domaines du domaine B ne seront jamais au courant de cette modification.

C'est ici que le maître d'infrastructure entre en jeu en recherchant si des mises à jour sont nécessaires et il mettra à jour le nom de l'utilisateur sur le domaine "B".
Ensuite, cette modification sera répliquée sur les autres contrôleurs de domaine du domaine B.

Bien que, par défaut, les contrôleurs de domaines ne soient pas au courant de ce genre de modification, ce n'est pas le cas de ceux qui sont configurés en tant que "catalogue global". En effet, dans ce cas, les informations sont mises à jour, quel que soit le domaine auquel ils appartiennent.
Ce rôle n'est donc pas utile si tous vos contrôleurs de domaines sont configurés en tant que "catalogue global".

L'autre exception à cette règle est simplement lorsque vous possédez un seul domaine dans votre infrastructure Active Directory.
Comme vous n'avez qu'un seul domaine Active Directory, ce genre de problème ne se pose pas.

Source : Configuration requise pour le placement du maître d’infrastructure

4. Relations d'approbation

La sécurité d'une infrastructure Active Directory est basée sur des relations d'approbation que vous pouvez créer entre des domaines ou des forêts.
Néanmoins, avant de créer des relations d'approbations entre des domaines ou des forêts, il est important de comprendre comment elles fonctionnent et qu'est ce qu'elles impliquent de façon transparente.

Par défaut, un canal sécurisé est utilisé pour vérifier les informations de sécurité, et notamment les identifiants de sécurité (SID) des utilisateurs et des groupes.
Ce canal sécurisé peut être étendu à d'autres domaines Active Directory grâce à la création de relations d'approbation entre plusieurs domaines ou plusieurs forêts.

Ces relations d'approbations peuvent être :

  • unidirectionnelles ou bidirectionnelles
  • transitives ou non transitives

Source : Fonctionnement des relations d’approbation pour les forêts de ressources dans Azure Active Directory Domain Services

4.1. Approbations unidirectionnelles et bidirectionnelles

Les relations d'approbation qui permettent d'accéder aux ressources peuvent être unidirectionnelles et bidirectionnelles.

Comme leurs noms l'indiquent :

  • les relations d'approbation unidirectionnelles sont valables uniquement dans un sens
  • les relations d'approbation bidirectionnelles sont valables dans les 2 sens

4.1.1. Approbations unidirectionnelles

Si vous créez une relation d'approbation unidirectionnelle entre le domaine A et le domaine B, les utilisateurs du domaine A pourront accéder aux ressources du domaine B.
Par contre, ceux du domaine B ne pourront pas accéder aux ressources du domaine A.

L'authentification pourra donc fonctionner aussi du domaine A vers le domaine B, mais pas l'inverse.

Dans ce cas-ci, on dit que le domaine A approuve le domaine B. Mais par contre, le domaine B n'approuve pas le domaine A.

4.1.2. Approbations bidirectionnelles

Si vous créez une relation d'approbation bidirectionnelle entre le domaine A et le domaine B, les utilisateurs du domaine A pourront accéder aux ressources du domaine B (et inversement).

L'authentification pourra donc aussi fonctionner du domaine A vers le domaine B (et inversement).

Dans ce cas-ci, le domaine A approuve le domaine B. Et le domaine B approuve donc aussi le domaine A.

Dans une forêt Active Directory, les approbations de domaine sont toutes bidirectionnelles et transitives.
De plus, chaque domaine enfant approuve automatiquement son parent lorsqu'il est créé.

4.2. Approbations transitives et non transitives

Les relations d'approbations entre 2 domaines peuvent être transitives et non transitives.

4.2.1. Approbations transitives

Dans le cas d'une approbation transitive, cela indique que l'approbation peut être étendue à d'autres domaines.
C'est le comportement par défaut utilisé lorsque vous créez un nouveau domaine Active Directory enfant.

Dans ce cas-ci, les utilisateurs d'un domaine enfant peuvent accédez aux ressources du domaine parent, du parent du parent, ... tant que la transitivité est activée.

Exemple : si le domaine A approuve le domaine B, et que le domaine B approuve le domaine C, alors étant donné que la transitivité est activée, les utilisateurs du domaine A pourront accéder aux ressources du domaine B, mais aussi à celles du domaine C. Pour les demandes d'authentification, c'est pareil, car elles suivent ces chemins d'approbations.

4.2.2. Approbations non transitives

Dans le cas d'une approbation non transitive, cela indique que l'approbation n'est application qu'entre les 2 domaines concernés.
L'utilisateur ne peut donc pas remonter le chemin d'approbation via les relations d'approbation que vous avez définies.

Pour reprendre l'exemple précédent, si le domaine A approuve le domaine B, et le domaine B approuve le domaine C :

  • les utilisateurs du domaine A pourront accéder aux ressources du domaine B
  • les utilisateurs du domaine B pourront accéder aux ressources du domaine C
  • mais, les utilisateurs du domaine A NE pourront PAS accéder aux ressources du domaine C

4.3. Approbations de forêts

4.3.1. Fonctionnement des approbations de forêts

Contrairement aux approbations de domaines qui permettent de créer une relation d'approbation entre un domaine A et un domaine B (voir plus en activant la transitivité), il existe aussi des approbations de forêts.
Ces relations d'approbations de forêts permettent de relier 2 forêts avec une relation unidirectionnelle (dans 1 sens) ou bidirectionnelle (dans les 2 sens).

Les relations d'approbations de forêts sont intéressantes dans certains cas et notamment lors de l'acquisition d'une ou plusieurs sociétés par exemples qui utilisent donc leurs propres forêts Active Directory et leurs propres espaces de noms (societe-a.lan et societe-b.lan, par exemple).

Néanmoins, contrairement aux relations d'approbations entre des domaines qui peuvent être transitives, cela n'est pas possible avec les relations d'approbations de forêts.
Celles-ci ne peuvent être que non transitives.

Cela signifie que si vous créer une relation d'approbation entre la forêt A et la forêt B, ainsi qu'entre la forêt B et la forêt C, les utilisateurs de la forêt A n'auront pas accès à la forêt C.
Si vous souhaitez que cela soit possible, vous devrez créer une relation d'approbation supplémentaire entre la forêt A et la forêt C.

Notez que la création de relations d'approbations de forêts ne peut s'effectuer qu'entre le domaine racine de chaque forêt concernée.

4.3.2. Conditions pour créer des approbations de forêts

Pour pouvoir créer des approbations de forêts, il faut que votre infrastructure DNS corresponde à une de ces situations :

  • un serveur DNS racine unique contient les zones DNS des 2 forêts que vous voulez relier avec une relation d'approbation de forêts.
  • un serveur DNS racine utilise des redirecteurs conditionnels pour rediriger les requêtes de chaque espace de nom vers le serveur DNS principal contenant celui-ci.
  • un serveur DNS racine utilise des zones DNS secondaires pour que les requêtes soient redirigées vers le serveur DNS principal concerné par l'espace de nom souhaité.

Ensuite, pour être autorisé à créer une relation d'approbation entre 2 forêts, vous devez faire partie du groupe "Admins du domaine" (dans le domaine racine de la forêt concernée) ou du groupe "Administrateurs de l'entreprise" dans votre infrastructure Active Directory.

4.4. Approbations externes (approbations de domaines)

Dans une grande infrastructure Active Directory avec plusieurs domaines et plusieurs forêt Active Directory, il peut être intéressant de créer une relation d'approbation entre 2 domaines (plutôt qu'entre 2 forêts).

Les approbations de domaines (ou externes) sont apparues avec Windows NT Server et peuvent être unidirectionnelles ou bidirectionnelles.

Source : Approbations externes

A voir également

Commentaires

Vous devez être connecté pour pouvoir poster un commentaire

Donnez-nous votre avis

Contenu épinglé

Contact

® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - Tous droits réservés.

Toute reproduction totale ou partielle de ce site est interdite et constituerait une contrefaçon sanctionnée par les articles L.335-2 et suivants du Code de la propriété intellectuelle.