Authentification Kerberos (2)

mot de passe de Joe et l’envoie
à  l’ordinateur de Joe en même
temps que le TGT. Désormais, le DC
(domain controller) et l’ordinateur de Joe ont une clé de cryptage connue
d’eux seuls parce qu’ils sont les seuls à 
connaître la clé secrète, partagée, qui
l’a cryptée : la valeur hachée du mot de
passe de Joe.

Outre la clé de session, le TGS
crypte des parties de chaque ticket
avec la valeur hachée du mot de passe
pour le service qui est la cible du ticket.
Le principal avantage de ce cryptage
partiel est que seules les deux entités
qui partagent la clé peuvent visualiser
ou modifier les données cryptées. Joe
ne peut donc pas manipuler un ticket
qui le rendrait membre du groupe global
Domain Admins pour obtenir des
privilèges sysadmin dans SQL Server.
Le cryptage partiel du ticket prouve
également au service que le DC a créé
le ticket parce que seuls le DC et le service
connaissent la clé. Enfin, il prouve
indirectement que le DC a authentifié
Joe parce qu’il n’y a pas d’autre moyen
pour Joe d’avoir un ticket crypté avec
la clé secrète du service.

Après un login réussi, l’ordinateur
de Joe a une valeur hachée du mot de
passe de Joe qu’il peut utiliser comme

• une clé secrète partagée

• un TGT qui liste tous les SID de Joe
et d’autres informations sur Joe et
son ordinateur

• une clé de session partagée qui peut
crypter le flux de données entre l’ordinateur de Joe et le DC (domain
controller)

Quand Joe reçoit la permission de
se connecter à  SQL Server, son ordinateur
reçoit un autre ticket qui contient
des informations sur Joe et son ordinateur.
Ce ticket est crypté avec la valeur
hachée du mot de passe du compte de
service SQL Server. A ce stade, chaque
entité impliquée sait que c’est vraiment
Joe qui essaie d’accéder à  une
base de données SQL Server.

Comment tout cela affecte-t-il la
performance de l’application ? En principe,
l’ordinateur client sert de courtier
pour le processus d’authentification.
Il reçoit des tickets provenant du
DC, qu’il présente ensuite aux services
qu’il veut utiliser. Comme l’ordinateur
client met en cache tous les tickets, qui
ont une durée de vie de 10 heures par
défaut avant que le client ne doive les
renouveler, le client n’a besoin de demander
un ticket pour un service
donné que deux fois par jour au plus. Il
peut ensuite utiliser ce ticket pour se
connecter à  un service autant de fois
que nécessaire jusqu’à  l’expiration du
ticket. Le processus d’authentification
semble peut-être compliqué mais, en
réalité, il ne devrait pas dégrader les
temps de connexion avec SQL Server
parce que les tickets sont mis en cache
dans la RAM.