Windows | Windows Server | Active directory | Exchange | SharePoint | SCCM | SCOM | Hyper-V | App-V
ACCUEIL Facebook Twitter Linked In Viadeo Flux RSS
Chapitres
8.1 Le rôle du serveur de catalogue global
8.2 Implémentation d’un RODC

Articles suivants

Articles précédents
Nouveautés de Windows Server 2016 CTP2
Histoire de Microsoft et chronologie
Windows 10: Découvrez les nouveautés !
System Center 2012 Orchestrator: Présentation
Optimisation des performances d'un environnement Hyper-V


Publié le : 20/06/2011 16:04:53
Mise à jour le : 11/10/2011 20:16:18
Catégories :


Version imprimable

Auteur(s)

Loïc THOBOIS (Membre depuis le 04/09/2007 17:50:01)
Société : AVAEDOS
Fonction : Consultant / Formateur
Contactez cet auteur - Affichez les ressources de cet auteur

[Active Directory] 8 Implémentation des contrôleurs de domaine (RODC et GC)


8.1 Le rôle du serveur de catalogue global

8.1.1 Définition du serveur de catalogue global

Le catalogue global ou GC (Global Catalogue) permet aux utilisateurs d’effectuer 2 tâches importantes :

Trouver des informations Active Directory sur toute la forêt, quel que soit l’emplacement de ces données.

Utiliser des informations d’appartenance à des groupes universels pour ouvrir une session sur le réseau.

Un serveur de catalogue global est un contrôleur de domaine qui conserve une copie du catalogue global et peut ainsi traiter les requêtes qui lui sont destinées. Le premier contrôleur de domaine est automatiquement le serveur de catalogue global. Il est possible de configurer d’autres contrôleurs de domaine en serveur de catalogue global afin de réguler le trafic.

8.1.2 L’importance du catalogue global dans le processus d’authentification

Voici les étapes importantes qui sont réalisées lorsqu’un utilisateur s’authentifie sur le domaine :

  1. L’utilisateur entre des informations d’identification (son identifiant, son mot de passe ainsi que le domaine sur lequel il souhaite ouvrir une session) sur un ordinateur membre du domaine afin d’ouvrir une session.
  2. Ces informations d’identification sont cryptées par le centre de distribution de clefs ou KDC (pour Key distribution Center), puis envoyées à l’un des contrôleurs de domaine du domaine de l’ordinateur client.
  3. Le contrôleur de domaine compare les informations d’identification cryptées du client avec celles se trouvant sur Active Directory (les informations stockées dans le service d’annuaire Active Directory qui sont cryptées nativement). Si les informations concordent alors le processus continue, sinon il est interrompu.
  4. Le contrôleur de domaine crée ensuite la liste de tous les groupes dont l’utilisateur est membre. Pour cela, le contrôleur de domaine interroge un serveur de catalogue global.
  5. Le contrôleur de domaine fournit ensuite au client un ticket d’accord ou TGT (Ticket Granting Ticket). Le TGT contient les identificateurs de sécurité ou SID (Security Identifier) des groupes dont l’utilisateur est membre (Un TGT expire au bout de 8 heures ou bien quand l’utilisateur ferme sa session).
  6. Une fois que l’ordinateur client a reçu le TGT, l’utilisateur est authentifié et peut tenter de charger son profil et d’accéder aux ressources du réseau.

Si le serveur de catalogue global n’est pas joignable, le processus d’authentification est mis en échec. En effet, le contrôleur de domaine ne peut pas obtenir les SID des groupes dont l’utilisateur est membre lorsque le serveur de catalogue global est indisponible. Dans ce cas le contrôleur de domaine n’émet pas de TGT et l’utilisateur ne peut pas ouvrir sa session.

8.1.3 L’importance du catalogue global dans le processus d’autorisation

