> Tech > Un client Win2K dans un domaine AD

Un client Win2K dans un domaine AD

Tech - Par iTPro - Publié le 24 juin 2010
email

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.

  1. 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.

    Téléchargez gratuitement cette ressource

    Guide des Services Managés pour se moderniser et se sécuriser

    Guide des Services Managés pour se moderniser et se sécuriser

    À l’heure où les talents du numérique sont rares et difficiles à séduire, comment bénéficier des meilleures compétences en infrastructure Cloud ou en cybersécurité pour gagner en agilité et en cyber-résilience ? Découvrez le Guide des Services managés dédiés aux PME.

    Tech - Par iTPro - Publié le 24 juin 2010