Dans les termes les plus simples, vous pouvez considérer l'authentification Kerberos comme le mécanisme d'authentification par défaut et le plus fondamental utilisé par les environnements Windows AD.
L'authentification Kerberos repose sur le concept de tickets et de clés de session qui constituent en fin de compte ce que nous décrivons communément comme des informations d'identification. Ces informations d'identification sont utilisées pour authentifier les utilisateurs sur n'importe quel domaine requis. Ils effectuent ensuite des demandes de service pour établir une connexion chiffrée sécurisée avec un serveur cible, sur n'importe quel réseau non sécurisé. Kerberos veille à ce que tous les clients qui interagissent fournissent une preuve d'identité aux serveurs, parfois mutuellement si nécessaire, pour permettre un processus d'authentification sans faille.
Kerberos, LDAP et leur intersection : Concepts couramment confondus
Il existe souvent une certaine confusion quant aux différences et similitudes entre le fonctionnement du protocole LDAP (Lightweight Directory Access Protocol) et ce qu'offre Kerberos. Pour dissiper cette confusion, vous pouvez considérer que Kerberos fournit un service d'authentification à signature unique permettant aux clients d'accéder à plusieurs applications et services. Quant au LDAP, il s'agit d'un protocole de communication permettant de consulter, de rechercher et de modifier les données AD.
LDAP authentifie également les utilisateurs par une procédure en deux étapes. Il vérifie d'abord le nom distinctif d'un utilisateur et le mot de passe fourni par le client par rapport aux informations stockées dans la base de données LDAP. L'authentification LDAP et l'autorisation ultérieure permettent aux clients d'accéder à la base de données AD pour récupérer et gérer les données AD de manière rapide et efficace.
Kerberos et LDAP sont généralement utilisés de manière cohérente afin de garantir que les capacités individuelles offertes par les deux sont exploitées lors de la mise en place de l'environnement AD.
Le modèle d'authentification Kerberos
Le mécanisme Kerberos est analogue au chien à trois têtes, Cerbère, de la mythologie grecque. Le modèle de fonctionnement de ce protocole est conçu sur la base de trois parties :
➤ L'utilisateur, ou le client, qui demande un service donné.
➤ L'application, ou le serveur cible, fournissant le service demandé.
➤ Le serveur tiers de confiance, appelé centre de distribution de clés (KDC). Celui-ci est généralement installé sur les contrôleurs de domaine dans tout environnement AD.
Le KDC est logiquement identifié par trois composants principaux :
➤ La base de données (Db)
➤ Le serveur d'octroi de tickets (TGS)
➤ Le serveur d'autorisation (AS)
Grâce à de multiples étapes, notamment l'octroi de tickets, les contrôles de chiffrement et de déchiffrement, les tickets Kerberos contribuent au processus d'authentification.
Ce flux de protocoles explique le processus d'authentification Kerberos :
- Tout utilisateur ou client nécessitant une authentification au cours du processus de connexion, saisit un mot de passe dans le cadre du processus de connexion. Ce mot de passe est traité pour produire un hachage dérivé d'un algorithme de hachage de mot de passe.
- Le client demande un ticket d'octroi (TGT) en indiquant son nom d'utilisateur principal (UPN) au KDC. La commande Kerberos utilisée ici est KRB_AS_REQ
- Ce hachage de mot de passe est vérifié, traité, puis utilisé par l'AS du KDC pour générer une clé secrète client/utilisateur
- À ce stade, l'AS génère également une clé secrète TGS après avoir confirmé la disponibilité du TGS
- Une clé de session 1 (SK1) est traitée par l'AS, qui devient une partie de la TGT chiffrée délivrée au client pour prouver son identité initiale
- Le TGT est envoyé au client par le KDC après une recherche de l'UPN client dans la base de données du KDC. La commande Kerberos utilisée ici est KRB_AS_REP
- Le TGT contient l'ID client, l'adresse réseau client, l'horodatage, la valeur de durée de vie et le SK1. Il est important de noter que le chiffrement des informations contenues dans le TGT est réalisé à l'aide de la clé secrète client ou utilisateur ainsi que de la clé secrète du TGS
- Après avoir reçu cette réponse, le client utilise le hachage de son mot de passe pour extraire le SK1
- Chaque fois que le client a besoin d'un service ou d'un accès à une ressource particulière du réseau, le TGT devra être renouvelé à son expiration par le KDC.
Pour accéder à un service particulier, tel qu'une connexion à distance à un nouveau poste de travail, ou pour accéder à un navigateur web ou à un système de fichiers, il y a des étapes d'authentification ultérieures nécessaires pour prouver que le client est autorisé à accéder à ce service. Ces étapes sont les suivantes :
- Le client traite le TGT en sa possession, ajoute le nom de principal du service (SPN) requis, et envoie au TGS un authentifiant chiffré avec le SK1 puis par la clé secrète du TGS. La commande Kerberos utilisée ici est KRB_TGS_REQ.
- Le TGS est contacté pour demander l'initiation de la session entre le client et le serveur cible par le biais d'une clé de session de service (SK2)
- Le serveur TG utilise la clé secrète TGS pour déchiffrer l'authentifiant et extraire le SK1. Après avoir vérifié la validité du TGT et la correspondance des informations du client sur le TGT et l'authentifiant, le TGS crée le SK2
- Le KDC inclut le SK2 avec l'ID du client, l'adresse réseau, l'horodatage, etc. dans un ticket de service et l'envoie au client. La commande Kerberos utilisée ici est KRB_TGS_REP
- Ce ticket est chiffré à l'aide d'une clé secrète du serveur fournie par la Db. Il est à nouveau doublement chiffré avec le SK1 et est envoyé au client. Ce ticket contient également le certificat d'attribut de privilèges (PAC) qui indique les privilèges utilisateur pour le client, chiffré et signé par le KDC.
- Le client ne peut que déchiffrer ce ticket de service pour extraire le SK1, générer un nouveau message d'authentification, le chiffrer avec le SK2, et l'envoyer au serveur cible pour le déchiffrement final et l'authentification pour accéder au service. La commande Kerberos utilisée ici est KRB_AP_REQ.
- Le serveur cible, avec sa clé secrète, déchiffre le ticket de service. Il accède au SK2 et déchiffre l'authentifiant. Il peut d'abord s'identifier, c'est-à-dire s'authentifier auprès du client avec une commande Kerberos optionnelle KRB_AP_REP, dans les cas où une authentification mutuelle est nécessaire pour une sécurité renforcée.
- Si l'ID client et les autres informations du ticket de service et du PAC correspondent à celles de l'authentificateur, une connexion sécurisée et authentifiée est établie entre le client et le serveur cible pour offrir le service requis.
L'un des avantages les plus notables de l'utilisation de ce modèle d'authentification est que les mots de passe ne sont jamais stockés en clair et ne sont pas non plus transférés sur le réseau dans leur forme native. Kerberos n'est toutefois pas infaillible. Pour bien comprendre ce protocole, vous devrez prêter attention aux limites du flux protocolaire ainsi qu'aux vulnérabilités qui lui sont associées. Le blog sur Une approche pratique de l'Active Directory Domain Services, Partie 8 : Attaques AD vous présente les attaques AD, dont l'une porte spécifiquement sur le concept Kerberos. Restez connecté pour en savoir plus !