Topologie de l'authentification

par Gil Kirkpatrick - Mis en ligne le 15/01/2004

Configurez les enregistrements SRV DNS pour accélérer l'authentification

Vous êtes chargé de concevoir un nouveau déploiement d'AD (Active Directory) Windows 2000 pour un réseau de plus de 10 000 utilisateurs et plus de 300 serveurs répartis sur 30 emplacements physiques, reliés par des lignes T1 parfois surchargées. Quel est votre plus gros souci ?Vous êtes chargé de concevoir un nouveau déploiement d'AD (Active Directory) Windows 2000 pour un réseau de plus de 10 000 utilisateurs et plus de 300 serveurs répartis sur 30 emplacements physiques, reliés par des lignes T1 parfois surchargées. Quel est votre plus gros souci ? Si vous êtes comme la plupart des concepteurs d'AD, la réplication est ce qui vous réveille à  3 heures du matin et continue à  vous préoccuper après votre quatrième tasse de café de 10 heures. Pourtant, aussi importante soit-elle, votre topologie de réplication n'est probablement pas ce qui devrait vous mobiliser le plus. En exploitation classique, la réplication ne représente qu'une partie relativement petite du trafic réseau qu'AD génère et une latence de réplication de bout en bout, même de quelques heures, ne gêne pas vraiment les utilisateurs. Mais si vous laissez le temps d'authentification d'AD, même d'un seul utilisateur, dépasser 20 secondes environ, vous pouvez parier que le téléphone du Help desk va sonner. Quand vous comprendrez la manière dont les clients AD localisent un DC (domain controller) visà - vis duquel ils pourront s'authentifier, vous pourrez configurer vos clients et DC pour réduire le temps d'authentification et améliorer la performance globale.

