Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Pourquoi utiliser Kerberos au lieu de NTLM dans IIS ?

ayi

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 ?

ayi_2

D’un point de vue Windows uniquement :
<h2><a name="p-19718-ntlm-1" class="anchor" href="#p-19718-ntlm-1" aria-label="Heading link"></a>NTLM</h2>
<ul>
<li>
fonctionne avec à la fois les clients externes (hors domaine) et internes
</li>
<li>
fonctionne avec à la fois les comptes de domaine et les comptes d’utilisateurs locaux sur la machine IIS
</li>
<li>
avec les comptes de domaine, seul le serveur nécessite une connectivité directe avec un contrôleur de domaine (DC)
</li>
<li>
avec les comptes locaux, vous n’avez besoin de connectivité nulle part <img src="//forum-microsoft.fr/images/emoji/twitter/slight_smile.png?v=15" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20">
</li>
<li>
vous n’avez pas besoin d’être connecté en tant que l’utilisateur en question pour utiliser un identifiant
</li>
<li>
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 : <a href="https://support.microsoft.com/en-us/kb/2688798"><code>MaxConcurrentAPI</code></a>, <a href="https://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication"><code>AuthPersistSingleRequest</code> (false)</a>, des DC plus rapides.) (<a href="https://blogs.technet.microsoft.com/tristank/2011/10/27/configuring-kerberos-for-sharepoint-farms-a-generic-gotchas-list/">Bonus auto-référentiel</a>.)
</li>
<li>
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).)
</li>
<li>
peut traverser n’importe quel proxy supportant les HTTP Keep-Alive
</li>
<li>
vous pourriez utiliser TLS/SSL pour contourner les autres
</li>
<li>
nécessite plusieurs allers-retours pour s’authentifier, avec de petits paquets
</li>
<li>
(modèle de journalisation : 401.2, 401.1, 200 avec nom d’utilisateur)
</li>
<li>
ne peut pas être utilisé dans les scénarios nécessitant une authentification à double saut
</li>
<li>
c’est-à-dire que les identifiants de l’utilisateur doivent être transmis à un service sur un autre ordinateur
</li>
<li>
prend en charge les anciens clients (< Win2000)
</li>
<li>
est susceptible aux divergences de niveau d’authentification LM (<a href="https://technet.microsoft.com/en-us/library/cc960646.aspx"><code>lmcompatibilitylevel</code></a> incompatibles)
</li>
<li>
est utilisé comme repli par le package Negotiate si Kerberos échoue.
</li>
<li>
(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.)
</li>
</ul>
<h2><a name="p-19718-kerberos-2" class="anchor" href="#p-19718-kerberos-2" aria-label="Heading link"></a>Kerberos</h2>
<ul>
<li></li>
</ul>
fonctionne uniquement avec les clients actuellement joints au domaine
<ul>
<li>
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)
</li>
<li></li>
</ul>
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.
<ul>
<li>
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à.
</li>
<li>
Dans les scénarios de proxy inverse (ISA/TMG), le serveur de <a href="https://msdn.microsoft.com/en-us/library/ff650469.aspx">transition de protocole</a> 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).
</li>
<li></li>
</ul>
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 – (<a href="https://blogs.msdn.microsoft.com/benjaminperkins/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication/"><code>AuthPersistNonNTLM</code></a> est toujours d’actualité ; la <a href="https://blogs.msdn.microsoft.com/spatdsg/2007/03/07/kerberos-pac-validation-what-is-it/">validation PAC Kerberos</a> était d’actualité)
<ul>
<li></li>
</ul>
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)
<ul>
<li></li>
</ul>
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
<ul>
<li>
en fait, N sauts – cela s’empile comme des Lego ! Ajoutez autant de sauts que nécessaire…
</li>
<li>
par exemple, pour permettre à <code>UserA</code> 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 ».
</li>
<li>
(Contrainte dans ce contexte signifie « mais pas autre chose », par exemple Exchange ou un autre serveur SQL)
</li>
<li></li>
</ul>
est actuellement le package de sécurité principal pour l’authentification Negotiate
<ul>
<li>
ce qui signifie que les membres du domaine Windows le préfèrent quand ils peuvent l’obtenir
</li>
<li></li>
</ul>
nécessite l’enregistrement de SPN, ce qui peut être délicat. <a href="http://blogs.technet.com/b/tristank/archive/2006/05/08/spns-r-fn.aspx">Des règles qui aident</a>.
<ul>
<li></li>
</ul>
nécessite l’utilisation d’un nom comme cible, pas d’une adresse IP
<ul>
<li></li>
</ul>
raisons pour lesquelles Kerberos pourrait échouer :
<ul>
<li>
utilisation d’une adresse IP au lieu d’un nom
</li>
<li>
pas de SPN enregistré
</li>
<li>
des SPN en double enregistrés
</li>
<li>
SPN enregistré sur le mauvais compte (<code>KRB_ERR_AP_MODIFIED</code>)
</li>
<li>
pas de connectivité DNS / DC côté client
</li>
<li>
paramètre proxy du client / zone Intranet local non utilisée pour le site cible
</li>
</ul>
Tant que nous y sommes :
<h2><a name="p-19718-basic-3" class="anchor" href="#p-19718-basic-3" aria-label="Heading link"></a>Basic</h2>
<ul>
<li>
peut faire du multi-saut. Mais le fait en exposant directement votre nom d’utilisateur et mot de passe à l’application web cible
</li>
<li>
qui peut ensuite en faire ce qu’elle veut. N’importe quoi.
</li>
<li>
« 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 »
</li>
<li>
nécessite une sécurité de la couche transport (c’est-à-dire TLS/SSL) pour toute forme de sécurité.
</li>
<li>
et ensuite, voir le problème précédent
</li>
<li>
fonctionne avec n’importe quel navigateur
</li>
<li>
(mais voir le premier problème)
</li>
<li>
nécessite un seul aller-retour pour s’authentifier (401, 200)
</li>
<li>
peut être utilisé dans des scénarios multi-saut car Windows peut effectuer une connexion interactive avec des identifiants Basic
</li>
<li>
Il peut être nécessaire de configurer le <a href="https://msdn.microsoft.com/en-us/library/aa394189"><code>LogonType</code></a> 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)
</li>
<li>
mais encore une fois, voir le premier problème.
</li>
<li>
Si vous avez l’impression que le premier problème est vraiment, vraiment important ? Il l’est.
</li>
</ul>
En résumé :
Kerberos peut être délicat à configurer, mais il existe de nombreux guides (<a href="http://blogs.technet.com/b/tristank/archive/2006/05/08/spns-r-fn.aspx">le mien</a>) qui tentent de simplifier le processus, et les outils se sont considérablement améliorés de 2003 à 2008 (<code>SetSPN</code> peut rechercher les doublons, ce qui est le problème le plus courant ; <a href="http://blogs.technet.com/b/tristank/archive/2011/10/10/psa-you-really-need-to-update-your-kerberos-setup-documentation.aspx">utilisez <code>SETSPN -S</code></a> 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.