Authentification à double tronçon sans contrainte Kerberos avec Microsoft Edge (Chromium)

S’applique à : Internet Information Services

Introduction

La configuration de l’authentification Windows basée sur le protocole d’authentification Kerberos peut être une tâche complexe, en particulier quand il s’agit de scénarios tels que la délégation d’identité d’un site frontal vers un service principal dans le contexte d’IIS et de ASP.NET. Suivez les étapes de cet article pour configurer la délégation des tickets d’authentification et utiliser des services avec un navigateur moderne tel que Microsoft Edge version 87 ou ultérieure.

Cet article suppose que vous configurez une architecture similaire à celle représentée dans le diagramme ci-dessous :

• L’ordinateur Workstation-Client1 fait partie du même répertoire actif que le serveur web principal, appelé Primary-IIS-SRV , et le serveur web principal, appelé Backend-Web-SRV.
• Les utilisateurs de l’ordinateur Workstation-Client1 se connectent à l’ordinateur à l’aide du compte Windows Active Directory.
• Ensuite, ils lancent un navigateur (Microsoft Edge), accèdent à un site web situé sur Web-Server, qui est le nom d’alias utilisé pour Primary-IIS-SRV, et s’authentifient via des Authentification Windows intégrées à l’aide de Kerberos.
• Le site web situé sur Web-Server effectuera des appels HTTP à l’aide des informations d’identification de l’utilisateur authentifié pour API-Server (qui est l’alias de Backend-Web-SRV) pour récupérer les données d’application pour le compte des utilisateurs, à l’aide de la délégation d’informations d’identification Kerberos.

Les étapes ci-dessous vous aideront à résoudre ce scénario : l’installation fonctionne avec Internet Explorer, mais lorsque les utilisateurs adoptent Microsoft Edge, ils ne peuvent plus utiliser la fonctionnalité de délégation d’informations d’identification. Pour utiliser la délégation d’informations d’identification Kerberos, consultez d’abord Résoudre les échecs Kerberos dans Internet Explorer.

Délégation contrainte ou non contrainte

Dans le scénario ci-dessus, les deux configurations permettent aux utilisateurs de déléguer les informations d’identification de leur session utilisateur sur l’ordinateur Workstation-Client1 au serveur d’API principal lors de la connexion via le serveur web frontal.

Dans une configuration de délégation Kerberos sans contrainte, l’identité du pool d’applications s’exécute sur Web-Server et est configurée dans Active Directory pour être approuvée pour la délégation à n’importe quel service. Le compte du pool d’applications s’exécutant sur Web-Server peut déléguer les informations d’identification des utilisateurs authentifiés du site web hébergé sur ce serveur à n’importe quel autre service dans Active Directory. Par exemple, un serveur SMTP, un serveur de fichiers, un serveur de base de données, un autre serveur web, etc. Cette délégation est appelée délégation sans contrainte, car le compte du pool d’applications a l’autorisation (il n’est pas contraint) de déléguer des informations d’identification à tout service qu’il contacte.

Dans une configuration de délégation contrainte, le compte Active Directory utilisé comme identité de pool d’applications peut déléguer les informations d’identification des utilisateurs authentifiés uniquement à une liste de services qui ont été autorisés à déléguer. Si l’application web résidant sur le serveur appelé Web-Server doit également contacter une base de données et s’authentifier au nom de l’utilisateur, ce nom de principal de service (SPN) doit être ajouté à la liste des services autorisés.

La délégation contrainte est plus sécurisée que la délégation sans contrainte basée sur le principe du privilège minimum. Une application se voit accorder les droits dont elle a besoin pour fonctionner et rien de plus, tandis que la délégation sans contrainte permet à une application de contacter des ressources qu’elle ne doit pas contacter au nom de l’utilisateur.

Comment savoir si le ticket Kerberos obtenu sur le client pour l’envoyer au Web-Server utilise une délégation contrainte ou sans contrainte ?

Utilisez l’outil de commande klist présent dans Windows pour répertorier le cache des tickets Kerberos à partir de l’ordinateur client (Workstation-Client1 dans le diagramme ci-dessus). Recherchez un ticket nommé HTTP/<Nom du serveur> web. Remarque : <Le nom du serveur> web est le SPN du service que vous souhaitez contacter et auprès de lequel vous souhaitez vous authentifier via Kerberos. Le ticket contient également quelques indicateurs. Deux d’entre eux sont intéressants : forwardable et ok_as_delegate.

