C’est une chose que je n’ai jamais vraiment pu expliquer aussi bien que je le voudrais : Quel est le véritable avantage d’utiliser l’authentification Kerberos dans IIS au lieu de NTLM ?
J’ai vu beaucoup de gens galérer à le configurer (moi y compris) et je n’ai pas pu trouver une bonne raison de l’utiliser. Il doit pourtant y avoir des avantages assez significatifs, sinon cela ne vaudrait pas tout ce mal pour le configurer, n’est-ce pas ?
D’un point de vue Windows uniquement :
fonctionne avec à la fois les clients externes (hors domaine) et internes
fonctionne avec à la fois les comptes de domaine et les comptes d’utilisateurs locaux sur la machine IIS
avec les comptes de domaine, seul le serveur nécessite une connectivité directe avec un contrôleur de domaine (DC)
avec les comptes locaux, vous n’avez besoin de connectivité nulle part 
vous n’avez pas besoin d’être connecté en tant que l’utilisateur en question pour utiliser un identifiant
Aparté : il n’est pas si rare qu’un DC soit submergé par un serveur NTLM occupé (IIS, Exchange, TMG/ISA, etc.) avec le volume de requêtes NTLM (pour atténuer : MaxConcurrentAPI, AuthPersistSingleRequest (false), des DC plus rapides.) (Bonus auto-référentiel.)
nécessite une connectivité client uniquement vers le serveur IIS (sur le port du site, rien d’autre. C’est-à-dire tout passe par HTTP (ou HTTPS).)
peut traverser n’importe quel proxy supportant les HTTP Keep-Alive
vous pourriez utiliser TLS/SSL pour contourner les autres
nécessite plusieurs allers-retours pour s’authentifier, avec de petits paquets
(modèle de journalisation : 401.2, 401.1, 200 avec nom d’utilisateur)
ne peut pas être utilisé dans les scénarios nécessitant une authentification à double saut
c’est-à-dire que les identifiants de l’utilisateur doivent être transmis à un service sur un autre ordinateur
prend en charge les anciens clients (< Win2000)
est susceptible aux divergences de niveau d’authentification LM (lmcompatibilitylevel incompatibles)
est utilisé comme repli par le package Negotiate si Kerberos échoue.
(pas « si l’accès est refusé avec Kerberos », Kerberos doit échouer pour que NTLM soit utilisé – généralement cela ressemble à l’impossibilité d’obtenir un ticket. Si le client obtient un ticket et qu’il n’est pas parfait, cela ne provoque pas de repli.)
fonctionne uniquement avec les clients actuellement joints au domaine
nécessite une connectivité client vers un DC AD (tcp/udp 88) ET le serveur (les tickets sont récupérés par le client depuis le DC via le port Kerberos, puis fournis au serveur via HTTP)
pourrait traverser un proxy, mais voir le point sur le DC ci-dessus : vous devez toujours être sur le même réseau qu’un DC actif, tout comme le serveur.
donc en théorie, si vous aviez un domaine dans lequel des clients connectés à Internet communiquaient directement avec un DC connecté à Internet, c’est réalisable. Mais ne faites pas cela sauf si vous le saviez déjà.
Dans les scénarios de proxy inverse (ISA/TMG), le serveur de transition de protocole doit être sur ce réseau, pas le client… mais alors le client n’est pas vraiment celui qui effectue la partie Kerberos (nécessairement – pensez à la transition d’authentification par formulaires vers Kerberos).
le ticket a une longue durée de vie (10h), ce qui signifie moins de communication avec le DC pendant la durée de vie du ticket – et pour souligner : cela pourrait économiser des milliers à des millions de requêtes par client pendant cette durée – (AuthPersistNonNTLM est toujours d’actualité ; la validation PAC Kerberos était d’actualité)
nécessite un seul aller-retour pour s’authentifier, mais la taille de la charge utile d’authentification est relativement importante (généralement 6-16K) (401, {taille du token (encodé)} 200)
peut être utilisé avec la délégation (“veuillez toujours utiliser la délégation contrainte”) pour permettre les scénarios à double saut – c’est-à-dire l’authentification Windows de l’utilisateur connecté vers le service suivant
en fait, N sauts – cela s’empile comme des Lego ! Ajoutez autant de sauts que nécessaire…
par exemple, pour permettre à UserA d’accéder à IIS, et pour qu’IIS usurpe l’identité de ce même compte utilisateur Windows lorsqu’il accède à un autre ordinateur SQL Server. C’est la « délégation d’authentification ».
(Contrainte dans ce contexte signifie « mais pas autre chose », par exemple Exchange ou un autre serveur SQL)
est actuellement le package de sécurité principal pour l’authentification Negotiate
ce qui signifie que les membres du domaine Windows le préfèrent quand ils peuvent l’obtenir
nécessite l’enregistrement de SPN, ce qui peut être délicat. Des règles qui aident.
nécessite l’utilisation d’un nom comme cible, pas d’une adresse IP
raisons pour lesquelles Kerberos pourrait échouer :
utilisation d’une adresse IP au lieu d’un nom
pas de SPN enregistré
des SPN en double enregistrés
SPN enregistré sur le mauvais compte (KRB_ERR_AP_MODIFIED)
pas de connectivité DNS / DC côté client
paramètre proxy du client / zone Intranet local non utilisée pour le site cible
Tant que nous y sommes :
peut faire du multi-saut. Mais le fait en exposant directement votre nom d’utilisateur et mot de passe à l’application web cible
qui peut ensuite en faire ce qu’elle veut. N’importe quoi.
« Oh, un administrateur de domaine vient d’utiliser mon application ? Et je viens de lire ses courriels ? Puis de réinitialiser son mot de passe ? Oh. Dommage »
nécessite une sécurité de la couche transport (c’est-à-dire TLS/SSL) pour toute forme de sécurité.
et ensuite, voir le problème précédent
fonctionne avec n’importe quel navigateur
(mais voir le premier problème)
nécessite un seul aller-retour pour s’authentifier (401, 200)
peut être utilisé dans des scénarios multi-saut car Windows peut effectuer une connexion interactive avec des identifiants Basic
Il peut être nécessaire de configurer le LogonType pour accomplir cela (je crois que la valeur par défaut a changé vers network cleartext entre 2000 et 2003, mais je me trompe peut-être)
mais encore une fois, voir le premier problème.
Si vous avez l’impression que le premier problème est vraiment, vraiment important ? Il l’est.
En résumé :
Kerberos peut être délicat à configurer, mais il existe de nombreux guides (le mien) qui tentent de simplifier le processus, et les outils se sont considérablement améliorés de 2003 à 2008 (SetSPN peut rechercher les doublons, ce qui est le problème le plus courant ; utilisez SETSPN -S chaque fois que vous voyez un guide utilisant -A, et la vie sera plus agréable).
La délégation contrainte vaut à elle seule le prix d’admission.