Kerberos en Active Directory

Un domaine Active Directory repose sur quatre briques : un annuaire interrogé en LDAP, un service de noms (DNS), des stratégies appliquées aux machines, et un protocole d’authentification, Kerberos. C’est ce dernier qui décide, à chaque connexion à un partage, à une base ou à un site intranet, si l’utilisateur est bien celui qu’il prétend être.

Cette note décortique Kerberos tel qu’il fonctionne dans un domaine Windows. Elle suit le plan de l’excellent article de Pixis sur hackndo, dont les schémas sont remplacés ici par des animations : chaque étape peut être rejouée, en avant comme en arrière.

Le problème à résoudre

Un utilisateur veut accéder à un service sur le réseau. Deux contraintes :

• son mot de passe ne doit jamais circuler, même chiffré ;
• le serveur qui héberge le service ne doit pas avoir à connaître le mot de passe de tout le monde.

Kerberos résout ce problème en ajoutant un tiers de confiance, le KDC (Key Distribution Center). Dans un domaine Active Directory, c’est le contrôleur de domaine qui joue ce rôle. Trois acteurs, donc : le client, le KDC et le serveur du service. Trois échanges aussi :

1. AS (Authentication Service) : le client prouve son identité au KDC et reçoit un TGT (Ticket-Granting Ticket) ;
2. TGS (Ticket-Granting Service) : avec ce TGT, il demande au KDC un ticket pour un service précis ;
3. AP (Application) : il présente ce ticket au service.

On peut se représenter une fête foraine. À l’entrée, on montre ses papiers une fois et on reçoit un bracelet nominatif : c’est le TGT. Pour chaque manège, on passe au guichet, bracelet au poignet, et on repart avec un ticket valable pour ce manège seulement : le ticket de service. Le forain, enfin, ne rappelle jamais l’entrée : il regarde le tampon du ticket, qu’il sait impossible à imiter.

Qui connaît quelle clé

Tout Kerberos tient dans la répartition des secrets. Chaque compte du domaine, utilisateur ou machine, a une clé dérivée de son mot de passe. Chacun ne connaît que la sienne. Le KDC, lui, les connaît toutes, plus une qui n’appartient qu’à lui : celle du compte krbtgt.

Suivons maintenant l’utilisateur pixis, qui veut ouvrir un partage sur le serveur SERV01.

Authentication Service : obtenir un TGT

KRB_AS_REQ

pixis commence par demander un TGT au KDC. Sa requête contient son nom, en clair, et l’heure courante chiffrée avec sa propre clé. Cet horodatage chiffré est la pré-authentification : il prouve que l’expéditeur connaît le secret de pixis, sans le dévoiler.

Le KDC cherche pixis dans sa base, récupère sa clé et tente de déchiffrer l’horodatage. S’il obtient une heure cohérente avec la sienne, la demande vient bien de quelqu’un qui connaît le secret de pixis. Sinon, elle est rejetée.

KRB_AS_REP

Le KDC génère alors une clé de session, aléatoire et limitée dans le temps, puis répond avec deux éléments :

• la clé de session, chiffrée avec la clé de pixis ;
• le TGT, chiffré avec la clé krbtgt. Il contient le nom de pixis, sa période de validité, la même clé de session et le PAC (Privilege Attribute Certificate), qui liste l’identifiant de pixis (son SID) et ceux de ses groupes.

pixis ouvre la première partie et récupère la clé de session. Le TGT, en revanche, lui reste illisible : seul le KDC peut l’ouvrir. pixis le garde tel quel, pour le présenter plus tard.

Le TGT n’a rien de secret : quelqu’un qui l’intercepte ne peut ni le lire, ni s’en servir sans la clé de session qui l’accompagne. L’étape suivante montre pourquoi.

Ticket-Granting Service : obtenir un ticket de service

KRB_TGS_REQ

pixis veut utiliser le service CIFS (le partage de fichiers) de SERV01. Il envoie au KDC :

• son TGT, sans y toucher ;
• le nom du service visé, son SPN (Service Principal Name) : CIFS/SERV01 ;
• un authentifiant : son nom et l’heure, chiffrés avec la clé de session.

Le KDC ne garde aucun état entre deux échanges : tout ce qu’il doit savoir est dans le TGT. Il l’ouvre avec la clé krbtgt, y lit l’identité de pixis et la clé de session, puis déchiffre l’authentifiant avec cette clé. Si les deux concordent, l’auteur de la demande possède le TGT et connaît la clé de session : c’est bien pixis.

KRB_TGS_REP

Le KDC retrouve ensuite le compte qui porte le SPN CIFS/SERV01, ici le compte machine SERV01$, et prépare :

• un ticket de service : nom du service, identité de pixis, PAC et une nouvelle clé de session, le tout chiffré avec la clé de SERV01$ ;
• cette nouvelle clé de session, chiffrée avec la première.

Accès au service

KRB_AP_REQ

pixis envoie à SERV01 le ticket de service et un nouvel authentifiant, chiffré avec la seconde clé de session. Le serveur ouvre le ticket avec sa propre clé : seul le KDC la connaît par ailleurs, le ticket vient donc forcément de lui. Il y trouve la clé de session, déchiffre l’authentifiant et compare. Tout concorde : pixis est authentifié.

Reste la question des droits, que Kerberos ne tranche pas : le serveur la règle à partir du PAC, en confrontant le SID et les groupes de pixis aux permissions du partage. Si le client le demande, le serveur prouve à son tour son identité par une KRB_AP_REP.

Récapitulatif

Une fois les étapes vues une par une, l’ensemble se lit d’un trait. Ci-dessous, pixis ouvre sa session puis accède au partage de SERV01. Le TGT obtenu au début reste en cache : tant qu’il est valide, il suffit pour demander d’autres tickets, sans repasser par le mot de passe.

klist

Conclusion

Kerberos est conçu pour qu’aucun secret d’authentification ne circule : chaque message n’est lisible que par l’acteur qui doit le lire, et chaque ticket porte la preuve de son origine. Quelqu’un qui écoute tout le trafic récupère des tickets, jamais les clés de session qui permettraient de s’en servir.

Ses faiblesses viennent surtout de ce qui l’entoure : des mots de passe faibles sur des comptes de service, des comptes sans pré-authentification, des délégations trop larges. Chacun de ces points mérite sa propre note.