Voici les étapes importantes qui sont réalisées lorsqu’un utilisateur authentifié essaye d’accéder à une ressource sur le domaine :

  1. Le client essaye d’accéder à une ressource située le réseau (ex. : serveur de fichier).
  2. Le client utilise le TGT qui lui a été remis lors du processus d’authentification pour accéder au service d’accord de ticket ou TGS (Ticket Granting Service) situé sur le contrôleur de domaine.
  3. Le TGS émet un ticket de session pour le serveur sur lequel se trouve la ressource qu’il envoie au client. Le ticket de session contient les identificateurs SID des groupes auxquels l’utilisateur appartient.
  4. Le client envoie son Ticket de session au serveur de fichier.
  5. L’autorité de sécurité locale ou LSA (pour Local Security Authority) du serveur de fichier utilise les informations du ticket de session pour créer un jeton d’accès.
  6. L’autorité LSA contacte ensuite le contrôleur de domaine et lui envoie les SIDs de tous les groupes figurant dans la liste DACL (Discretionary ACcess List) de la ressource. Le contrôleur de domaine doit ensuite joindre un serveur de catalogue global afin de connaître les identificateurs de sécurité (ou SIDs) des groupes de la liste DACL dont l’utilisateur est membre.
  7. Enfin, l’autorité LSA compare les identificateurs SID du jeton d’accès avec les SID des groupes dont l’utilisateur est membre et qui figurent dans la liste DACL. Si les groupes auxquels l’utilisateur appartient sont autorisés à accéder à la ressource alors l’utilisateur peut accéder à la ressource sinon, l’accès est refusé.

Si le serveur de catalogue global est indisponible, alors le processus d’autorisation ne peut pas se poursuivre et l’utilisateur ne peut pas accéder à la ressource.

8.1.4 La mise en cache de l’appartenance au groupe universel

La fonction de mise en cache de l’appartenance au groupe universel est disponible uniquement sur les contrôleurs de domaine exécutant Windows Server 2003 ou ultérieur. La mise en cache de l’appartenance au groupe universel consiste à stocker sur un contrôleur de domaine les résultats des requêtes effectuées auprès d’un serveur de catalogue global.

La mise en cache de l’appartenance au groupe universel est principalement utilisée lorsque deux sites sont reliés entre eux par une liaison WAN (Wide Area Network) possédant une faible bande passante (par exemple une connexion RNIS à 128Kb/s). En effet, dans ce cas de figure la connexion WAN impose diverses restrictions au niveau de l’implémentation du réseau :

Il est obligatoire de placer un contrôleur de domaine dans le site distant sinon la connexion ralentira les ouvertures de session.

Il n’est pas possible d’héberger le catalogue global sur le site distant car la réplication entre les serveurs de catalogue global entraîne un trafic réseau trop important.

Malgré le fait qu’un contrôleur de domaine soit disponible en local dans le site distant, le trafic entre les deux sites reste élevé puisque pour chaque ouverture de session ou bien chaque accès à une ressource partagée, le contrôleur de domaine accède à un serveur de catalogue global situé dans la maison mère. Une solution à ce problème est donc l’implémentation de la mise en cache de l’appartenance au groupe universel.

Lorsqu’un utilisateur du site Learning tente d’ouvrir sa session pour la première fois, il contacte le contrôleur de domaine qui va lui-même contacter le serveur de catalogue global (GS sur le schéma) afin de récupérer les SIDs des groupes dont l’utilisateur est membre. Le contrôleur de domaine va ensuite mettre en cache les informations qu’il a reçues du serveur de catalogue global pendant une durée de 8 heures (durée par défaut). La même opération (mise en cache) est effectuée lors du premier accès de l’utilisateur à une ressource partagée.

Si l’utilisateur se « logue » de manière récurrente sur le domaine ou bien si il accède régulièrement à des partages réseaux, le contrôleur de domaine du site Learning utilise les informations situées dans son cache. Cela offre trois grands avantages :

Les authentifications des utilisateurs et les accès aux ressources du réseau sont moins dépendantes de la liaison WAN.

Le trafic d’authentification et d’autorisation au niveau de la liaison WAN utilise peu de bande passante.

La résolution de l’appartenance au groupe universel est plus rapide puisque le contrôleur de domaine possède les informations nécessaires en local.