Un client Win2K dans un domaine AD

Voyons ce qui se passe quand on démarre une station de travail ou un serveur qui est membre d'un domaine AD. Le processus commence avec des requêtes DNS pour des enregistrements DNS de type SRV.

La station de travail recherche un DC AD adéquat pour l'authentifier au domaine.

Les comptes ordinateur
sont simplement un type spécial
de compte utilisateur : ils s’authentifient
auprès des AD de la
même manière que les utilisateurs.

La station de travail effectue une requête
DNS (par le port UDP 53)
pour tous les enregistrements SRV
qui sont enregistrés dans la zone
ldap._tcp.._sites.dc._msdcs.
, où site et domain correspondent,
respectivement, au
site AD et au domaine auxquels appartient
la station de travail. La station
de travail cache l’information
de site dans la sous-clé HKEY_LOCAL_
MACHINE\SYSTEM\ControlSe
t\Services\Netlogon\Parameters\Dy
namicSiteName. Si le nom du site
change entre des réinitialisations
de machines ou si le site n’existe
plus, la requête échouera et la station
de travail interrogera alors la
zone DNS ldap._tcp.dc._msdcs.
. Cette zone contient
en principe tous les DC disponibles
dans un domaine particulier, chacun
étant capable d’authentifier la
machine.

Le serveur DNS renvoie à la station
de travail une liste des DC pour le
site (s’il est connu) ou le domaine.

Le client fait une requête de recherche
Lightweight Directory
Access Protocol (LDAP – UDP port
389), qui demande à l’un des DC
listés de valider que le client existe
dans AD. La requête demande à AD
d’établir la correspondance avec le
nom de la station de travail, le nom
du domaine auquel la station de travail appartient, le GUID (globally
unique identifier) du domaine et le
nom du compte machine de la station
de travail. (Le nom du compte
machine est le nom du système
suivi d’un signe dollar – $ ; par
exemple, une station de travail appelée
ws1 a le nom de compte machine
ws1$.) Cette requête LDAP
est non authentifiée (c’est-à -dire,
anonyme).

Quand le DC trouve une correspondance
à la requête de la station
de travail, il envoie une réponse
« success » à la requête LDAP.

La station de travail envoie ensuite
un ping à chaque DC de la liste que
le serveur DNS a renvoyé à l’étape
3. Le premier DC qui répond traite
les requêtes d’identification de la
station de travail.
A partir de là , l’interaction entre la
station de travail (ou le serveur
membre) et le DC comporte l’authentification
de la station de travail
vis-à -vis du domaine et l’exécution
des tâches nécessaires pour
présenter un dialogue de logon à
l’utilisateur.

La station de travail entame une série
de connexions TCP/IP avec le
DC pour des services spécifiques,
comme RPC (remote procedure
call) et SMB (Server Message
Block). (Les communications RPC
ont besoin de ce processus, dans
lequel le client adresse une requête
au serveur sur le port 135 pour savoir
sur quel port un service de serveur
particulier est à l’écoute. Dès
que le client obtient cette information,
il ouvre une connexion TCP/IP
sur ce port afin de pouvoir effectuer
les communications RPC.)
Premièrement, le client ouvre une
connexion TCP vers le service mapper
de port RPC (port TCP 135)
fonctionnant sur le DC. Cette action
fait une requête au service de
logon AD. La station de travail
ouvre ensuite une connexion SMB
(port TCP 445) vers le DC, une action
qui établit une connexion vers
un file share. Les ports d’origine et
de destination pour le trafic RPC se
situent au-dessus de 1 023. Par
conséquent, si vous transmettez la
communication RPC au travers
d’un pare-feu, il vous faudra ouvrir
ces ports de numéros élevés, à
moins que vous ne puissiez restreindre
les ports que le service
RPC en question utilise.

