Résoudre les problèmes de délégation Kerberos contrainte

Les méthodes d’authentification unique (SSO) varient entre les applications. Le proxy d’application Microsoft Entra fournit la délégation Kerberos contrainte (KCD) par défaut. Dans le proxy d’application, un utilisateur s’authentifie auprès d’une application privée à l’aide de Kerberos.

Cet article explique comment résoudre les problèmes les plus courants dans la configuration KCD. Il inclut des étapes de diagnostic que vous pouvez effectuer pour des implémentations plus complexes.

Cet article repose sur les hypothèses suivantes :

• Le proxy d’application Microsoft Entra est déployé et dispose d’un accès général aux applications non-KCD.

  Pour plus d’informations, consultez Prise en main du proxy d’application.

• Une application publiée est basée sur Internet Information Services (IIS) et l’implémentation Microsoft de Kerberos.

• Les hôtes de serveur et d’application se trouvent dans un seul domaine Microsoft Entra.

  Pour en savoir plus sur les scénarios inter-domaines et inter-forêts, consultez le livre blanc Understanding Kerberos constrained delegation with application proxy (Présentation de la délégation contrainte Kerberos avec le proxy d'application).

• L’application est publiée dans un client Microsoft Entra avec la préauthentification activée. Les utilisateurs sont censés s’authentifier à l’aide de l’authentification basée sur des formulaires.

  Les scénarios d’authentification client riches ne sont pas abordés dans cet article.

Considérations

La liste suivante décrit les considérations fondamentales relatives à la configuration de KCD et à l’utilisation avec le proxy d’application Microsoft Entra :

• Les erreurs de base ou les erreurs générales provoquent la plupart des problèmes. Avant de commencer à résoudre les problèmes, vérifiez toutes les conditions préalables à l’utilisation de l’authentification unique KCD avec le proxy d’application.

• Les hôtes de connecteur ne sont pas limités à communiquer avec un contrôleur de domaine de site local spécifique (DC). Vérifiez le contrôleur de domaine que vous utilisez, car il peut changer.

• Les scénarios inter-domaines s’appuient sur des références qui dirigent un hôte de connecteur vers des contrôleurs de domaine susceptibles de résider en dehors du périmètre du réseau local. Dans ces cas, il est tout aussi important d’envoyer le trafic vers les DCs qui représentent d’autres domaines. Si ce n’est pas le cas, la délégation échoue.

• Évitez d'utiliser des dispositifs actifs de prévention des intrusions (IPS) ou de détection des intrusions (IDS) entre les hôtes connecteurs et les contrôleurs de domaine (DC) en raison des interférences avec le trafic RPC (Remote Procedure Call) principal.

• Testez la délégation dans un scénario simple. Plus vous introduisez de variables dans un scénario, plus la configuration et la résolution des problèmes sont complexes. Pour gagner du temps, limitez vos tests à un seul connecteur. Ajoutez d’autres connecteurs une fois le problème résolu.

• Les facteurs environnementaux peuvent contribuer à la cause d’un problème. Pour éviter ces facteurs, réduisez l’architecture autant que possible pendant les tests. Par exemple, les listes de contrôle d’accès internes mal configurées sont courantes. Si possible, envoyez tout le trafic d’un connecteur directement aux contrôleurs de domaine et à l’application back-end.

• Le meilleur endroit pour positionner les connecteurs est le plus proche possible de leurs cibles. Un pare-feu qui se trouve en ligne lorsque vous testez le connecteur ajoute une complexité inutile et peut prolonger vos investigations.

• Qu’indique un problème KCD ? Plusieurs erreurs courantes indiquent que l’authentification unique KCD échoue. Les premiers signes d’un problème s’affichent dans le navigateur.

  Les deux captures d’écran suivantes montrent le même symptôme de l’échec de l’authentification unique : l’accès utilisateur à l’application est refusé.

  

  

Résolution des problèmes

Vous pouvez résoudre les problèmes de KCD en trois étapes. Vérifiez ces parties du processus KCD dans l’ordre suivant :

• Pré-authentification du client
• Service de délégation
• L’application cible

Pré-authentification du client

La pré-authentification du client fait référence à un utilisateur externe qui s’authentifie dans une application via un navigateur. La possibilité de préauthentifier l’ID Microsoft Entra est nécessaire pour que l’authentification unique KCD fonctionne.

Testez d’abord la pré-authentification du client et résolvez tous les problèmes. La phase de pré-authentification n’est pas liée à KCD ou à l’application publiée. Il est facile de corriger toutes les différences en vérifiant que le compte d’objet existe dans Microsoft Entra ID. Vérifiez que l’application n’est pas disponible ou bloquée. La réponse d’erreur dans le navigateur est généralement suffisamment descriptive pour expliquer la cause.

Service de délégation

Le service de délégation Kerberos est le connecteur de réseau privé qui obtient un ticket de service Kerberos à partir d’un centre de distribution de clés Kerberos (KDC). L’utilisateur de l’application s’authentifie auprès de l’application via le ticket.

Les communications externes entre le client et le front-end Azure n'ont aucun effet sur la délégation restreinte. Ces communications garantissent uniquement que KCD fonctionne. Le service proxy d’application reçoit un ID d’utilisateur valide qui obtient un ticket Kerberos. Sans cet ID, KCD ne peut pas se produire et l’authentification unique échoue.

Les messages d’erreur du navigateur fournissent des informations utiles sur la raison pour laquelle la connexion échoue. Enregistrez les valeurs pour TransactionID et Timestamp dans la réponse à la connexion de l’application. Les informations permettent de mettre en corrélation le comportement aux événements qui apparaissent dans le journal des événements du proxy d’application.

Les entrées correspondantes dans le journal des événements sont les ID d’événement 13019 ou 12027. Pour afficher les journaux des événements du connecteur, accédez à Applications and Services Logs>Microsoft>réseau privé Entra>Connecteur>Admin.

Pour résoudre un problème de délégation limitée :

1. Dans votre système DNS (Domain Name System) interne pour l’adresse de l’application, utilisez un enregistrement A, et non un enregistrement CNAME.
2. Assurez-vous que l'hôte du connecteur est configuré avec des autorisations pour déléguer au nom principal de service (SPN) du compte cible. Vérifiez que l’option Utiliser n’importe quel protocole d’authentification est sélectionnée. Pour plus d’informations, consultez la configuration de l'authentification unique (SSO).
3. Vérifiez qu’une seule instance du SPN existe dans l’ID Microsoft Entra. Pour vérifier un seul SPN, exécutez setspn -x à l'invite de commandes sur n’importe quel hôte membre du domaine.
4. Vérifiez qu’une stratégie de domaine qui limite la taille maximale des jetons Kerberos émis est appliquée. La stratégie empêche le connecteur d’obtenir un jeton si la taille du jeton dépasse un maximum défini.
5. L’exécution d’une trace réseau qui capture les échanges entre l’hôte du connecteur et un KCD de domaine est la meilleure étape suivante pour obtenir plus de détails sur le problème. Pour plus d’informations, vous pouvez consulter le livre blanc détaillé Résolution des problèmes du proxy d’application Microsoft Entra.

Si le ticketing fonctionne correctement, les logs montrent probablement un événement indiquant que l'authentification a échoué, car l'application a retourné une erreur 401. Cet événement indique que l’application cible a rejeté le ticket. Passez à l’étape suivante de la résolution des problèmes.

L’application

L’application cible traite le ticket Kerberos fourni par le connecteur. À ce stade, le connecteur inclut un ticket de service Kerberos en tant qu’en-tête dans la première demande d’application vers le serveur principal.

Pour résoudre un problème d’application :

1. Vérifiez que l’application est accessible. Connectez-vous directement à partir du navigateur sur l’hôte du connecteur à l’aide de l’URL interne définie dans le portail Azure. Si la connexion réussit, l’application est accessible.

2. Vérifiez si le navigateur et l’application utilisent Kerberos pour l’authentification. À partir de l’hôte du connecteur, utilisez DevTools d’Internet Explorer (appuyez sur F12) ou Fiddler pour accéder à l’application via l’URL interne. Recherchez « Négocier » ou « Kerberos » dans les en-têtes d’autorisation web dans la réponse de l’application.

   La réponse du navigateur à l’application inclut un objet blob Kerberos qui commence par YII, confirmant que Kerberos est en cours d’exécution. En revanche, une réponse de Microsoft NT LAN Manager (NTLM) commence toujours par TlRMTVNTUAAB. Lorsqu’elle est décodée à partir de Base64, cette réponse indique le fournisseur de support de sécurité NTLM (NTLMSSP). Si les objets blob commencent par TlRMTVNTUAAB, Kerberos n’est pas disponible. Si ce n’est pas le cas, Kerberos est probablement disponible.

   Remarque

   Si vous utilisez Fiddler, vous devez désactiver temporairement la protection étendue sur la configuration de l’application dans IIS.

   

   L’objet blob de cette capture d’écran ne commence pas par TIRMTVNTUAAB. Par conséquent, dans cet exemple, Kerberos est disponible et l’objet blob Kerberos ne commence pas par YII.

3. Sur le site IIS, supprimez temporairement NTLM de la liste des fournisseurs. Accédez directement à l’application à partir d’Internet Explorer sur l’hôte du connecteur. NTLM n’est plus dans la liste des fournisseurs. Vous pouvez donc accéder à l’application uniquement à l’aide de Kerberos. En cas d’échec de l’accès, un problème avec la configuration de l’application est indiqué. L'application ne traite pas l'authentification Kerberos.

4. Si Kerberos n’est pas disponible, vérifiez les paramètres d’authentification de l’application dans IIS. Assurez-vous que Negotiate est répertorié en haut et que NTLM est juste en dessous. Si vous ne voyez pas Négocier, Kerberos ou Négocier ou PKU2U, continuez uniquement si Kerberos est fonctionnel.

   

5. Avec Kerberos et NTLM en place, dans le portail, désactivez temporairement la pré-authentification pour l’application. Essayez d’accéder à l’application dans un navigateur à l’aide de l’URL externe. Vous êtes invité à vous authentifier. Utilisez le même compte que celui que vous avez utilisé à l’étape précédente. Si vous ne pouvez pas vous authentifier et vous connecter, il existe un problème avec l’application back-end, et non avec KCD.

6. Réactivez la pré-authentification dans le portail. Authentifiez-vous via Azure en essayant de vous connecter à l’application via son URL externe. Si l'authentification unique échoue, un message d'interdiction s'affiche dans le navigateur et l'événement à l'ID 13022 apparaît dans le journal :

   Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

   

7. Vérifiez l’application IIS. Vérifiez que le pool d’applications configuré et le SPN sont configurés pour utiliser le même compte dans l’ID Microsoft Entra. Dans IIS, accédez au dossier, comme illustré dans la capture d’écran suivante :

   

   Vérifiez l’identité, puis vérifiez que ce compte est configuré avec le SPN. À une invite de commandes, par exemple, exécutez setspn –q http/spn.contoso.com.

   

8. Dans le portail, vérifiez le SPN défini par rapport aux paramètres de l’application. Assurez-vous que le pool d’applications de l’application utilise le même SPN défini pour le compte Microsoft Entra cible.

9. Dans IIS, sélectionnez l’option Éditeur de configuration pour l’application. Accédez à system.webServer/security/authentication/windowsAuthentication. Vérifiez que la valeur de UseAppPoolCredentials a la valeur True.

   

   Remplacez la valeur par True si nécessaire. Supprimez tous les tickets Kerberos mis en cache du serveur principal en exécutant la commande suivante :

   Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
   

10. Si le mode noyau est activé, les opérations Kerberos s’améliorent. Mais le ticket du service demandé doit également être déchiffré à l’aide du compte d’ordinateur. Ce compte est également appelé système local. Définissez cette valeur sur True pour interrompre le KCD lorsque l’application est hébergée sur plusieurs serveurs d’une batterie de serveurs.

11. En guise d’autre vérification, désactivez la protection étendue. Dans certains scénarios de test, la protection étendue a rompu le KCD lorsqu’elle a été activée dans des configurations spécifiques. Dans ces cas, une application a été publiée en tant que sous-dossier du site web par défaut. Cette application est configurée uniquement pour l’authentification anonyme. Toutes les boîtes de dialogue sont inactives, sans sélection disponible, ce qui suggère que les objets enfants n’héritent pas des paramètres actifs. Nous vous recommandons de tester, mais n’oubliez pas de restaurer cette valeur à activé si possible.

    Cette vérification supplémentaire vous prépare à utiliser votre application publiée. Vous pouvez générer davantage de connecteurs qui sont également configurés pour déléguer. Pour plus d’informations, consultez la procédure technique plus détaillée sur la résolution des problèmes du proxy d’application Microsoft Entra.

Si vous ne pouvez toujours pas résoudre le problème d’authentification d’application, créez un ticket de support directement dans le portail.

Autres scénarios

Le proxy d’application Microsoft Entra demande un ticket Kerberos avant d’envoyer une demande à une application. Certaines applications ne prennent pas en charge cette méthode d’authentification. Ces applications sont configurées pour répondre aux étapes d’authentification plus conventionnelles. La première requête est anonyme, ce qui permet à l’application de répondre aux types d’authentification qu’elle prend en charge par le biais d’une erreur 401. Vous pouvez configurer ce type de négociation Kerberos en suivant les étapes décrites dans la délégation contrainte de Kerberos pour l’authentification unique.

L’authentification multi-tronçon est couramment utilisée lorsqu’une application est hiérarchisée. Les niveaux incluent un serveur principal et un serveur frontal. Les deux niveaux nécessitent une authentification. Par exemple, vous pouvez créer une application hiérarchisée à l’aide de SQL Server Reporting Services. Pour en savoir plus, consultez Configurer la délégation Kerberos contrainte pour les pages proxy d'inscription via le Web.

Contenu connexe

• Configurer le KCD sur un domaine managé