Authentification Kerberos

le
contrôleur du domaine partagent toujours
le mot de passe. On pourrait
aussi utiliser une combinaison clé publique/
clé privée, mais dans la même
optique : prouver une identité.

Pour protéger le mot de passe,
Win2K le transforme au moyen d’une
fonction de « hachage » unidirectionnel,
puis stocke la valeur « hachée » à  la
place du mot de passe lui-même. La fonction de hachage distingue le mot
de passe de telle sorte que l’on peut
transmettre la valeur hachée sur le réseau
à  la place du mot de passe, sans
craindre que quelqu’un n’en déduise
le mot de passe.

Bien que Win2K puisse envoyer en
toute sécurité la valeur hachée sur le
réseau, il ne le fait pas. Kerberos utilise
encore une autre parade pour mettre
le mot de passe et la valeur hachée à 
l’abri de tierces parties indiscrètes.
Pendant l’authentification, le Kerberos
Security Provider côté client dans
Win2K crypte une chaîne qui contient
l’heure courante, en utilisant la valeur
hachée du mot de passe comme une clé. Il envoie ensuite la chaîne cryptée
résultante à  l’AS (Authentication
Service) qui s’exécute sur un contrôleur
de domaine Win2K. L’AS extrait la
valeur hachée pour le compte spécifié,
de la base de données AD et décrypte
la chaîne envoyée par le client. Si le décryptage
est réussi et si l’heure figurant
dans la chaîne est suffisamment
proche de l’heure courante sur le
contrôleur du domaine, l’AS a la certitude
que l’utilisateur de l’ordinateur
client connaît le secret partagé (le mot
de passe). Pour une explication détaillée
du principe de fonctionnement
du processus d’authentification, voir le
chapitre 3 de Understanding Microsoft
Windows 2000 Distributed Services par
David Chappell (Microsoft Press,
2000).

Une clé secrète et partagée a un
autre mérite que la seule authentification.
Si le DC (domain controller) et un
service sont les deux seules entités à 
connaître la clé, elles peuvent crypter
les données afin d’être les seules à 
pouvoir la lire. Ainsi, Kerberos protège
les données sensibles dans les tickets
qu’il utilise pour permettre à  des entités
de se parler. Tous les services ont
besoin d’un ticket avant que l’utilisateur
puisse en bénéficier. Prenons un
exemple pour illustrer le processus de
ticketage.

Quand l’utilisateur Joe se connecte
à  son ordinateur, le Win2K Local
Security Authority et le Kerberos Security Provider collaborent avec le
DC (domain controller) pour authentifier
son couple compte/mot de passe.
Si l’authentification est positive, le TGS
(Ticket Granting Service), qui s’exécute
sur le DC avec l’AS, envoie un TGT
(Ticket Granting Ticket) à  l’ordinateur
de Joe. Le
TGT contient des informations sur le
SID de Joe et sur les SID de tous les
groupes de domaines auxquels son
compte appartient. Le TGS a besoin de
ces informations pour pouvoir créer
de nouveaux tickets grâce auxquels Joe utilisera d’autres services, à  la fois sur
son propre ordinateur et sur les autres
ordinateurs du réseau.