Topologie de l’authentification

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.