Les protocoles LDAP, DNS et Kerberos
Après s’être intéressé à la vue d’ensemble d’une infrastructure Active Directory, avec les notions de domaine, d’arbres et de forêts, on va creuser un peu plus dans le fonctionnement de l’Active Directory en s’intéressant à trois protocoles indispensables à son fonctionnement.
Ces trois protocoles sont le LDAP, le DNS et le Kerberos. Pour chacun d’entre eux, nous verrons à quoi ils servent et pourquoi sont-ils si vitaux au bon fonctionnement de l’Active Directory.
Sommaire
I. Le protocole LDAP
A. Qu’est-ce que le protocole LDAP ?
Le protocole « LDAP » (Lightweight Directory Access Protocol) est un protocole permettant d’accéder et d’administrer des services d'annuaire distribués. Il sert de point d’entrée pour effectuer des actions telles que la recherche, l'ajout, la suppression et la modification d'entrées dans un annuaire.
Les services d'annuaire, tels qu'Active Directory, utilisent LDAP pour interagir avec leur base de données d'informations sur les utilisateurs, les groupes, les ordinateurs, etc. Il permet ainsi aux applications et aux utilisateurs de rechercher et de récupérer des informations de manière efficace dans la base d'annuaire Active Directory.
Les communications LDAP s'effectuent sur le port « 389 » en utilisant le protocole « TCP », ce qui permet aux clients de se connecter aux contrôleurs de domaine pour interroger l'annuaire.
Une version sécurisée de LDAP, appelée « LDAPS » (LDAP over SSL), est aussi disponible mais elle n’est pas utilisée nativement par l’Active Directory. Le LDAPS utilise un chiffrement basé sur SSL/TLS pour protéger les données échangées entre les clients et le serveur LDAP. Les communications chiffrées LDAPS s’effectue sur le port « 636 », offrant une couche supplémentaire de sécurité en garantissant la confidentialité et l'intégrité des informations transmises.
Malgré tout, la sécurité des échanges LDAP en environnement Active Directory ne reposent pas exclusivement sur le LDAPS. Depuis longtemps, Microsoft a implémenté le « LDAP Signing » ou la « Signature LDAP » en français.
C’est un mécanisme de sécurité qui exige que les clients signent les requêtes LDAP. La signature LDAP garantit que la demande reçue par le contrôleur de domaine (serveur LDAP) a bien été envoyée par le client dont le message LDAP est censé provenir. Cette signature va permettre de sécuriser les connexions LDAP via « SASL Bind » (prises en charge de plusieurs mécanismes et protocoles d’authentification).
B. Que contient l’annuaire LDAP ?
L'annuaire « LDAP », utilisé par l’Active Directory, contient une structure hiérarchique d'unités d'organisation, qui forment l'arborescence permettant de classer et de gérer les objets de manière ordonnée. Par exemple, une organisation nommée « Salariés » pourra être utilisée pour regrouper tous les utilisateurs de l’annuaire correspondants aux comptes des salariés.
L'annuaire LDAP contient divers types d'objets, comme les utilisateurs, les ordinateurs, les groupes, les contrôleurs de domaine, mais aussi des objets plus spécifiques tels que des imprimantes, ou des stratégies de groupe. Chaque objet dans l'annuaire appartient à une classe, et pour chaque objet, LDAP stocke un ensemble d'attributs qui décrivent ses caractéristiques.
Par exemple, pour un utilisateur, l'annuaire stocke des attributs tels que le nom d'utilisateur, le mot de passe, le prénom, le nom de famille, l'adresse e-mail, le numéro de téléphone, etc…
C. Comment est structuré l’annuaire LDAP ?
Un annuaire est un ensemble d’entrées, ces entrées étant elles-mêmes constituées de plusieurs attributs. De son côté, un attribut est bien spécifique et dispose d’un nom qui lui est propre, d’un type et d’une ou plusieurs valeurs.
Chaque entrée dispose d’un identifiant unique qui permet de l’identifier rapidement, de la même manière que l’on utilise les identifiants dans les bases de données pour identifier rapidement une ligne.
L’identifiant unique d’un objet est appelé GUID qui est « l’identificateur unique global ». Par ailleurs, un nom unique (DN – Distinguished Name) est attribué à chaque objet, et il se compose du nom de domaine auquel appartient l’objet ainsi que du chemin complet pour accéder à cet objet dans l’annuaire (le chemin à suivre dans l’arborescence d’unités d’organisation pour atteindre cet objet).
Par exemple, le chemin d’accès suivant, correspondant à un objet appartenant à la casse « user » nommé « Florian », du domaine « it-connect.local » et étant stocké dans une unité d’organisation (OU) nommée « Salariés ».
- it-connect.local, Salariés, Florian
Se traduira en chemin LDAP par :
- CN=Florian,OU=Salariés,DC=it-connect,DC=local
Ainsi, la chaîne ci-dessus correspondra au Distinguished Name (unique) de l’objet.
Dans un chemin LDAP vers un objet, on trouve toujours la présence du domaine sous la forme « dc=it-connect,dc=local », correspondant à « it-connect.local » dans cet exemple.
II. Le protocole DNS
L’importance du protocole DNS n’est plus à prouver, nous l’utilisons chaque jour des centaines de fois, notamment pour la navigation internet et à chaque fois que l’on communique avec un serveur, pour ne citer que ces deux cas de figure.
Il en est de même pour l’Active Directory qui adore s’appuyer sur le DNS… D’ailleurs, sans le DNS, l’Active Directory ne fonctionnera pas. C’est d’ailleurs pour ça que lors de la mise en place d’un domaine, l’installation du serveur DNS est proposée.
Le protocole DNS est utilisé pour la résolution des noms, ce qui permet aux postes clients de localiser les contrôleurs de domaine au sein de votre système d’information. De la même manière, lorsque l’on souhaite joindre un client au domaine, on utilise un nom comme « it-connect.local », ce qui implique une requête DNS pour savoir quelle est l’adresse IP correspondante à ce nom, vous serez alors redirigé vers votre contrôleur de domaine qui traitera la requête.
Le serveur DNS crée une zone correspondante à votre domaine et enregistre de nombreux enregistrements. Il y a bien sûr un enregistrement (de type A) pour chaque contrôleur de domaine, mais il existe une multitude d’enregistrements annexes, indispensable au bon fonctionnement de l’Active Directory :
- Enregistrement pour localiser le « Primary Domain Controller » : correspondant au contrôleur de domaine qui dispose du rôle FSMO « Émulateur PDC ».
- Enregistrement pour localiser un contrôleur de domaine qui est catalogue global.
- Enregistrement pour localiser les KDC du domaine (concept abordé au point suivant de ce cours).
- Enregistrement pour localiser les contrôleurs de domaine du domaine cible.
- Enregistrer simplement la correspondance nom/adresse IP des différents contrôleurs de domaine. Il est également possible de créer un second enregistrement avec les adresses IPv6.
- Enregistrer les contrôleurs de domaine via le GUID pour assurer la localisation dans toute la forêt.
Ne vous inquiétez pas, concernant les notions abordées ci-dessus et qui vous sont inconnues, nous les aborderons plus loin dans ce cours.
Il est même possible que l’ensemble des ordinateurs joint au domaine soit enregistré au sein du DNS, si vous le permettez. Ainsi, un ordinateur de l’entreprise pourra être joint via : pc-01.it-connect.local s’il se nomme « pc-01 ».
Le serveur DNS peut être sur le contrôleur de domaine ou sur un autre serveur DNS du système d’information. Ce serveur DNS peut être sous Windows mais aussi sous Linux en utilisant le paquet « Bind 9 » qui requiert alors une configuration particulière.
Les contrôleurs de domaine doivent être capables d’écrire dans la zone DNS qui leur correspond. Ceci dans le but de gérer les enregistrements dynamiquement. Lors de la création d’un domaine, tous les enregistrements nécessaires au bon fonctionnement du système seront créés automatiquement (je suis sûr que ça vous rassure).
III. Le protocole Kerberos
Le protocole Kerberos est l’acteur principal de l’authentification au sein d’un domaine, il n’intervient ni dans l’annuaire ni dans la résolution de noms.
Le protocole Kerberos est un protocole mature, qui est aujourd’hui en version 5. Il assure l’authentification de manière sécurisée avec un mécanisme de distribution de clés.
A. Comment fonctionne le protocole Kerberos ?
Chaque contrôleur de domaine Active Directory dispose d’un composant appelé « Centre de distribution de clés » (KDC), qui joue un rôle central dans l’authentification en fournissant deux services :
- Le service d’authentification (Authentication Service - AS)
Ce service délivre des « TGT » (Ticket-Granting Ticket), qui sont des tickets temporaires permettant à un utilisateur ou à un appareil de demander l'accès à d'autres services ou ressources dans le domaine.
Lorsqu'un utilisateur tente de se connecter au domaine, il envoie ses informations d'identification au KDC (généralement son nom d'utilisateur et son mot de passe, ou un certificat). Si ces informations sont valides, le KDC émet un TGT, qui prouve que l'utilisateur est authentifié.
Le TGT a une durée de vie limitée, généralement configurable par l'administrateur du domaine mais peut être renouvelé automatiquement tant qu'il n'a pas expiré. Le TGT permet de ne pas avoir à réauthentifier l'utilisateur à chaque requête. La durée maximale recommandée pour un TGT est de 10 heures, soit 600 minutes.
- Le service d’émission de tickets (Ticket-Granting Service - TGS)
Une fois que le client possède un TGT, il peut demander l'accès à des ressources spécifiques (comme des fichiers partagés, des imprimantes, ou des serveurs d'application) en présentant son TGT au « Ticket-Granting Service » (TGS).
Le TGS vérifie la validité du TGT et, si tout est correct, émet un ticket de service (ou ticket TGS) spécifique à la ressource demandée. Ce ticket permet au client de se connecter à la ressource directement, sans avoir à réinteragir avec le KDC pour chaque accès.
Les tickets de service ont également une durée de vie limitée, mais peuvent être réutilisés tant qu'ils sont valides. Par exemple, une session avec un serveur de fichiers peut se prolonger tant que le ticket de service est actif.
- Le chiffrement des échanges
Kerberos repose sur l'utilisation d'un chiffrement symétrique (comme l'algorithme AES) pour protéger toutes les communications entre le client, le KDC et les services. Les tickets et les informations d'identification échangés sont chiffrés, garantissant que seules les parties autorisées peuvent les déchiffrer.
Ce mécanisme renforce la sécurité de l'authentification et empêche les attaques de type « man-in-the-middle » ou de réutilisation des tickets.
B. Importance de Kerberos dans Active Directory
Ce processus d'authentification basé sur des tickets est essentiel pour accéder aux ressources protégées dans un domaine (comme les fichiers, les applications ou les imprimantes).
Si le KDC devient indisponible, le processus d'authentification échoue. Les utilisateurs ne peuvent alors plus obtenir de nouveaux TGT ni de tickets de service, empêchant l'accès aux ressources critiques. Par conséquent, un KDC indisponible rend Active Directory inopérant sur le plan de l'authentification, entraînant des problèmes d’accès à l’ensemble des ressources du domaine.
Ceci justifie d’autant plus l’importance d’avoir au moins 2 contrôleurs de domaine.
Sachez que si l’authentification Kerberos est indisponible, le système peut basculer sur l'authentification via le protocole NTLM (NT LAN Manager), mais cela dépend du contexte. De plus, NTLM est un protocole d'authentification plus ancien, utilisé avant l'adoption de Kerberos avec Active Directory.
Contrairement à Kerberos, NTLM ne repose pas sur un mécanisme de tickets et est considéré comme moins sécurisé, car il utilise des défis-réponses avec des hachages de mots de passe, et il est vulnérable à plusieurs attaques. La bonne pratique consiste à désactiver le protocole NTLM ou à limiter son utilisation (autoriser uniquement le NTLM v2).
C. De quoi est composé un ticket Kerberos ?
Un ticket Kerberos contient plusieurs informations essentielles qui permettent d’identifier l'utilisateur ou le service auquel le ticket est attribué, et de garantir la sécurité des échanges.
Il contient notamment l’identité de l'utilisateur (identifier qui a le droit d'accéder à la ressource), la clé de session et la durée de validité. Pour les tickets délivrés par le TGS, le ticket contient également l'identité du service ou du serveur auquel le ticket donne accès. Cela garantit que le ticket ne peut être utilisé que pour accéder à la ressource spécifiée.
IV. LDAP, DNS et Kerberos en bref
En résumé, vous devez garder en tête que ces trois protocoles sont indispensables au bon fonctionnement de l’Active Directory. Ils assurent des fonctions critiques :
