Pages de diagnostic pour la résolution des problèmes liés à l’authentification intégrée Windows

La résolution des problèmes d’échec d’authentification intégrée Windows peut être difficile, en particulier lorsque vous gérez la délégation d’informations d’identification Kerberos. Bien qu’il existe une liste de contrôle détaillée sur la façon de vous assurer que vous disposez de la configuration correcte pour internet Information Services (IIS) pour utiliser l’authentification intégrée Windows et éventuellement utiliser la délégation d’informations d’identification, cet article cible spécifiquement les scénarios suivants :

• Vous pouvez vous connecter à votre site web cible à partir de l’ordinateur client, mais vous ne savez pas si vous utilisez NTLM ou Kerberos comme mécanisme d’authentification.
• Vous pouvez vous connecter à votre site web cible, mais vous êtes invité à vous connecter uniquement après avoir entré une combinaison de nom d’utilisateur et de mot de passe.
• Vous pouvez accéder à votre site web cible sur le serveur frontal, mais il échoue lorsque vous lancez une action qui nécessite que le serveur frontal appelle un point de terminaison HTTP back-end à l’aide des informations d’identification de l’utilisateur authentifié.

Pour les besoins de cet article, tenez compte de la disposition suivante :

• Le client 1 est la station de travail jointe au domaine ou l’ordinateur portable à partir duquel l’utilisateur hypothétique lance toutes les tentatives de connexion.

• Web-serv1 est le serveur IIS frontal hébergeant un site web ASP.NET (sur .NET Framework) qui utilise l’authentification intégrée Windows et s’exécute à l’aide de l’identité d’un compte de service : domaine\serviceaccount.

• Web-serv2 est le serveur web principal qui héberge également un site ASP.NET (sur .NET Framework) qui expose les points de terminaison d’API pour l’application frontale. Il est également configuré pour autoriser les requêtes qui utilisent l’authentification intégrée Windows et s’exécuter dans un pool d’applications qui utilise domain\serviceapiaccount comme identité de pool d’applications.

Pour faciliter la collecte de données pour ces scénarios et ne pas s’appuyer sur des outils de collecte de données externes tels que Fiddler ou WireShark (étant donné que les connexions entre les trois ordinateurs peuvent utiliser HTTPS et donc tous les échanges entre eux seront chiffrés), utilisez les deux pages de diagnostic autonomes dans ASP.NET pages autonomes pour résoudre les problèmes d’authentification intégrée Windows sur IIS.

Pages de résolution des problèmes

Les deux pages sont codées dans ASP.NET Web Forms. Ils sont destinés à regrouper le code et le balisage de la page dans un fichier qui peut être copié à la racine de l’application web que vous essayez de résoudre, sans avoir besoin de compilation ou de déploiement. Les pages sont les suivantes :

• WhoAmI.aspx - Cette page permet de vider les informations relatives à l’authentification telles que :

  • Méthode d’authentification utilisée pour accéder au site cible. Si la méthode est basée sur le fournisseur Negotiate pour l’authentification intégrée Windows, la page indique si Kerberos ou NTLM est utilisé pour authentifier l’utilisateur.

  • Identité du compte qui exécute le pool d’applications hébergeant le site.

  • Niveau d’emprunt d’identité pour l’utilisateur authentifié. Si Kerberos est utilisé pour l’authentification et la délégation d’informations d’identification non contraintes est autorisée, le niveau d’emprunt d’identité est marqué comme délégué. Si ce n’est pas le cas, il sera marqué comme emprunt d’identité dans le cas d’une délégation contrainte ou d’un emprunt d’identité simple.

  • Identité de l’utilisateur authentifié et des groupes auxquels appartient l’utilisateur.

  • Identité du compte exécutant le code de la page (il peut s’agir d’un utilisateur authentifié ou d’un utilisateur du pool d’applications, en fonction des paramètres d’emprunt d’identité ).

  • Toutes les valeurs des en-têtes de requête pour les requêtes qui entrent dans la page WhoAmI.aspx telle qu’elles sont récupérées à partir des variables du serveur IIS.

    

• ScrapperTest.aspx : cette page est effectuée pour fonctionner avec la page WhoAmI.aspx, ce qui permet aux requêtes du serveur frontal d’être dirigées vers toutes les URL du serveur principal. La page présente une interface utilisateur qui permet à un utilisateur de :

  • Entrez l’URL souhaitée de la ressource de serveur principal que la page doit tenter de charger.

  • Déterminez s’ils sont authentifiés lors du chargement de la page ScrapperTest.aspx et s’ils sont authentifiés, les utilisateurs auxquels ils sont authentifiés.

  • Dans le scénario où l’utilisateur est effectivement authentifié, une case à cocher permet de réutiliser les informations d’identification de l’utilisateur lors de la tentative de chargement de la ressource principale indiquée dans la zone de texte URL.

    

Guide pratique pour déployer

Étant donné que les deux pages sont autonomes, la seule chose nécessaire est de :

1. Téléchargez les pages à partir du dépôt GitHub.
2. Copiez la page WhoAmI.aspx ou les deux pages à la racine de vos applications web cibles qui s’exécutent à l’intérieur d’IIS.
3. Effectuez une demande à l’URL de votre site en ajoutant /WhoAmI.aspx ou /ScrapperTest.aspx, selon la page à laquelle vous souhaitez accéder.

