En faisant des recherches pour mieux comprendre les environnements Windows et Active Directory, je suis tombé, comme beaucoup avant moi, sur une étrange créature nommée Kerberos. Ce protocole revient partout, il est là dès qu’on parle de connexion, d’authentification, de tickets… Bref, il méritait bien qu’on s’y attarde un peu.
J’ai préféré en parler séparément, parce que dans le monde d’Active Directory, Kerberos est un monstre à part entière – un truc tentaculaire qu’on pourrait explorer pendant des mois (et écrire un livre dessus, mais ce ne sera pas le mien, merci bien).
Alors pour le fun (et un peu cette curiosité maladive), j’ai pris le temps de disséquer Kerberos. J’ai voulu comprendre quand il intervient, pourquoi il se déclenche, et surtout comment il fait pour gérer tout ça de manière (à peu près) fluide dans un environnement souvent bordélique.
Ce que vous allez lire ici, c’est ma tentative de rendre Kerberos plus digeste. Une explication claire, illustrée, et ancrée dans un contexte réel. Et cerise sur le gâteau : un schéma complet des échanges Kerberos, que vous pourrez télécharger en PowerPoint si vous avez envie d’en coller une version imprimée dans le dos d’un collègue ou d’en faire un t-shirt (taille minimum XXL, ce n’est pas une blague). Libre à toi.
Voici donc ce fameux schéma que nous explorerons ensemble point par point, étape par étape :
Ca fait beaucoup, j’en ai conscience, mais je vous promet que ca va bien se passer. Lire cet article va prendre du temps, mais je vous garantit que vous comprendrez (plus ou moins bien) Kerberos en en lisant ces lignes.
Voici d’ailleurs une belle métaphore pour tenter de cerner le dilemme que souhaite résoudre Kerberos !
Kerberos et la métaphore du voyageur 🌍
Vous pouvez voir Kerberos comme une sorte de système d’immigration ultra organisé dans un monde où chaque service réseau est un pays indépendant avec ses propres frontières.
Vous êtes un voyageur : Vous voulez accéder à plusieurs pays (services), mais vous ne voulez pas présenter votre acte de naissance de votre pays d’origine (ton mot de passe) à chaque poste frontière. Trop risqué, trop bizarre et beaucoup trop long.
Étape 1 – Le passeport (TGT)
Vous commencez votre voyage en vous présentant à votre propre gouvernement (le KDC – plus précisément l’AS).
Vous prouvez votre identité, par exemple avec une carte d’identité nationale (votre mot de passe partagé entre vous et votre gouvernement).
Une fois validé, votre passeport vous est remis – c’est le fameux Ticket Granting Ticket (TGT).
Ce passeport ne permet pas encore de voyager, mais il prouve que vous êtes un citoyen reconnu.
Étape 2 – Les visas (tickets de service)
Vous voulez maintenant visiter d’autres pays (accéder à des services).
Vous vous rendez donc à l’ambassade centralisée (le TGS) – car dans le monde Kerberos, toutes les ambassades sont réunies en un seul bâtiment (gain de temps, pas besoin de courir partout).
Vous présentez votre passeport (le TGT), vous dites quel pays vous voulez visiter (ex : un serveur de fichiers), et l’ambassade vous délivre un visa pour ce pays spécifique.
Ce visa, c’est le ticket de service, et il est scellé (chiffré) pour que seul le pays cible puisse le lire.
Étape 3 – Le passage de frontière
Vous arrivez à la frontière du pays (le service), vous présentez votre visa.
Le garde-frontière (le service) vérifie que tout est en règle, et vous laisse entrer sans vous redemander votre passeport ou votre mot de passe (alors oui, les gardes-frontières regardent le passeport, NE CASSEZ PAS MA MÉTAPHORE !!).
Résultat : tout va bien dans le meilleur des mondes (comme dirait Leibniz selon Voltaire).
On comprend donc qu’en langage Kerberos, on a 3 acteurs :
1. Le client
C’est l’utilisateur ou le programme qui veut accéder à une ressource réseau. Ça peut être vous qui ouvrez une session Windows, un script qui se connecte à une base de données, ou un navigateur qui tente d’accéder à un portail interne.
2. Le KDC – Key Distribution Center
C’est le cœur du système Kerberos. Il fait deux choses :
- AS (Authentication Service) : il vérifie l’identité du client et lui délivre un Ticket Granting Ticket (TGT).
- TGS (Ticket Granting Service) : il prend ce TGT donné par l’AS et fournit un ticket de service, qui permettra d’accéder à la (article défini appuyant l’unicité du service accordé) ressource demandée.
Vous pouvez voir les services comme des pays : tu prouves ton identité à ton pays, ton pays te donne un passeport, tu vas dans l’ambassade de chaque pays (excepté qu’ici toutes les ambassades sont gérées par la même administration) et tu demandes un visa (le ticket de service) que tu peux montrer à chaque frontière (pays).
3. Le service (serveur applicatif, base de données, etc.)
C’est la ressource finale à laquelle vous allez accéder. Elle va recevoir votre ticket de service, vérifier qu’il est valide, et si tout est en ordre, vous ouvrir la porte sans broncher.
Et la beauté de Kerberos, c’est que votre mot de passe ne circule jamais sur le réseau. Tous les échanges sont basés sur des tickets chiffrés et des clés de session partagées.
Avant de plonger dans le schéma…
Kerberos, c’est un peu comme une montre suisse : à première vue, tout semble fluide. Mais dès qu’on soulève le capot, on découvre une mécanique complexe, avec des rouages parfaitement coordonnés. Et ici, c’est précisément ce qu’on va faire : analyser chaque rouage, chaque message, chaque rôle.
Avant de commencer, il faut le dire clairement :
- Ce qui suit est dense.
- C’est précis.
- Et c’est nécessaire pour vraiment comprendre ce qui se passe lors d’une authentification Kerberos complète.
Mais pas de panique.
On va avancer étape par étape, en s’appuyant sur un schéma détaillé que vous pourrez suivre à votre rythme. À chaque étape, on expliquera qui parle à qui, ce qu’il envoie, ce qu’il reçoit, et pourquoi. Il aura aussi plusieurs niveau d’abstraction, à chaque étape, on commencera par le simple pour aller vers le plus dur
Alors installez-vous confortablement, gardez vos cerveaux en alerte :
on commence la plongée dans le cœur de Kerberos 🙂
Étape 1 – Présentation des acteurs et des données
Niveau 1 – Vue simple
Dans une authentification Kerberos, trois grands blocs jouent un rôle :
- L’utilisateur : celui qui veut accéder à un service. Il possède des identifiants, et une « mémoire » locale (le cache) dans laquelle il stocke les tickets qu’il reçoit.
- Le KDC (Key Distribution Center) : il joue le rôle d’autorité centrale. Il est divisé en deux entités :
- le serveur d’authentification (AS), qui connaît tous les utilisateurs,
- le TGS (Ticket Granting Service), qui connaît tous les services disponibles.
- Le service : c’est la ressource finale (par exemple, une base de données). Il n’accepte de parler qu’aux utilisateurs qui présentent un ticket valide.
Chacun d’eux a des données spécifiques qu’il utilise pour échanger de manière sécurisée.
Niveau 2 – Détails techniques
Utilisateur
Dans son cache local, il va stocker tous les tickets qu’il va recevoir ou qu’il a déjà reçu, organisés par service.
Il aura aussi en sa possession un ticket de demande de service, qui lui servira… à commencer la demande de service. Ce ticket contient :
- son propre UserID (ex :
Bob), - le SPN (Service Principal Name) du service demandé (ex :
BDD SQL), - un timestamp indiquant la date-heure-minute-seconde-milliseconde d’émission,
- son adresse IP,
- la durée de vie souhaitée pour ce ticket.
Ces informations sont nécessaires pour prouver son identité et valider la session plus tard.
KDC
Le serveur d’authentification (AS) possède :
- une table des utilisateurs avec leurs identifiants (ex : Bob, Alice, Toi, Moi),
- un secret associé à chaque utilisateur : c’est souvent un hash dérivé de leur mot de passe.
Le TGS, lui, détient :
- une table des services disponibles, identifiés par leur SPN,
- et un secret pour chaque service, utilisé pour chiffrer les tickets qu’on remettra à l’utilisateur.
Service
Le service cible conserve aussi un cache local, qui contient les attributs d’authentification des utilisateurs ayant initié une session :
- l’UserID,
- et le timestamp.
Ces données serviront à vérifier que le ticket présenté est bien valide, à jour, et délivré pour le bon utilisateur.
Niveau 3 – Pour aller plus loin
- Le SPN (Service Principal Name) est une sorte d’identifiant unique d’un service sur le réseau. Il peut inclure un nom DNS, un port, ou un protocole (ex :
MSSQLSvc/sql01.contoso.com:1433). - Le timestamp est central dans tout Kerberos : il permet d’éviter les attaques par rejeu (replay), en s’assurant que chaque ticket ou authentificateur est utilisé dans une fenêtre de temps valide.
Étape 2 : L’utilisateur se présente et souhaite s’authentifier
Niveau 1 – Vue simple
C’est le tout début de la danse.
L’utilisateur (ici Bob) veut accéder à un service, mais il ne peut rien faire tant qu’il ne s’est pas présenté auprès de l’autorité centrale : le serveur d’authentification (AS) du KDC.
Il envoie donc un premier message pour annoncer son identité. Il ne fournit pas encore son mot de passe, ni de preuve directe d’authenticité. Il dit simplement :
« Bonjour, je suis Bob, et je voudrais m’authentifier. »
C’est une demande de Ticket Granting Ticket (TGT) – un sésame qui lui permettra ensuite de demander l’accès à n’importe quel service.
Niveau 2 – Détails techniques
Le message envoyé par l’utilisateur contient :
- Son UserID (Bob),
- Un timestamp (pour prouver que le message est récent),
- Optionnellement des infos comme :
- la durée de validité souhaitée pour le TGT,
- son adresse IP,
- des flags indiquant le type d’authentification attendue.
Ce message est en clair, et ne contient encore aucun mot de passe ni secret. C’est simplement une requête initiale : « Je veux un TGT, voici mon nom. »
Le KDC va maintenant vérifier s’il connaît cet utilisateur dans sa base.
Niveau 3 – Pour aller plus loin
- Cette requête est souvent appelée
AS-REQ (Authentication Service Request). - Dans Kerberos, on part du principe que l’AS connaît le secret partagé entre l’utilisateur et le KDC, généralement dérivé de son mot de passe.
- À ce stade, aucune preuve d’identité n’a encore été fournie. Le serveur d’authentification va répondre avec un message chiffré avec ce secret, de manière à ce que seul le vrai utilisateur puisse le lire. S’il y parvient, il aura prouvé son identité (ça arrive à l’étape suivante).
- Le timestamp peut être optionnel dans certains modes, mais il joue un rôle important contre les attaques par rejeu. Il sera encore plus central lors de l’authentification au TGS et au service final.
Étape 3 : Le KDC délivre un Ticket Granting Ticket (TGT)
Niveau 1 – Vue simple
L’utilisateur (Bob) a demandé à s’authentifier. Le KDC (serveur d’authentification) accepte sa demande et lui répond avec deux objets importants :
- Un ticket d’accès à la suite du système (le TGT) : ce ticket sera utilisé pour demander l’accès aux services du réseau, mais il est illisible pour Bob, car chiffré pour le TGS.
- Une clé de session (SK1), accompagnée d’informations utiles (timestamp, ID du TGS), chiffrées avec le secret de Bob (son mot de passe hashé, qu’il possède).
Si Bob arrive à déchiffrer ce deuxième message, il prouve qu’il est bien lui, et qu’il peut continuer.
Niveau 2 – Détails techniques
Le serveur d’authentification génère d’abord une clé de session SK1, qui sera utilisée entre Bob et le TGS. Ensuite, il envoie deux messages :
1. Message chiffré avec le secret de Bob :
- ID du TGS
- Timestamp
- Clé SK1
Bob pourra lire ce message s’il connaît son propre secret, ce qui prouve son identité. À ce stade, pas besoin d’envoyer le mot de passe sur le réseau : c’est le fait de pouvoir lire le message qui sert de preuve.
2. Le TGT (Ticket Granting Ticket) :
Chiffré avec la clé secrète du TGS, ce qui le rend illisible pour Bob. Il contient :
- L’UserID de Bob
- Un timestamp
- Son adresse IP
- La durée de vie du ticket accordée (alignée avec la policy de durée maximale si présent ou à défaut la durée souhaitée par l’utilisateur)
- Et la clé SK1
Ce ticket est destiné au TGS, qui sera le seul à pouvoir l’ouvrir plus tard.
Niveau 3 – Pour aller plus loin
- Le TGT est un jeton d’accès général : il ne donne pas encore accès à un service particulier, mais permet de demander n’importe quel ticket de service plus tard.
- La clé SK1 est temporaire : elle est valide uniquement pour la durée du TGT (10 heures par défaut).
- Le fait que l’utilisateur ne puisse pas ouvrir le TGT renforce la séparation des responsabilités dans le protocole : seul le TGS peut valider l’authenticité de cette requête.
- Cette étape correspond au message AS-REP (Authentication Service Reply) dans le protocole Kerberos.
Étape 4 : L’utilisateur contacte le TGS pour demander un ticket de service
Niveau 1 – Explication simple
Bob a maintenant en main un TGT (Ticket Granting Ticket) et une clé de session SK1 reçue précédemment. Grâce à ça, il peut enfin demander ce qu’il veut vraiment : un accès à un service concret, comme une base de données SQL.
Il envoie une nouvelle requête, cette fois au TGS, pour dire :
« Salut, j’ai déjà mon passeport (TGT), maintenant je voudrais un visa pour aller parler à la base de données. »
Pour ça, il assemble un message plus complexe, mais bien structuré.
Niveau 2 – Détails techniques
L’utilisateur envoie trois éléments au TGS :
1. Un User Authenticator :
Un mini-message signé par lui-même, chiffré avec la clé SK1 :
- Son UserID
- Un timestamp
Ce message sert à prouver que :
- Il connaît bien SK1 (donc qu’il a pu lire le message chiffré précédemment, il est Bob),
- Et que le message est récent (grâce au timestamp)
2. Le TGT :
Exactement celui qu’il a reçu de l’AS, sans modification. Il est toujours chiffré avec la clé secrète du TGS, donc illisible pour l’utilisateur, mais lisible pour le TGS. Ce TGT contient la clé SK1 pour que le TGS puisse lire le premier message et authentifier l’utilisateur.
3. Les informations sur le service demandé, en clair :
- Le SPN (ex :
BDD SQL) - Un timestamp pour horodater la demande
Le TGS va ensuite croiser ces trois éléments pour valider la demande et octroyé un ticket de service.
Niveau 3 – Pour aller plus loin
- Ce système en deux temps (TGT + authenticator) permet de limiter les risques de rejeu et de s’assurer que le message est bien initié par l’utilisateur en temps réel.
- Cette étape correspond au message TGS-REQ (Ticket Granting Service Request).
- Le TGS utilise sa clé secrète pour ouvrir le TGT. Il récupère à l’intérieur la clé SK1, puis utilise SK1 pour déchiffrer le authenticator envoyé par l’utilisateur.
- Si les deux timestamps sont cohérents et que l’identité correspond, alors le TGS considère que l’utilisateur est authentifié avec succès.
Étape 5 : Le TGS délivre un ticket de service
Niveau 1 – Vue simple
Le TGS a bien reçu la demande de Bob. Il a vérifié le TGT, le User Authenticator, et la cohérence des données. Tout est bon. Il peut maintenant délivrer un ticket spécifique pour le service demandé : ici, la base de données SQL.
Bob reçoit à nouveau deux messages :
- Un qu’il peut lire (contenant une nouvelle clé de session),
- Un qu’il ne peut pas lire : c’est le ticket de service, destiné au service final.
Niveau 2 – Détails techniques
Le TGS commence par générer une nouvelle clé de session SK2, destinée à être utilisée entre l’utilisateur et le service cible.
Il envoie ensuite deux blocs :
1. Message chiffré avec SK1 (lisible par Bob) :
- SPN du service demandé (
BDD SQL) - Timestamp
- Durée de vie du ticket
- Clé SK2
Grâce à SK1 (qu’il a reçu à l’étape précédente), Bob peut déchiffrer ce message et récupérer SK2.
2. Ticket de service (illisible pour Bob) :
Ce ticket est chiffré avec le secret du service (hashDeBDD) et contient :
- UserID de Bob
- SPN (
BDD SQL) - Timestamp
- Adresse IP
- Durée de vie
- Clé SK2
Ce ticket sera envoyé plus tard au service cible. Bob ne peut pas l’ouvrir, seul le service de base de données peut.
Niveau 3 – Pour aller plus loin
- Cette réponse s’appelle TGS-REP (Ticket Granting Service Reply).
- Le TGS utilise le SPN envoyé en clair pour identifier le service concerné, vérifier qu’il existe, puis retrouver son secret partagé pour chiffrer le ticket.
- Ce ticket de service est très proche du TGT dans sa forme, sauf qu’il est destiné à un service applicatif et non à une entité du KDC.
- La clé SK2 permettra à Bob et au service de chiffrer leurs échanges futurs (prochaine étape).
- À nouveau, la séparation des secrets garantit que seul le service pourra lire le ticket de service, et que Bob ne peut pas l’altérer.
Étape 6 : L’utilisateur contacte le service
Niveau 1 – Vue simple
Bob a tout ce qu’il lui faut : un ticket de service et une clé de session SK2.
Il va maintenant contacter directement le service cible (la base de données SQL), et lui dire :
« Voilà un ticket qui prouve que je suis autorisé à venir, et une preuve que c’est bien moi qui te parle. »
S’il a bien suivi toutes les étapes précédentes, le service va pouvoir vérifier son identité, et lui ouvrir la porte.
Niveau 2 – Détails techniques
L’utilisateur envoie deux messages au service :
1. Le ticket de service
Ce ticket est exactement identique à celui reçu de la part TGS puisque chiffré avec la clé de la BDD hashDeBDD, et donc illisible au yeux de notre cher ami Bob. Ce ticket de service contient :
- UserID
- SPN du service demandé
- IP de l’utilisateur
- Timestamp
- Durée de vie accordée du ticket
- La clé SK2
L’utilisateur ne peut donc pas lire ce ticket, mais il le transmet tel quel.
2. Un User Authenticator, chiffré avec SK2, qui contient :
- Son UserID
- Timestamp
Cela permet au service de s’assurer que :
- La requête vient bien de l’utilisateur qui détient le ticket,
- Et que le message est récent, évitant toute attaque par rejeu.
Niveau 3 – Pour aller plus loin
- Le ticket de service permet au service de retrouver SK2, qui devient la base de toute la session sécurisée.
- L’authenticator est utilisé exactement comme dans l’échange avec le TGS, pour vérifier l’instantanéité et l’authenticité de la requête.
- Si les UserID, timestamp et IP concordent avec ceux du ticket, et que le déchiffrement avec SK2 fonctionne, alors le service accepte l’authentification.
- On parle ici d’un message de type AP-REQ (Application Request) dans la terminologie Kerberos.
Étape 7 : Le service répond
Niveau 1 – Vue simple
Le service a bien reçu les deux messages envoyés par Bob : le ticket de service et l’authenticator. Il a pu les déchiffrer, vérifier que tout est cohérent, et surtout, qu’ils ont bien été envoyés au bon moment par la bonne personne.
Maintenant, c’est au tour du service de prouver qu’il est bien lui-même. Il envoie un dernier petit message à Bob pour dire :
« Oui, j’ai pu lire ton message et j’ai compris que tu veux accéder à
BDD SQL. Je confirme que c’est bien moi, le vrai service ; la preuve, je te l’envoie chiffré avec la clé SK2 que seul le service et toi connaissez (et le TGS, mais ça, c’est une autre histoire).»
C’est le signal de confiance mutuelle. À partir de maintenant, la session sécurisée et authentifier par les 2 parties peut commencer.
Niveau 2 – Détails techniques
Le service procède en plusieurs étapes :
- Il déchiffre le ticket de service avec sa propre clé secrète.
- Il y récupère la clé de session SK2.
- Il utilise SK2 pour déchiffrer l’authenticator, et vérifie :
- que le UserID correspond à celui du ticket,
- que le timestamp est cohérent,
- que la requête n’est pas un rejeu.
- Pour confirmer sa propre identité, le service envoie un authenticator en retour, le Service Authenticator, chiffré avec SK2 :
- Il contient typiquement le SPN du service et un timestamp récent.
Cela prouve que le service aussi détient SK2, et donc qu’il est bien légitime.
Niveau 3 – Pour aller plus loin
- Cette étape correspond au message AP-REP (Application Reply).
- Cette authentification mutuelle est optionnelle dans certaines implémentations, mais fortement recommandée pour la sécurité.
- Une fois cette étape réussie, la session sécurisée débute : toutes les communications peuvent être chiffrées avec SK2.
- Dans le contexte Microsoft (Active Directory), cette phase peut s’appuyer sur des mécanismes comme GSS-API ou SSPI, qui encapsulent tout cela de façon transparente pour les applications.
Dernier Mot
Et voilà. Bob et le service sont mutuellement authentifiés, la confiance est établie, et la communication applicative (Data Plane) peut commencer, sécurisée et sans plus jamais exposer le mot de passe de Bob.
Si vous êtes arrivé jusqu’ici, bravo. Kerberos n’est pas un protocole simple à appréhender, mais vous avez désormais une vision claire de son fonctionnement, étape par étape, et de son rôle essentiel dans les environnements Windows et Active Directory.
Ce qu’il faut retenir, c’est que Kerberos repose sur un principe fondamental : la confiance entre plusieurs entités, orchestrée par une gestion rigoureuse des secrets partagés et des tickets chiffrés.
Le tout sans jamais faire circuler de mot de passe en clair sur le réseau.
Il s’agit d’un protocole ancien, mais extrêmement présent, notamment dans les infrastructures Microsoft ou Azure. Et une fois que l’on comprend bien le flux d’authentification, analyser les erreurs, sécuriser un domaine ou détecter certaines attaques devient beaucoup plus accessible (mais tout de même très compliqué au vue de la complexité du monstre).
Schéma complet récapitulatif
Retrouvez ci-dessous le schéma global représentant l’ensemble des étapes du processus Kerberos que nous avons détaillées dans cet article :
Télécharger le schéma au format PowerPoint
Vous souhaitez le réutiliser en réunion, dans un support de formation ou simplement le modifier à votre convenance ?
Voici le lien de téléchargement :
Je vous dis à Jeudi pour un article sur Dora
Laisser un commentaire