Kerberos dans l'Active Directory : le modèle des tickets

Le principe est simple : au lieu d’envoyer un mot de passe sur le réseau (ce qui serait catastrophique), Kerberos émet des tickets que les services peuvent valider. Ces tickets permettent au client et au service d’établir la confiance en s’appuyant sur des secrets déjà connus d’AD, tandis que la communication qui suit est chiffrée à l'aide de clés de session.

Vue d’ensemble

Kerberos est un protocole d’authentification prévu pour une configuration client ↔ service.

Il assure que le client et le service soient tous les deux authentifiés.

Dans l'AD, Kerberos repose sur trois acteurs :

• Client : un compte utilisateur ou ordinateur, veut une preuve que le service n'est pas usurpé.

• Service la destination (HTTP, LDAP...) : veut une preuve que le client est bien authentifié et autorisé.

• KDC (Key Distribution Center) : le moteur d’authentification de l’AD. Le KDC émet des tickets.

Le KDC est fourni par le contrôleur de domaine qui expose les deux services Kerberos :

• AS (Authentication Server) : traite la demande initiale et émet le TGT (Ticket Granting Ticket).

• TGS (Ticket Granting Server) : utilise le TGT pour émettre les tickets de service (Service Tickets).

Un ticket est un “jeton d’accès” chiffré et signable que l’AD délivre à un client pour prouver son identité auprès d’un service.

• Service ticket : Le client présente ce ticket au service, il prouve au service cible que le client est authentifié et a le droit d’accéder à ce service précis.

• Le TGT (Ticket Granting Ticket) : prouve que le client s'est authentifié auprès de l'AS. Il est utilisé pour obtenir les tickets de services sans devoir retaper son mot de passe à chaque fois.

Quelques mots clés du jargon Kerberos :

• Authenticator : bloc de données contenant les informations du client et d'autres informations de sécurité (timestamp, nonce) chiffré avec la clé session. Il est une preuve de possession de la clé et évite les relay attacks.

• Principal : nom d'identité unique Kerberos, exemple : alice@EXAMPLE.COM, host/server01.example.com@EXAMPLE.COM

Étape par étape : du login à l'accès au service

1. Le client contacte l’AS.
   L’utilisateur s’authentifie auprès du serveur AS Kerberos en demandant un TGT.

2. L’AS vérifie lidentité.
   Si le compte est valide et bien authentifié par l'AD, l’AS renvoie :

   – un TGT, chiffré avec la clé secrète du TGS ;
   – une clé de session client ↔ TGS, chiffrée avec la clé dérivée du mot de passe de l’utilisateur.

3. Le client présente son TGT au TGS.
   Le client envoie ensuite son TGT avec un authenticator pour demander l’accès à un service précis.

4. Le TGS délivre un ticket de service.
   Si tout est valide, le TGS génère :

   – une clé de session client ↔ service ;
   – un service ticket, chiffré avec la clé secrète du service.

5. Le client se présente au service.
   Le client envoie le ticket de service au service cible, accompagné d’un nouvel authenticator.

6. Le service vérifie le ticket.
   Le service déchiffre le ticket, valide l’authenticator, puis accepte la session.

7. La session peut commencer.
   Le client et le service partagent alors une clé de session commune pour échanger de manière sécurisée.

L’intérêt de ce mécanisme est simple : le mot de passe ne circule jamais sur le réseau. À la place, Kerberos repose sur des tickets temporaires et des clés de session, ce qui limite fortement l’exposition des secrets.

La sécurité dépend fortement de la configuration du domaine, de la gestion des comptes de service et de la bonne santé du KDC. Un Kerberos mal configuré peut rapidement devenir une porte d’entrée pour des attaques comme le Kerberoasting, le pass-the-ticket ou la falsification de tickets.

C’est pourquoi la suite logique consiste à voir comment durcir Kerberos dans Active Directory, cela est détaillé dans notre 2ᵉ partie Sécuriser Kerberos dans Active Directory.

Schéma des communication kerberos permttant de créer une session sécurisée.