• Le premier indicateur, forwardable, indique que le KDC (centre de distribution de clés) peut émettre un nouveau ticket avec un nouveau masque réseau si nécessaire. Cela permet à un utilisateur de se connecter à un système distant et au système distant d’obtenir un nouveau ticket au nom de l’utilisateur pour se connecter à un autre système principal comme si l’utilisateur s’était connecté au système distant localement.

• Le deuxième indicateur ok_as_delegate indique que le compte de service du service auprès lequel l’utilisateur tente de s’authentifier (dans le cas du diagramme ci-dessus, le compte du pool d’applications IIS hébergeant l’application web) est approuvé pour la délégation sans contrainte.

Si ces services utilisent une délégation sans contrainte, les tickets sur l’ordinateur client contiennent les ok_as_delegate indicateurs et forwardable . Dans la plupart des cas, lorsque la délégation contrainte est configurée, les tickets ne contiennent pas l’indicateur ok_as_delegate , mais l’indicateur forwardable .

Pourquoi la délégation sans contrainte fonctionne-t-elle dans Internet Explorer et pas dans Microsoft Edge ?

Lorsqu’une tentative de s’authentifier auprès d’un site web à l’aide de l’authentification Kerberos est effectuée, le navigateur appelle une API Windows pour configurer le contexte d’authentification. L’API en question est InitializeSecurityContext. Cette API peut recevoir une série d’indicateurs pour indiquer si le navigateur autorise le delegatable ticket reçu par l’utilisateur. Le ticket est marqué comme étant donné que delegatable le service auquel l’utilisateur tente de s’authentifier a le droit de déléguer les informations d’identification sans contrainte. Toutefois, cela ne signifie pas que l’application qui tente de s’authentifier (dans ce cas le navigateur) doit utiliser cette capacité.

Par défaut, Internet Explorer transmet l’indicateur à InitializeSecurityContext, ce qui indique que si le ticket peut être délégué, il doit l’être. Microsoft Edge de la version 87 et ultérieure ne transmet pas l’indicateur à InitializeSecurityContext simplement parce que le ticket est marqué avec l’indicateur ok_as_delegate . Nous vous déconseillons d’utiliser la délégation sans contrainte dans les applications, car elle donne aux applications plus de privilèges que nécessaire. Les applications peuvent déléguer l’identité de l’utilisateur à n’importe quel autre service sur le domaine et s’authentifier en tant qu’utilisateur, ce qui n’est pas nécessaire pour la plupart des applications utilisant la délégation d’informations d’identification. Les applications doivent contacter uniquement les services de la liste qui a été spécifiée lors de la configuration de la délégation contrainte.

Par défaut, Microsoft Edge fonctionne avec la délégation contrainte, où le site web IIS s’exécutant sur Web-Server a uniquement le droit de contacter le site d’API principal hébergé sur API-Server, comme indiqué dans la configuration du compte d’identité du pool d’applications à partir d’Active Directory listée ci-dessous :

Autoriser Edge-Chromium à utiliser la délégation sans contrainte dans Active Directory

À des fins de compatibilité, si vous devez gérer une application à l’aide d’une délégation sans contrainte via Kerberos, activez Microsoft Edge pour autoriser la délégation de tickets. Les étapes ci-dessous sont détaillées dans les sections suivantes de cet article :

1. Installez les modèles d’administration pour stratégie de groupe Magasin central dans Active Directory (s’ils ne sont pas déjà présents).
2. Installez les modèles d’administration Microsoft Edge.
3. Créez un objet stratégie de groupe.
4. Modifiez la configuration du stratégie de groupe pour autoriser la délégation sans contrainte lors de l’authentification auprès des serveurs.
5. (Facultatif) Vérifiez si Microsoft Edge utilise les indicateurs de délégation corrects.

Étape 1 : Installer les modèles d’administration pour Active Directory

1. Téléchargez les modèles à partir de Modèles d’administration (.admx) (pour Windows Server 2019).

2. Téléchargez le programme d’installation et extrayez le contenu dans un dossier de votre choix. Vous pouvez simplement l’extraire à l’emplacement spécifié par défaut du package, à savoir C :\Program Files (x86)\Microsoft stratégie de groupe\Mise à jour d'octobre 2018 de Windows 10 (1809) v2\PolicyDefinitions.

3. Une fois le package décompressé, recherchez le dossier Sysvol sur votre contrôleur de domaine. Le chemin d’accès au dossier est C :\Windows\SYSVOL\sysvol\. Dans le dossier Sysvol se trouve un dossier portant le même nom que votre nom Active Directory (dans l’exemple ici, Oddessy.local). À partir de là, accédez au dossier Stratégies . S’il n’existe pas, créez un dossier appelé Définitions de stratégie, comme indiqué ci-dessous :

   