Une fois que la station de travail a
établi ces connexions, le client utilise
Kerberos sur UDP (port 88)
pour envoyer une requête d’authentification
au DC. Si nécessaire,
vous pouvez forcer Kerberos à utiliser
TCP. (Pour plus de détails, voir
l’article Microsoft « How to Force
Kerberos to Use TCP Instead of
UDP », http://support.microsoft.
com/?kbid=244474.)

La station de travail utilise l’information
qu’elle a reçue de la part du
mapper de ports RPC à l’étape 7
pour ouvrir une connexion TCP
RPC vers le service AD Logon RPC,
qui est identifié par sa GUID (aussi
appelée UUID – universally unique
identifier) : 12345678-1234-ABCDEF00-
01234567 CFFB. Vous pouvez
voir ce processus dans la trace de
paquets Network Monitor, comme
le montre la figure 1. Dans cette
trace, SERVER222 est le nom de la
station de travail (ou du serveur
membre) et SPLEXORA-DC1 est le
nom du DC. Tout le trafic RPC pendant
cette phase de communication
entre la station de travail et le
DC est crypté, donc vous ne pouvez
pas voir les données que le
client et le serveur échangent : vous ne voyez que l’information d’entête
RPC montrée dans la trace
Network Monitor.

Le DC répond à la requête d’authentification
Kerberos de la station
de travail à l’étape 8, par le
TGT (ticket-granting ticket) de la
station de travail, qui est la clé de
session que la station de travail utilisera
pendant la durée de vie de sa
session d’authentification avec le
DC.

En utilisant le TGT et la connexion
RPC qu’elle a ouverte à l’étape 9, la
station de travail s’authentifie auprès
de l’AD en émettant une suite
de requêtes RPC R_Logon vers le
DC. Le DC honore les requêtes
quand l’information de session
Kerberos transmise est correcte
pour la station de travail.

La station de travail utilise la
connexion SMB qu’elle a créée à
l’étape 7 pour se connecter au
share IPC$ sur le DC. La station de
travail demande également au DC
s’il est au courant de quelques références
Microsoft Dfs pour le share
auquel elle est en train de se
connecter (dans ce cas, IPC$).
Cette étape se produit automatiquement
chaque fois qu’un client
se connecte à un serveur share ;
nous verrons plus loin son intérêt.

Après ouverture de la connexion
SMB, la station de travail effectue
un test de liaison lente pour déterminer
si le DC auprès duquel elle
est en train de s’authentifier répond
aux critères d’une liaison de
réseau lente. Ce test détermine le
comportement futur, comme si
certaines extensions de Group
Policy seront traitées ou non, ou
comment (ou si) un profil roaming
est téléchargé quand un utilisateur
se connecte. Le test de liaison lente
est constitué d’un ping de 60 octets
envoyé et « timed » suivi d’un ping
de 1 514 octets qui est envoyé et
« timed ». La station de travail répète
cette série trois fois et utilise la
latence de chaque ping pour déterminer
la vitesse de la liaison et voir
si elle descend au-dessous du seuil
de liaison lente prédéfinie pour la
station de travail. Ce seuil est de
500 Kbps par défaut mais vous pouvez
utiliser les paramètres de
Group Policy Administrative
Template pour modifier le seuil
chez le client.

La station de travail effectue ensuite
une requête LDAP basée sur
TCP pour obtenir des renseignements
à propos du domaine, y
compris la liste des NC (naming
contexts) que le DC supporte et le
DN (distinguished name) LDAP de
chaque NC.

La station de travail effectue ensuite
un lien LDAP authentifié, à
nouveau sur TCP/IP vers le DC. La
station de travail envoie une requête
Generic Security Service
(GSS) – SPNEGO vers le DC pour
s’authentifier. Cette requête GSSSPNEGO
indique que la station de
travail est en train de négocier le
protocole d’authentification avec le
DC. Quand à la fois le client et le
serveur le supportent, Kerberos est
le mécanisme d’authentification
préféré pour lier la station de travail
à LDAP. La figure 2 montre la trace
de paquets pour le processus de
négociation LDAP.

