Il existe plusieurs méthodes pour identifier le protocole d'authentification utilisé par IIS.
Dans notre précédent article, nous avons vu qu'il existe quatre types d'authentification pour IIS (Basic, Digest, Windows Intégrée et .NET Passport) auxquels s'ajoute l'authentification Anonyme qui est, quant à elle, un cas particulier dont nous parlerons dans un article séparé.

L'interface de gestion IIS permettant de sélectionner plusieurs types d'authentification, il nous faut distinguer plusieurs cas de figure amenant à l'identification du protocole d'authentification effectivement utilisé :

  • Une seule authentification parmi les trois suivantes est sélectionnée :
    • Basic
    • Digest
    • .NET Passport

Dans ce cas, vous pouvez vous fier à l'interface de gestion IIS. L'authentification sélectionnée est celle qui est utilisée. Il reste quand même recommandé de vérifier ceci avec la méthode décrite dans le cas 3.

  • Plusieurs authentifications sont sélectionnées :

Dans ce cas, il vaut mieux les tester une par une afin de cibler laquelle pose problème. Cependant vous pouvez utiliser la méthode décrite dans le cas 3 afin de savoir quel est le protocole réellement utilisé.

  • L'authentification Windows Intégrée ou toute autre authentification est sélectionnée :

Dans le cas de l'authentification Windows Intégrée saviez-vous que l'on peut utiliser deux protocoles bien distincts : NTLM ou Negotiate?
Et que Negotiate se compose du protocole NTLM mais également du protocole Kerberos ?
Il est donc difficile de déterminer quel protocole est utilisé sans rentrer dans le détail.
Il est d'ailleurs fortement recommandé, quelle que soit l'authentification sélectionnée, de vérifier que le protocole utilisé est bien celui attendu.
Cela peut éviter de nombreuses heures d'arrachage de cheveux sans jamais trouver la solution.


Mais comment faire ?
Tout simplement en utilisant deux outils, Strace & HTTPReplay.
Strace va permettre de capturer un log et HTTPReplay va permettre de l'interpréter.
Si vous désirez plus de détails sur ces outils, je vous invite à consulter l'article "Mise à jour STRACE / HTTPREPLAY".

Pour collecter un log, vous devez télécharger Strace disponible ici, puis effectuez les étapes suivantes :

  • Installez-le sur un poste client. J'insiste sur ce point, car tester l'authentification en local sur le serveur IIS n'est jamais révélateur du comportement depuis un poste client étant donné que certains protocoles ne sont jamais utilisés en local.
  • Une fois installé, lancez le fichier "STRACE.cmd" situé par défaut dans "C:\Program Files (x86)\STRACE".
  • Une fenêtre Internet Explorer va alors se lancer
    • Reproduisez votre problème d'authentification
  • Une fois la reproduction terminée, fermez la fenêtre Internet Explorer
  • Un log Strace est alors généré sur le bureau avec la nomenclature suivante :
    • STRACE_IEXPLORE_PID_5084_27102009_130513.LOG


Pour pouvoir interpréter le log, téléchargez HTTPReplay qui est disponible ici et effectuez les étapes suivantes :

  • Installez-le sur le poste client ou sur le poste où vous avez enregistré le log Strace
  • Cliquez droit sur le log Strace, et sélectionnez "Ouvrir avec"
    • Sélectionnez le fichier "HTTPREPLAY.cmd", situé par défaut dans "C:\Program Files (x86)\HTTPREPLAY"
  • Le rapport se charge alors dans une fenêtre Internet Explorer
  • Il vous suffit maintenant de cliquer, dans la colonne "Status", sur le code retour 401 renvoyé par le serveur IIS afin d'en afficher le détail et connaître la liste des types d'authentification proposée par le serveur
  • En cliquant sur le "GET" dans la trame suivante, vous verrez quelle authentification est utilisée pour authentifier le client

Par exemple si j'ai coché Basic et Windows Intégrée :

        

On peut voir qu'en authentification disponible j'ai Negotiate, NTLM & Basic mais qu'au final j'utilise le protocole Negotiate :

Voici un exemple de rapport pour chaque type d'authentification :

  • Basic :

    

  • Digest :

    



  • .NET Passport :

Si cette authentification est sélectionnée, seule cette authentification pourra fonctionner :

        

Pour l'authentification .NET Passport, la trace est un peu différente étant donné que l'authentification va être gérée par le serveur Microsoft Live.
Quoi qu'il en soit, cette authentification est facilement identifiable car elle ouvre une fenêtre de prompt avec le logo .NET Passport comme celle-ci :

De plus on peut voir une connexion vers le serveur Live :

  • Authentification Windows Intégrée :

    

Comme indiqué précédemment, en cochant l'authentification Windows Intégrée vous pouvez utiliser le protocole NTLM ou le protocole Negotiate. Avec le protocole Negotiate vous pouvez utiliser Kerberos ou NTLM (qui se nomme NTLMSSP).

  • NTLM :

  • Negotiate :

Vous pouvez voir dans la liste des protocoles que l'on a Negotiate & NTLM.
Ici, nous utilisons le protocole Negotiate.
Maintenant il faut identifier si dans Negotiate on utilise NTLM ou Kerberos :

  • NTLM :

Si on utilise NTLM, dans le "get" du client, "Authorization : Negotiate" commencera toujours par "TlRMTVNTUA" ce qui en base 64 veut dire NTLMSSP (le NTLM de Negotiate)

  • Kerberos :

Pour Kerberos, dans le "get" du client, "Authorization : Negotiate" commencera toujours par "YII"


Résumons-nous (Remarque : chaque image est un lien) :


                                  
                
                          

Maintenant, que vous connaissez l'authentification que vous utilisez, cliquez sur celle qui vous pose problème J !

Sylvain Lecerf et L'équipe de support IIS Microsoft France