4. Copiez le contenu du dossier PolicyDefinitions (qui a été extrait du programme d’installation vers le dossier PolicyDefinitions ) que vous avez créé à l’intérieur de votre domaine dans le dossier sysvol sur le contrôleur de domaine.

   Remarque

   Les fichiers qui ont été extraits par le programme d’installation contiennent également du contenu localisé. Pour économiser de l’espace, transférez les fichiers localisés uniquement pour les langues souhaitées. Par exemple, le dossier nommé fr-FR contient tout le contenu localisé dans Français.

5. Une fois le transfert terminé, vérifiez que les modèles sont disponibles dans Active Directory. Pour ce faire, ouvrez le composant logiciel enfichable gestion stratégie de groupe de microsoft Management Console (appuyez sur Windows+R, puis tapez gpmc.msc pour lancer). Dans le stratégie de groupe Management, recherchez un objet de stratégie de groupe et modifiez-le.

   

   Comme indiqué dans la capture d’écran ci-dessus, sous le nœud Configuration de l’ordinateur , se trouve un nœud Stratégies et un nœud Modèles d’administration .

Étape 2 : Installer les modèles d’administration Microsoft Edge

Bien que vous disposiez des modèles d’administration de stratégie sur le contrôleur de domaine pour commencer, vous devrez toujours installer les fichiers de stratégie Microsoft Edge pour avoir accès à la stratégie destinée à activer la délégation sans contrainte à double tronçon via ce navigateur. Pour installer les fichiers de stratégie Microsoft Edge, procédez comme suit :

1. Accédez au site de téléchargement Microsoft Edge pour les entreprises.

2. Sélectionnez la version que vous souhaitez télécharger dans la liste déroulante canal/version . La dernière version stable est recommandée.

3. Sélectionnez la build souhaitée dans la liste déroulante build et enfin le système d’exploitation cible dans la liste déroulante de la plateforme . Une fois la sélection effectuée, deux autres boutons (un bouton et un lien) s’affichent.

   

4. Cliquez sur OBTENIR LES FICHIERS DE STRATÉGIE et acceptez le contrat de licence pour télécharger le fichier appelé MicrosoftEdgePolicyTemplates.cab. Ce fichier contient les fichiers de définition de stratégie pour Microsoft Edge.

5. Double-cliquez sur le fichier pour explorer le contenu (une archive zip portant le même nom).

6. Extrayez le contenu de l’archive zip dans un dossier sur votre disque local. Le contenu extrait contient un dossier appelé Windows dans lequel vous trouverez un sous-dossier appelé Admx. Celui-ci contiendra les modèles d’administration ainsi que leurs versions localisées (vous devez en avoir besoin dans une langue autre que l’anglais).

   