Ensuite, la station de travail détermine
quels GPO (Group Policy
Objects) elle doit traiter. Elle utilise
LDAP pour déterminer les objets
conteneurs (sites, domaines et OU
– organizational units) dont elle est
membre. Plus précisément, une
fois que la station de travail connaît
sa place dans la hiérarchie AD, elle
envoie une requête au DC pour
qu’il renvoie les attributs gpLink et
gpOptions pour chaque objet
conteneur.

Le DC renvoie alors les DN pour
chaque GPO que la station de travail
doit traiter. Ces DN prennent la
forme d’un chemin vers le GPC
(Group Policy Container) du GPO.
Un exemple de DN pourrait se présenter
ainsi : LDAP://CN={31B2F3
40-016D-11D2-945F-0C04FB984
F9},CN=Policies,CN=System,D
C=mycompany,DC=org.

La station de travail envoie ensuite
une requête SMB au share SYSVOL
sur le domaine (par exemple,
\\DC.mycompany.org\sysvol) pour
lire la portion GPC de chaque GPO.
Là encore, la station de travail demande
s’il existe une éventuelle information
de référence de Dfs
avant de demander à se connecter
à ce share. En fait, la requête originale
de la station de travail est pour
\\mycompany.org\sysvol, et le DC
détermine la réplique Dfs la plus
proche avant d’envoyer son information
en retour.

La station de travail utilise SMB
pour lire le contenu du GPT
(Group Policy Template) de chaque
GPO et traite la policy requise.

La station de travail utilise ensuite
NTP (Network Time Protocol) pour
se synchroniser avec son DC partenaire.

Enfin, la station de travail détermine
si elle doit être au courant
d’éventuels services de certificats
de clé publique. En utilisant LDAP,
elle demande des informations au
domaine dans le conteneur CN
=Public.Key.Services,CN=Services,
CN=Configuration,DC=mycompany,
dc=org, en demandant des objets de type NTAuthCertificates
et caCertificate.

Toutes les interactions entre deux
machines au sein d’une infrastructure
AD ne sont pas aussi compliquées ou
aussi longues que le processus que je
viens de décrire. Bien que ce processus
semble plutôt ardu, l’interaction se traduit
par un petit nombre de paquets
de réseau. Sur mon réseau, la station
de travail a traité de trois à quatre
GPO; une séquence de démarrage
classique a impliqué environ 300 paquets
et s’est effectuée en 35 secondes
environ. Si je validais NetBIOS sur le
client (mais pas sur le serveur), le
nombre de paquets augmentait d’environ
80. Ce nombre était le résultat des
services liés à NetBIOS supplémentaires,
y compris les consultations
WINS, les enregistrements machine
dans WINS et l’enregistrement auprès
du service navigateur, et les sessions
SMB qui utilisaient le port TCP 139 en
plus du port 445. Quoi qu’il en soit, le
delta global entre IP pur et Net
BIOS/TCP a été inférieur à ce que je
prévoyais.
Nous venons de voir le processus
qu’une station de travail ou un serveur
membre utilise pour s’initialiser et
s’authentifier auprès d’un domaine
AD. Vous pouvez utiliser ce genre d’information
pour le dépannage. Supposons
que vous constatiez que vos
stations de travail s’enregistrent dans
le site AD incorrect. En utilisant la liste
des DC obtenue à l’étape 2, vous pouvez
vérifier les entrées dans le serveur
DNS, vos sites AD, et le registre, pour
savoir ce qui se passe. Dans le même
esprit, supposons que certains serveurs
membres d’un réseau qui a une
DMZ (demilitarized zone) sécurisée
ont du mal à s’authentifier avec un domaine
AD dans le réseau de confiance.
Vous pouvez utiliser l’information
contenue dans la trace pour déterminer
quels ports et protocoles doivent
traverser vos pare-feu pour que l’authentification
réussisse.