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 lorsque vous traitez des 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 de 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 Station de travail-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 le serveur Web, qui est le nom d’alias utilisé pour Primary-IIS-SRV, et s’authentifient via des Authentification Windows intégrés à l’aide de Kerberos.
• Le site web situé sur le serveur web effectue des appels HTTP à l’aide des informations d’identification de l’utilisateur authentifié vers le serveur API (qui est l’alias pour 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 : la configuration 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, reportez-vous d’abord à résoudre les défaillances 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 la machine Station de travail-Client1 au serveur d’API principal lors de la connexion via le serveur web frontal.

Dans une configuration de délégation Kerberos non contrainte, l’identité du pool d’applications s’exécute sur le serveur Web 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 exécuté sur le serveur web peut déléguer les informations d’identification des utilisateurs authentifiés du site web hébergé sur ce serveur à tout autre service de l’annuaire Active Directory. Par exemple, un serveur SMTP, un serveur de fichiers, un serveur de base de données, un autre serveur web, etc. Il s’agit de la délégation non contrainte, car le compte de pool d’applications dispose de l’autorisation (il n’est pas contraint) de déléguer les informations d’identification à n’importe quel 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 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 pour le compte 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 non contrainte basée sur le principe du privilège minimum. Une application reçoit les droits dont elle a besoin pour fonctionner et rien de plus, alors que la délégation non contrainte permet à une application de contacter les ressources qu’elle ne doit pas contacter pour le compte de l’utilisateur.

Comment savoir si le ticket Kerberos obtenu sur le client à envoyer au serveur Web utilise une délégation contrainte ou non 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/<Name of Web-Server>. Remarque : <Le nom du serveur web> est le SPN du service que vous souhaitez contacter et authentifier via Kerberos. Le ticket contient également quelques indicateurs. Deux d’entre eux sont d’intérêt : forwardable et ok_as_delegate.

• Le premier indicateur, forwardableindique 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 pour le compte de l’utilisateur de 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 auquel l’utilisateur tente de s’authentifier (dans le cas du diagramme ci-dessus, le compte de pool d’applications du pool d’applications IIS hébergeant l’application web) est approuvé pour la délégation non contrainte.

Si ces services utilisent une délégation non contrainte, les tickets sur l’ordinateur client contiennent les indicateurs et forwardable les ok_as_delegate indicateurs. 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 contiennent l’indicateur forwardable .

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

Lorsqu’une tentative est effectuée pour s’authentifier auprès d’un site web à l’aide de l’authentification Kerberos, 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 delegatable étant dû au fait que le service que l’utilisateur tente de s’authentifier pour avoir le droit de déléguer les informations d’identification de manière non contrainte. Toutefois, cela ne signifie pas que l’application qui tente d’authentifier (dans ce cas le navigateur) doit utiliser cette capacité.

Par défaut, Internet Explorer transmet l’indicateur à InitializeSecurityContext, indiquant que si le ticket peut être délégué, il doit être. Microsoft Edge de la version 87 et ultérieure ne passe pas l’indicateur uniquement InitializeSecurityContext parce que le ticket est marqué avec l’indicateur ok_as_delegate . Nous vous déconseillons d’utiliser la délégation non 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 à tout autre service sur le domaine et s’authentifier en tant qu’utilisateur, ce qui n’est pas nécessaire pour la plupart des applications à l’aide de la délégation d’informations d’identification. Les applications doivent contacter uniquement les services de la liste spécifiée lors de la configuration de la délégation contrainte.

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

Permettre à Edge-Chromium d’utiliser la délégation non 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 le magasin central de stratégie de groupe dans Active Directory (s’il n’est pas déjà présent) .
2. Installez les modèles d’administration Microsoft Edge.
3. Créez un objet de stratégie de groupe.
4. Modifiez la configuration de la stratégie de groupe pour autoriser la délégation non contrainte lors de l’authentification auprès des serveurs.
5. (Facultatif) Vérifiez si Microsoft Edge utilise les indicateurs de délégation appropriés.

É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, qui est C :\Program Files (x86)\Microsoft Group Policy\Windows 10 octobre 2018 Update (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 est 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.

   Note

   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é en 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 des stratégies de groupe de la console de gestion Microsoft (appuyez sur Windows+R, puis tapez gpmc.msc pour lancer). Dans la gestion des stratégies de groupe, recherchez un objet de stratégie de groupe et modifiez-le.

   

   Comme illustré dans la capture d’écran ci-dessus, sous le nœud Configuration de l’ordinateur, il s’agit d’un nœud Stratégies et d’un nœud modèles d’administration.

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

Bien que vous ayez peut-être les modèles d’administration de stratégie sur le contrôleur de domaine à démarrer, 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 de 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 GET POLICY FILES 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 (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. Cela contiendra les modèles d’administration ainsi que leurs versions localisées (vous devez les 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 l’Éditeur de stratégie de groupe Active Directory et sélectionnez un objet de stratégie de groupe existant pour vérifier 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 de stratégie de groupe

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

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égies de groupe Active Directory.
3. Recherchez le nœud Objets de stratégie de groupe dans l’arborescence de la console, puis 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 de la stratégie de groupe pour autoriser la délégation non contrainte lors de l’authentification sur les serveurs

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

Dans l’Éditeur de stratégie de groupe 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 duquel vous envisagez d’autoriser les utilisateurs finaux à s’authentifier via l’authentification Kerberos et à disposer de leurs informations d’identification déléguées aux services principaux par le biais d’une délégation non contrainte. La stratégie qui active la délégation non 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.

Note

Une liste de serveurs doit être fournie. Dans l’exemple utilisé au début de cet article, vous devrez ajouter le nom du serveur Web-Server à la liste pour permettre à l’application web web front-end de déléguer les informations d’identification au serveur-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. Elle génère un paramètre ImpersonationLevel de Délégué au lieu de signaler par emprunt d’identité 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 serveur 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 (facultatif) : vérifiez si Microsoft Edge utilise les indicateurs de délégation appropriés

Voici l’étape de résolution des problèmes/vérification 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 déjà intégrés à Microsoft Edge ou disponibles en tant que services en ligne.

1. Utilisez la fonctionnalité de journalisation disponible dans Microsoft Edge pour consigner 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 sont omises.

      

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

   4. Ouvrez un autre onglet Microsoft Edge, accédez au site web sur lequel vous souhaitez effectuer des Authentification Windows intégrés à 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é et 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 quels paramètres le navigateur a passés à la InitializeSecurityContext fonction lors de la tentative d’authentification. Pour analyser la trace, utilisez la netlog_viewer.

3. À l’intérieur de la trace analysée, il s’agit d’un journal des événements semblable à 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 montre que :

   • 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) ne nécessite pas que le serveur s’authentifie également 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 liés à l’authentification intégrée Windows