7. Transférez les fichiers .admx dans le même dossier sous le répertoire Sysvol vers lequel les modèles d’administration du précédent ont été transférés (dans l’exemple ci-dessus : C :\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

8. Ouvrez le stratégie de groupe Rédacteur Active Directory et sélectionnez un objet de stratégie de groupe existant à modifier pour case activée la présence des modèles Microsoft Edge nouvellement transférés. Ceux-ci se trouvent dans un dossier appelé Microsoft Edge situé sous le dossier Modèles d’administration dans l’arborescence :

   

Étape 3 : Créer un objet stratégie de groupe

Voici comment créer un objet stratégie de groupe à l’aide du composant logiciel enfichable MMC Active Directory stratégie de groupe Manager :

1. Appuyez sur la touche Windows+R pour ouvrir le menu Exécuter sur votre contrôleur de domaine.
2. Tapez Gpmc.msc pour ouvrir la console de gestion Microsoft et charger le composant logiciel enfichable Gestionnaire de stratégie de groupe Active Directory.
3. Recherchez le nœud Objets stratégie de groupe dans l’arborescence de la console et cliquez avec le bouton droit sur le nœud pour ouvrir le menu contextuel.
4. Sélectionnez l’élément de menu Nouveau , renseignez le nom de la stratégie de groupe que vous souhaitez créer, puis cliquez sur OK.

Étape 4 : Modifier la configuration du stratégie de groupe pour autoriser la délégation sans contrainte lors de l’authentification auprès des serveurs

La dernière étape consiste à activer la stratégie qui permet au navigateur Microsoft Edge de transmettre l’indicateur à l’appel ok_as_delegate d’API lors de l’exécution de l’authentification InitializeSecurityContext à l’aide de Kerberos sur un site web windows intégré. Si vous ne savez pas si votre navigateur Microsoft Edge utilise Kerberos pour l’authentification (et non NTLM), reportez-vous à Résoudre les défaillances Kerberos dans Internet Explorer.

Dans le stratégie de groupe Rédacteur Active Directory, sélectionnez l’objet de stratégie de groupe qui sera appliqué aux ordinateurs à l’intérieur de votre annuaire Active Directory à partir desquels vous souhaitez permettre aux utilisateurs finaux de s’authentifier via l’authentification Kerberos et de déléguer leurs informations d’identification aux services principaux par le biais d’une délégation sans contrainte. La stratégie qui activera la délégation sans contrainte à partir de Microsoft Edge se trouve sous le dossier d’authentification HTTP des modèles Microsoft Edge , comme indiqué ci-dessous :

Utilisez ce paramètre pour configurer une liste de serveurs pour lesquels la délégation de tickets Kerberos est autorisée.

Remarque

Une liste de serveurs doit être fournie. Dans l’exemple utilisé au début de cet article, vous devez ajouter le nom du serveur Web-Server à la liste pour permettre à l’application web frontale Web-Server de déléguer les informations d’identification au serveur d’API principal.

Une fois que l’objet de stratégie de groupe nouvellement modifié est appliqué aux ordinateurs clients à l’intérieur du domaine, accédez à la page d’authentification de test dans les pages de diagnostic pour la résolution des problèmes d’authentification intégrée Windows et téléchargez la page whoami.aspx à partir du référentiel d’exemples ASP.net sur GitHub. Il génère un paramètre ImpersonationLevel délégué au lieu de l’emprunt d’identité signalant que la délégation d’informations d’identification est désormais autorisée.

Pour tester si la stratégie a été appliquée correctement sur la station de travail cliente, ouvrez un nouvel onglet Microsoft Edge et tapez edge://policy.

La AuthNegotiateDelegateAllowlist stratégie doit être définie pour indiquer les valeurs des noms de serveurs pour lesquels Microsoft Edge est autorisé à effectuer la délégation de tickets Kerberos. Si la stratégie n’apparaît pas dans la liste, elle n’a pas été déployée ou a été déployée sur les ordinateurs incorrects.

Étape 5 (facultative) : vérifier si Microsoft Edge utilise les indicateurs de délégation appropriés

Voici l’étape de résolution des problèmes/case activée facultative.

Une fois la stratégie configurée et déployée, les étapes suivantes doivent être effectuées pour vérifier si Microsoft Edge transmet les indicateurs de délégation appropriés à IntializeSecurityContext. Les étapes utilisent des outils qui sont déjà intégrés à Microsoft Edge ou qui sont disponibles en tant que services en ligne.

1. Utilisez la fonctionnalité de journalisation disponible dans Microsoft Edge pour journaliser ce que fait le navigateur lors de la demande d’un site web. Pour activer la journalisation :

   1. Ouvrez une nouvelle fenêtre Microsoft Edge et tapez edge://net-export/.

   2. Utilisez l’option Inclure les cookies et les informations d’identification lors du suivi. Sans cette option, les données de niveau de trace d’authentification seront omises.

      

   3. Cliquez sur le bouton Démarrer la journalisation sur le disque et indiquez le nom de fichier sous lequel vous souhaitez enregistrer la trace.

   4. Ouvrez un autre onglet Microsoft Edge et accédez au site web sur lequel vous souhaitez effectuer des Authentification Windows intégrées à l’aide de Microsoft Edge.

   5. Une fois que vous avez essayé de vous authentifier, revenez à l’onglet précédent où le suivi a été activé, puis cliquez sur le bouton Arrêter la journalisation . L’interface de suivi indique où le fichier contenant la trace a été écrit.

2. Utilisez le fichier JSON contenant la trace pour voir les paramètres que le navigateur a passés à la InitializeSecurityContext fonction lors de la tentative d’authentification. Pour analyser la trace, utilisez la netlog_viewer.

3. Dans la trace analysée se trouve un journal des événements qui ressemble à ce qui suit :

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   Ce journal indique ce qui suit :

   • AUTH_LIBRARY_INIT_SEC_CTX signifie que le navigateur appelle la InitializeSecurityContext fonction .
   • "delegated":false signifie que le ticket ne doit pas être délégué même si le ticket est marqué comme delegatable.
   • "mutual":false signifie que le client (navigateur) n’exige pas que le serveur s’authentifie auprès du client et prouve son identité. Seul le client doit s’authentifier auprès du serveur pour prouver son identité.
   • HTTP/web-server.odessy.local est le SPN utilisé par le navigateur lors de l’appel d’authentification.

Plus d’informations

Pages de diagnostic pour la résolution des problèmes d’authentification intégrée Windows