Quand un DC s'initialise et, périodiquement pendant son fonctionnement, le service Netlogon du DC utilise le protocole DDNS (dynamic DNS) pour publier des enregistrements SRV DNS (voir l'encadré « Enregistrements SRV DNS » pour plus d'informations sur le format de ces enregistrements). Ces enregistrements SRV décrivent les types de services prodigués par le DC - par exemple, l'authentification Kerberos, l'accès au répertoire basé sur LDAP (Lightweight Directory Access Protocol) et les consultations GC (Global Catalog) AD. Les DC AD organisent les enregistrements SRV de manière hiérarchique afin que les clients puissent trouver les DC qui offrent un service spécifique dans un domaine ou dans un site et domaine particuliers.
La figure 1 montre la hiérarchie de nommage DNS que les DC utilisent pour publier leurs enregistrements SRV. Vous avez probablement vu cette structure dans votre DNS Win2K. Elle permet aux clients de localiser les services même quand lesdits clients ne connaissent pas parfaitement les caractéristiques d'un service. Ainsi, pour trouver n'importe quel GC dans la forêt, le client se contente d'indiquer le nom de la forêt et le protocole à  rechercher (c'est-à -dire, chercher le domaine forestname.-tcp pour les enregistrements SRV _gc. Ce type de recherche donnerait les enregistrements SRV pour tous les serveurs GC dans la forêt spécifiée. Si le client connaît un nom de site AD spécifique, il peut chercher les enregistrements SRV gc dans le domaine forestname._ sites.sitename._tcp. Ce type de recherche produira les GC dans le site spécifié.
Le fait de publier ces enregistrements SRV dans DNS aide les clients à  trouver les DC qui traiteront le mieux leurs requêtes. Quand un ordinateur client s'authentifie vis-à -vis d'un domaine, il doit d'abord trouver un DC dans son domaine et s'authentifier visà - vis de lui. Pour être le plus performant possible, l'ordinateur client doit choisir un DC dans son site AD.
Le processus Netlogon du client traite le processus d'authentification côté client et le composant DC Locator de Netlogon est chargé de trouver un DC vis-à -vis duquel il s'authentifiera. Dans les versions antérieures de Windows, le DC Locator du client utilise WINS pour trouver un DC. En revanche, les machines Win2K et les autres clients de type AD recherchent les enregistrements SRV DNS appropriés.
La première fois qu'une station de travail s'authentifie à  son domaine, elle ne sait pas à  quel site elle appartient, donc sa première tâche consiste à  trouver n'importe quel DC dans le domaine. La station de travail émet une requête DNS pour des enregistrements SRV _ldap dans le domaine _tcp.dcs_msdcs.domainname. Le client interroge le service DNS primaire spécifié dans sa configuration TCP/IP. Si le client n'obtient pas de réponse de son service DNS, il se replie sur les services DNS suivants que la configuration TCP/IP spécifie.
Le service DNS répond par une liste d'enregistrements SRV qui correspondent à  tous les DC dans le domaine du client. Le client prend les enregistrements dont la valeur de priorité est la plus basse et émet un ping AD (qui est en réalité une requête LDAP sur UDP) pour chaque DC à  tour de rôle. Si un DC ne répond pas en un dixième de seconde, le client essaie le DC suivant, et ainsi de suite, jusqu'à  ce qu'un DC réponde.
Quand un DC reçoit un ping AD de la part d'un client, il calcule deux informations cruciales avant d'envoyer une réponse. Tout d'abord, le DC détermine le site le plus proche du client ; pour cela, il compare l'adresse IP dans le paquet de requêtes avec une structure de données en mémoire qui contient les associations de sites et de subnets définis dans les objets du site de l'AD. Le DC détermine aussi s'il est dans le site le plus proche (du point de vue de la topologie IP) du site du client. Le DC envoie cette information et le nom du site du DC répondant dans une réponse UDC au client.
Quand le client reçoit cette réponse, il détermine si le DC répondant est dans le site le plus proche du sien. Si oui, le client sauvegarde le nom du site client renvoyé dans l'entrée DynamicSiteName de la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\Netl ogon\Parameters et utilise ce DC pour d'autres requêtes d'authentification de domaine. Si la réponse du DC indique que le DC n'est pas dans le site le plus proche du site du client, le client revient à  DNS pour trouver le DC dans le site le plus proche. Cette fois-ci, comme le client connaît son nom de site, il demande à  DNS les enregistrements SRV _ldap dans le domaine _tcp.sitename.sites.dc._msdcs.domain name. DNS répond avec une liste des enregistrements SRV pour les DC présents dans le site spécifié. Le client sélectionne à  nouveau les enregistrements SRV de plus basse priorité et émet des pings AD vers chacun à  tour de rôle, jusqu'à  ce que l'un d'eux réponde dans un dixième de seconde.
Que se passe-t-il si aucun DC dans le site du client ne répond ? Dans ce cas (rare heureusement), le client s'en tient au DC original, peut-être très éloigné.
Voyons quelques exemples concrets. La figure 2 montre un réseau comportant deux sites : un à  Scottsdale, Arizona, et un à  Amsterdam, Pays- Bas. Chaque site contient un DC : DCSC1 et DCAM1, respectivement. DSCS1 est le serveur DNS primaire pour la nouvelle station de travail WSSC1. WSSC1 interroge d'abord son serveur DNS (c'est-à -dire, DNSSC1) pour demander s'il y a un DC dans le domaine ds.megacorp.com et DNS répond avec les enregistrements SRV pour DCAM1 et DCSC1. WSSC1 envoie ensuite un ping AD sur le WAN à  DCAM1, qui répond dans un délai de 100 millisecondes (ms). DCAM1 renvoie le nom du site du WSSC1 (c'est-à dire, Scottsdale) et un drapeau indiquant que DCAM1 n'est pas dans le site le plus proche de Scottsdale. WSSC1 réinterroge DNSSC1, cette fois en demandant les DC dans le site Scottsdale. DNSSC1 renvoie l'enregistrement SRV pour DCSC1. WSSC1 envoie un ping AD à  DCSC1 et obtient une réponse disant que DCSC1 se trouve dans le site le plus proche de WSSC1. WSSC1 s'authentifie auprès de DCSC1 et stocke son nom de site (c'est-à -dire, Scottsdale) dans la valeur Dynamic- SiteName de la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEM\Cur rentControlSet\Services\Netlogon\Para meters. La prochaine fois que WSSC1 s'authentifiera, il utilisera automatiquement le nom du site dans DynamicSiteName, accélérant ainsi les authentifications suivantes.
Supposons que WSSC1 soit un portable et que l'utilisateur se rende au bureau d'Amsterdam. Quand il branche le portable au réseau d'Amsterdam, l'appareil reçoit une nouvelle adresse IP et un nouveau serveur DNS de la part du serveur DHCP local. Mais, cette fois-ci, les transactions sont quelque peu différentes. Comme on le voit figure 3, WSSC1 interroge le serveur DNS, DNSAM1, au sujet des DC dans le site Scottsdale parce que ce site est enregistré dans la valeur de registre DynamicSiteName du portable. DNSAM1 envoie des renseignements précis pour DCSC1. WSSC1 envoie un ping AD à  DCSC1, lequel répond qu'il n'est pas dans le site le plus proche du site de WSCC1 et que le site de WWSSC1 est désormais Amsterdam. WSSC1 interroge ensuite DNSAM1 à  propos des DC dans le site Amsterdam et reçoit la réponse DCAM1. WSSC1 envoie un ping AD à  DCAM1 et obtient une réponse disant que DCAM1 est dans le site le plus proche du site de WSCC1. WSSC1 s'authentifie vis-à -vis de DCAM1 et stocke le nom de site Amsterdam dans la valeur de registre DynamicSiteName.
Qu'advient-il si tous les DC du site d'un client sont en panne ou sans réaction ? Dans ce cas, le client se replie sur le DC qui a fourni son information de site. Ce DC est en principe dans un autre site, ce qui signifie que le client s'authentifie auprès d'un DC distant et établit un canal sécurisé avec lui sur le WAN - ce qui n'est pas bon pour la performance. Dans de telles circonstances, le processus Netlogon du client essaie de redécouvrir un DC dans le site le plus proche chaque fois qu'il y a une autre tentative d'authentification vis-à -vis du domaine. Vous pouvez définir la valeur CloseSiteTimeout de la sous-clé de registre HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Se rvices\Netlogon\Parameters d'après le nombre de secondes qui doivent s'écouler avant que Netlogon ne tente de redécouvrir son DC. La valeur par défaut est de 900 secondes (c'est-à dire, 15 minutes) ; Netlogon acceptera des valeurs comprises entre 60 et 4 233 600 secondes (c'est-à -dire, entre une minute et 49 jours).
Parfois, vous ne voulez pas qu'un client AD détermine son appartenance au site par la requête DC classique. Supposons que vous ayez un serveur membre avec deux NIC sur différents subnets. Vous ne pouvez pas spécifier à  quel subnet le système appartient simplement en définissant la valeur de registre DynamicSiteName parce que Netlogon redéfinit cette entrée. Toutefois, le service Netlogon du client donne un moyen de contourner le calcul d'appartenance au site : donnez à  la valeur SiteName de la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\Netl ogon\Parameters le nom du site dont vous voulez que le client soit membre. Comme la valeur SiteName demande une chaîne, vous devez entrer un nom du genre Amsterdam. Soyez conscient que la manipulation manuelle du registre présente un risque : prenez la précaution de sauvegarder vos données avant de procéder à  une telle manipulation.

iTPro.fr - La rédaction
Le comité éditorial du site iTPro.fr est composé de journalistes informatiques, experts et contributeurs spécialistes des services, solutions et technologies informatiques d’entreprise.

Participez aux Microsoft IT CampsBénéficiez de formations gratuites, ouvertes et interactives animées par des architectes Microsoft ! Les Microsoft IT Camps sont un nouveau format d'évènement d'une demi-journée vous proposant d'apprendre par la pratique et comprendre comment les solutions Microsoft répondent à vos enjeux au quotidien.Découvrez les thèmes des IT Camps