Fonctionnement de Kerberos sous Windows

Processus de log on pour l’utilisateur U

La première opération de l’utilisateur U est le logon dans le domaine. À travers une séquence spéciale, appelée SAS (Secure Attention Sequence) bien connue sous la séquence CTRL+ALT+DELETE, l’utilisateur U encode ses credentials (username et password ou SmartCard) à travers LogonUI. Ces credentials sont envoyés à LSASS (Local Security Authority Subsystem) qui utilise la fonction lsalookupauthenticationpackage pour déterminer quel provider utiliser. Ensuite, les credentials sont passés au provider grâce à la fonction LsaLogonUser.

Cas où le process est abandonné :

• Credentials incorrects
• Le provider indiqué n’est pas trouvé
• La méthode de logon n’est pas acceptée (interractive logon, network, batch, service)

Le provider Kerberos entre dans un processus que nous expliquons en 6 étapes :

Version simple du fonctionnement de Kerberos

L’utilisateur U veut accéder à une ressource R sur le serveur S intégré au domaine D

1) Le client U, à travers Kerberos, contacte le KDC (Key Distribution Center) afin d’obtenir un TGT (Ticket Granting Ticket) en donnant son identité, le service name (dans le cas de AS_REQ, c’est toujours le service krbtgt) et un timestamp encrypté avec son secret (dérivé du password ou long-term-key). Ce timestamp (ainsi que d’autres données, comme l’ip et le lifetime) est en fait un authenticator qui permet de prouver au KDC que U est bien U.

2) KDC décrypte le message avec le secret partagé avec U (vérification dans sa base), vérifie la valeur du timestamp proposé (refuse si la différence entre le timestamp et son heure est de plus de 5 minutes (par défaut ou que le timestamp est plus petit ou égal au timestamp du précédent authenticator). Ensuite le service d’authentification crée une clé de session de logon (nécessaire pour s’adresser au TGS) qu’il crypte avec le secret partagé. Il crée alors le TGT qui inclut les informations de l’utilisateur (dont le user RID et les group memberships), le lifetime et la clé de session de logon cryptée. Enfin, il crypte le TGT avec son propre secret (password du compte krbtgt) et envoi à U le TGT et la clé de session de logon cryptée. Le TGT peut seulement être décrypté par un KDC valide ! Un RODC a son propre compte krbtgt avec un password propre. Ce qui veut dire qu’un utilisateur présentant un TGT provenant d’un RODC à un RWDC, le RWDC dump le TGT et en génère un nouveau.

3) Le client reçoit deux messages, le TGT et la clé de session de logon. Le client décrypte la clé de session avec son secret et le met en cache. En plus de ceci, le client stocke également le TGT dans son cache (klist permet d’afficher les tickets mis en cache). Dès lors que le client veut accéder à un service sur le réseau, il fait une demande au service Ticket-Granting-Service du KDC. Sa demande contient un authenticator encrypté avec la clé de session de logon et composé du username et d’un timestamp, le nom du service qu’il veut joindre (Service Principal Name*) et le TGT.

4) Le KDC reçoit la demande de ticket de service. Il la traite complètement seulement si le SPN est unique et le timestamp est dans le range acceptable et le TGT est valide et non expiré. Le Ticket-Granting-Service décrypte le TGT avec son secret (password de krbtgt) et extrait la clé de session de logon. Cette clé de session lui permet donc de décrypter l’authenticator. S’il y parvient avec succès, il extrait du TGT les informations de l’utilisateur. Ensuite, le TGS crée une clé de session de service.

Le TGS crée deux messages:

• un message contenant le SPN, le timestamp récupéré après avoir décrypté l’authenticator et la clé de session de service à Ce message est encrypté avec la clé de session de logon
• le Ticket de service contenant le username U, le SPN, la clé de session de service et le timestamp à ce message est encrypté avec le secret du service (long term key du server sur lequel réside le service)

5) Le client U envoie le ticket de service par une requête au serveur S. La requête contient l’authenticator (time stamp et username), qui est encrypté avec la clé de session de service et le ticket de service.

6) Le serveur reçoit la requête et décrypte le ticket de service en utilisant son secret et extrait la clé de session de service. Ensuite il utilise la clé de session de service pour décrypter l’authenticator et pour l’évaluer. Si le test est OK, le serveur encrypte l’authenticator avec la clé de session de service et renvoie l’authenticator au client. Le client décrypte l’authenticator, récupère le timestamp, et s’il s’agit du même que l’original, c’est bon la connexion s’opère, le client a accès au service demandé.

Les packets sont constitués comme suit :

*Que sont les Principal Names ?

User Principal Name (UPN)
Doit être unique au sein d’une forêt. Il s’agit d’un attribut d’un objet Active Directory. Il ne peut contenir qu’une seule valeur (exemple: bob@contoso.com)

Service Principal Name (SPN)
Doit être unique au sein d’une forêt. Il est défini au niveau du contexte de sécurité du compte pour lequel il tourne. Il est du type Service/hostname (on peut également spécifier un numéro de port). Le SPN est très important dans un domaine Active Directory. En effet, c’est grâce à lui que tous les services possibles dans un réseau Active Directory sont accédés. Ils doivent être uniques pour un type de service car sinon, KDC est dans l’impossibilité de déterminer quel host héberge le service.