Pourquoi utiliser Kerberos au lieu de NTLM dans IIS?

Question

C'est quelque chose auquel je n'ai jamais vraiment pu répondre aussi bien que j'aime: Quel est le réel avantage d'utiliser l'authentification Kerberos dans IIS au lieu de NTLM?

J'ai vu beaucoup de gens avoir vraiment du mal à le configurer (moi y compris) et je n'ai pas été en mesure de trouver une bonne raison de l'utiliser. Il doit cependant y avoir des avantages assez importants, sinon cela ne vaudrait pas la peine de l'installer, non?

Answer 1

Du point de vue de Windows uniquement:

NTLM

• fonctionne avec les deux externe (hors domaine) et interne clients
• fonctionne avec les comptes de domaine et les comptes d'utilisateurs locaux sur le IIS case
  • en utilisant des comptes de domaine, seul le serveur nécessite une connectivité directe à un contrôleur de domaine (DC)
  • en utilisant des comptes locaux, vous n'avez besoin de connectivité nulle part :)
  • vous n'avez pas besoin d'être connecté en tant qu'utilisateur en question pour utiliser un identifiant
  • A part: il n'est pas 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) , contrôleurs de domaine plus rapides.) ( Bonus auto-référentiel .)
• nécessite une connectivité client uniquement au serveur IIS (sur le port du site, rien d'autre. ie Tout se passe sur HTTP (ou HTTPS).)
• peut traverser n'importe quel proxy prenant en charge HTTP Keep-Alive s
  • vous pourrez peut-être utiliser TLS/SSL pour contourner les autres
• nécessite plusieurs allers-retours pour s'authentifier, avec petits paquets
  • (le modèle de journal est 401.2, 401.1, 200 avec le nom d'utilisateur)
• ne peut pas être utilisé dans les scénarios où une authentification à double saut est requise
  • c'est-à-dire que les informations d'identification de l'utilisateur doivent être transmises à un service sur un autre ordinateur
• prend en charge les anciens clients (<Win2000)
• Est sensible aux écarts de niveau d'authentification LM (incompatibles lmcompatibilitylevel )
• est utilisé comme solution de rechange par le package Negotiate si Curb échoue.
  • ( pas "si l'accès est refusé avec Curb", Curb doit break pour NTLM à utiliser - cela ressemble généralement à ne pas obtenir de ticket. Si le client obtient un ticket et qu'il n'est pas parfait, cela ne provoque pas de repli.)

Kerberos

• fonctionne avec actuellement clients joints au domaine uniquement
  • nécessite une connectivité client à un AD DC (tcp/udp 88) ET au serveur (les tickets sont récupérés par le client depuis le DC via le port Curb, puis fournis au serveur via HTTP)

• pourrait être capable de traverser un proxy, mais voir DC point 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 les clients connectés à Internet discutaient directement avec un DC connecté à Internet, c'est réalisable. Mais ne faites pas ça sauf si vous le saviez déjà.
  • Dans les scénarios de proxy inverse (ISA/TMG), le serveur transition de protocole doit être sur ce réseau, c'est-à-dire pas le client ... mais alors le client n'est pas vraiment celui qui fait le bit Kerberos ( nécessairement - pensez que Forms auth à Curb transition).

• le ticket a une longue durée de vie (10h) signifie moins DC communication pendant la durée de vie du ticket - et pour souligner: cela pourrait sauver des milliers de millions de demandes par client pendant cette durée de vie - - (AuthPersistNonNTLM est toujours une chose; validation Kerberos PAC était une chose)

• nécessite un aller-retour unique pour s'authentifier, mais la taille de la charge utile d'authentification est relativement grande (généralement 6-16K) ( 401 , {taille du jeton (codé)} 200 )
• peut être utilisé avec (s'il vous plaît, toujours contraint) délégation pour activer l'authentification Windows de l'utilisateur qui se connecte au service suivant
  • par exemple, pour permettre à UserA d'accéder à IIS et d'utiliser ce même compte d'utilisateur lorsque IIS accède à SQL Server, il s'agit de "délégation d'authentification".
  • ( Contraint dans ce contexte signifie "mais pas autre chose", par exemple Exchange ou une autre boîte SQL)
• est actuellement le package de sécurité principal pour l'authentification de négociation
  • ce qui signifie que les membres du domaine Windows le préfèrent quand ils peuvent l'obtenir
• nécessite l'enregistrement des SPN , ce qui peut être délicat. Des règles qui aident .
• nécessite l'utilisation d'un nom comme cible, pas une adresse IP
• raisons pour lesquelles Curb pourrait échouer:
  • en utilisant une adresse IP au lieu d'un nom
  • aucun SPN enregistré
  • sPN en double enregistrés
  • SPN enregistré contre un mauvais compte (KRB_ERR_AP_MODIFIED)
  • aucun client DNS/DC
  • paramètre de proxy client/zone Intranet local non utilisée pour le site cible

Pendant que nous y sommes:

De base

• peut multi-hop. Mais cela se fait en en exposant votre nom d'utilisateur et votre mot de passe directement à l'application Web cible
  • qui peut alors faire tout ce qu'il veut avec eux. N'importe quoi.
  • "Oh, un administrateur de domaine a-t-il simplement utilisé mon application? Et ai-je simplement lu leur e-mail? Puis réinitialisé leur mot de passe? Awww. Dommage"
• nécessite la sécurité de la couche de transport (c'est-à-dire TLS/SSL) pour toute forme de sécurité.
  • puis, voir le numéro précédent
• fonctionne avec n'importe quel navigateur
  • (mais voir le premier numéro)
• nécessite un aller-retour unique pour s'authentifier ( 401 , 200 )
• peut être utilisé dans des scénarios à sauts multiples car Windows peut effectuer une connexion interactive avec des informations d'identification de base
  • Peut avoir besoin de LogonType pour être configuré à cet effet (pensez que la valeur par défaut a été modifiée en texte clair réseau entre 2000 et 2003, mais peut-être un mauvais souvenir)
  • mais encore, voir le premier numéro.
  • Vous avez l'impression que le premier numéro est vraiment, vraiment important? C'est.

Pour résumer:

La configuration peut être difficile à configurer, mais il existe de nombreux guides ( mon seul ) qui tentent de simplifier le processus, et les outils se sont améliorés énormément de 2003 à 2008 (SetSPN peut rechercher des doublons, ce qui est le problème de rupture le plus courant; tilisez SETSPN -S chaque fois que vous voyez des conseils pour utiliser -A, et la vie sera plus heureuse).

La délégation restreinte vaut le coût de l'admission.

Answer 2

• Kerberos a la réputation d'être un mécanisme d'authentification plus rapide et plus sécurisé que NTLM.
• Historiquement, il a également été plus facile de se connecter via des serveurs proxy que NTLM, en raison de la nature basée sur la connexion de NTLM.
• Cela dit, comme vous le constatez, Kerberos est plus difficile à installer et à exécuter, et nécessite une connexion à l'AD qui n'est pas toujours pratique.

Une autre approche serait de définir l'authentification sur negotiate et d'utiliser les deux plutôt que l'un au lieu de l'autre.

Answer 3

Depuis le Microsoft Application Verifier , qui détecte les erreurs courantes des développeurs. L'une de ces erreurs est l'utilisation de NTLM :

NTLM est un protocole d'authentification obsolète avec des failles qui compromettent potentiellement la sécurité des applications et du système d'exploitation. L'inconvénient le plus important est le manque d'authentification du serveur, ce qui pourrait permettre à un attaquant d'inciter les utilisateurs à se connecter à un serveur usurpé. En corollaire de l'authentification de serveur manquante, les applications utilisant NTLM peuvent également être vulnérables à un type d'attaque appelé attaque de "réflexion". Ce dernier permet à un attaquant de détourner la conversation d'authentification d'un utilisateur vers un serveur légitime et de l'utiliser pour authentifier l'attaquant auprès de l'ordinateur de l'utilisateur. Les vulnérabilités de NTLM et les moyens de les exploiter sont la cible de l'augmentation des activités de recherche dans la communauté de la sécurité.

Bien que Kerberos soit disponible depuis de nombreuses années, de nombreuses applications sont toujours écrites pour utiliser NTLM uniquement. Cela réduit inutilement la sécurité des applications. Kerberos ne peut cependant pas remplacer NTLM dans tous les scénarios - principalement ceux où un client doit s'authentifier auprès de systèmes qui ne sont pas joints à un domaine (un réseau domestique étant peut-être le plus courant). Le package de sécurité Negotiate permet un compromis rétrocompatible qui utilise Kerberos dans la mesure du possible et ne revient à NTLM qu'en l'absence d'autre option. Changer de code pour utiliser Negotiate au lieu de NTLM augmentera considérablement la sécurité de nos clients tout en introduisant peu ou pas de compatibilités d'application. Négocier en soi n'est pas une solution miracle - il existe des cas où un attaquant peut forcer la rétrogradation vers NTLM mais ceux-ci sont beaucoup plus difficiles à exploiter. Cependant, une amélioration immédiate est que les applications écrites pour utiliser Negotiate correctement sont automatiquement immunisées contre les attaques par réflexion NTLM.

En guise de dernière mise en garde contre l'utilisation de NTLM: dans les futures versions de Windows, il sera possible de désactiver l'utilisation de NTLM sur le système d'exploitation. Si les applications ont une forte dépendance à NTLM, elles échoueront simplement à s'authentifier lorsque NTLM est désactivé.

Answer 4

Vous devez ajouter un point très important:

Kerberos est un protocole standard et ouvert sous Unix depuis 20 ans, tandis que NTLM est une solution purement propriétaire de Microsoft et uniquement connue de Microsoft.

Answer 5

Kerberos est requis si vous devez emprunter l'identité de l'utilisateur pour accéder à des ressources qui ne sont pas sur le serveur iis.