Utilisation

Le premier scénario d’utilisation tente de déterminer quelle méthode d’authentification est utilisée pour accéder à un site web ou une application web donné hébergé sur IIS. Pour celui-ci, vous pouvez effectuer des demandes à la page WhoAmI.aspx que vous avez précédemment déployée sur le site.

• Dans la première demande, la page affiche les informations d’authentification. Si le fournisseur Negotiate pour l’authentification intégrée Windows est utilisé, il répertorie également le protocole d’authentification utilisé : Kerberos ou NTLM.

• Les requêtes suivantes dans un scénario où Negotiate est utilisé comme fournisseur pour l’authentification intégrée Windows affichent uniquement l’étiquette basée sur la session en regard du type d’authentification. Pour plus d’informations, consultez l’authentification Kerberos basée sur la requête ou sur session (ou le paramètre AuthPersistNonNTLM).

• Toutes les autres informations d’authentification, telles que l’utilisateur du pool d’applications, l’utilisateur authentifié, les détails de l’utilisateur d’exécution et les en-têtes de la requête entrante, sont affichées sur chaque requête.

La page WhoAmI.aspx affiche également un petit formulaire en bas. Ce formulaire vous permet d’émettre POST des demandes au serveur pour tester le comportement du navigateur lors de l’émission de ces types de requêtes. Si la page est inactive pendant plus de 60 secondes, la connexion TCP (Transmission Control Protocol) utilisée pour télécharger la page dans le navigateur et authentifiée par le serveur est interrompue en raison de l’inactivité. Par conséquent, lorsque vous effectuez une POST demande, une nouvelle connexion TCP est ouverte et vous devez vous authentifier à nouveau. Il y a une subtilité avec POST les demandes :

1. Le navigateur envoie d’abord les en-têtes de requête HTTP POST .
2. Il émet ensuite le corps de la POST requête, qui contient les informations capturées à partir des différents champs d’entrée du formulaire HTTP affiché sur la page.

Si le navigateur n’attend pas après l’envoi des en-têtes de la POST requête, mais envoie plutôt le corps directement sur une connexion non authentifiée, les problèmes suivants peuvent se produire :

• Le serveur reçoit les POST en-têtes de requête et, étant donné que la connexion n’est pas authentifiée (en supposant que l’authentification intégrée Windows ou une autre authentification basée sur un défi est utilisée), elle émet une réponse 401 avec l’en-tête HTTP de réponse d’authentification approprié (WWW-Authenticate).
• Pendant ce temps, le navigateur a déjà envoyé le corps de la POST requête avant de recevoir la réponse 401 du serveur.
• Le serveur reçoit ensuite un corps de requête non authentifié POST sur une connexion qu’il a précédemment indiqué au client que l’authentification est requise.
• Cela entraîne la séparation de la connexion TCP sous-jacente par le serveur, et le navigateur peut afficher un message « Page web n’est pas disponible ».

La page ScrapperTest.aspx est utilisée pour tester la délégation de scénarios d’informations d’identification du serveur frontal vers le point de terminaison du serveur principal. Une fois la page demandée à partir du navigateur client, elle offre une interface utilisateur qui autorise :

• Entrée de l’URL du point de terminaison back-end à laquelle le serveur frontal doit se connecter.
• Vérifiez que l’utilisateur est authentifié sur le serveur frontal et sur le nom d’utilisateur utilisé pour se connecter au serveur frontal.
• Décider (dans le cas où l’authentification est utilisée pour accéder à la page ScrapperTest.aspx ) si les informations d’identification de l’utilisateur authentifié doivent être transmises avec la demande au serveur principal (si l’emprunt d’identité et la délégation sont possibles).

Une fois que le bouton Supprimer la page est sélectionné, le code de la page ScrapperTest.aspx émet une GET demande pour l’URL cible indiquée. Si la case Utiliser les informations d’identification est cochée et que l’authentification est nécessaire pour accéder au point de terminaison principal spécifié, les informations d’identification de l’utilisateur authentifié sont également utilisées pour effectuer la demande. Si une demande réussit, le résultat s’affiche dans le contrôle de zone de texte de la page en tant que sortie HTTP brute de la réponse reçue.

Un scénario d’utilisation que nous prévoyons consiste à placer la page ScrapperTest.aspx et la page WhoAmI.aspx à l’intérieur de l’application ASP.NET qui serait contacté sur le serveur principal. Par conséquent, la réponse HTTP récupérée par la page ScrapperTest.aspx sera la sortie HTML de la page WhoAmI.aspx lorsqu’elle est exécutée sur le serveur principal. Cette sortie peut ensuite être évaluée pour comprendre comment la demande a été authentifiée sur le serveur principal et quels comptes ont été utilisés.

Plus d’informations

Pour mieux comprendre la configuration de l’authentification intégrée Windows à l’aide de Kerberos, consultez :

• Résoudre les échecs Kerberos dans Internet Explorer
• Authentification à double tronçon sans contrainte Kerberos avec Microsoft Edge (Chromium)
• Authentification Kerberos basée sur la requête ou sur session (ou paramètre AuthPersistNonNTLM)