Lorsqu’un utilisateur tente de se connecter à un domaine AD, il essaie ensuite de communiquer avec un Contrôleur de domaine (DC) sur le même site AD, le serveur Global Catalog (GC) lit l’appartenance au groupe Universel appartenant à l’utilisateur, puis l’authentifie.
Si aucun DC n’est trouvé sur le même Site, il essaie de communiquer (via DNS) avec un autre DC sur les autres Sites. Cela signifie que cette communication est très probablement via le WAN, par exemple, pour les communications de succursales.
Si aucun DC n’est disponible, la connexion de l’utilisateur échouera.
Pour éviter de tels cas, ce que nous pouvons faire est le suivant. Placez un serveur de catalogue global sur la succursale afin que les utilisateurs puissent s’authentifier ou activer la mise en cache universelle d’appartenance à un groupe (UGMC).
La mise en cache universelle d’appartenance à un groupe a été introduite pour la première fois dans Windows Server 2003 et continue d’exister jusqu’à aujourd’hui. Auparavant, les liens entre les différentes régions étaient très lents et instables. Même le trafic de réplication du GC a eu un effet négatif sur la communication entre les différentes régions. C’est, je pense, l’une des raisons pour lesquelles UGMC est arrivé sur Windows Server.
Lorsque nous activons UGMC sur un Site et qu’un utilisateur tente de se connecter, le DC demandeur prend soin de contacter un serveur GC et d’obtenir l’appartenance au Groupe Universel de l’utilisateur, en les mettant en cache localement. Ainsi, la prochaine fois que l’utilisateur doit se connecter, la connexion sera réussie et plus rapide car il n’aura pas besoin de contacter un GC même si la liaison WAN est en panne.
L’UGMC peut être activé au niveau du site, pas au niveau DC. De plus, pour pouvoir connecter un utilisateur via UGMC, chaque utilisateur doit s’être préalablement authentifié avec succès lorsqu’un serveur de catalogue global était disponible et que l’UGMC était activé. De cette façon, le DC peut mettre en cache l’appartenance au Groupe universel des utilisateurs. Si un utilisateur ne s’est pas connecté pendant ce processus, il ne pourra pas se connecter car ses données de cache n’existeront pas sur le serveur.
L’intervalle de mise à jour automatique UGMC d’un serveur CC vers un serveur GC est de 8 heures. S’il y a des changements fréquents aux adhésions universelles, c’est une bonne idée de placer un serveur GC au lieu de la mise en cache. En outre, UGMC est utilisé lorsqu’il n’y a pas de communication avec un serveur GC. Sinon, DC essaiera d’abord de communiquer avec un GC pour l’authentification de l’utilisateur.
Voyons comment vous pouvez activer UGMC sur Windows Server (quelle que soit la version).
Activer la mise en cache Universelle de l’Appartenance à un groupe
Ouvrez la console Sites et services Active Directory et sélectionnez le Site que vous souhaitez activer la mise en cache universelle de l’appartenance à un groupe. Ici, cliquez avec le bouton droit sur l’objet Paramètres du site NTDS, puis cliquez sur Propriétés.
Dans la fenêtre qui apparaît, dans l’onglet Paramètres du site, activez l’option Activer la mise en cache universelle d’appartenance à un groupe. De plus, dans le champ Actualiser le cache depuis, choisissez le site pour actualiser le cache automatiquement toutes les 8 heures. Si vous sélectionnez Par défaut, l’actualisation se fera automatiquement à partir du site le plus proche en fonction de votre infrastructure.
Cliquez sur Appliquer et sur OK pour enregistrer vos modifications.
Enfin, notez que la fonctionnalité de mise en cache d’appartenance à un groupe universel ne fonctionne que pour l’authentification de l’utilisateur. Si, par exemple, vous avez un serveur Exchange sur l’infrastructure et que le lien vers un serveur GC n’est pas réalisable, il y aura des problèmes et UGMC ne l’aidera pas au-delà de l’authentification des utilisateurs.