Corriger les problèmes de configuration de délégation Kerberos contrainte (KCD) avec le proxy d’application Microsoft Entra

Les méthodes d’authentification unique varient d’une application à une autre. Le proxy d’application Microsoft Entra fournit par défaut la délégation Kerberos contrainte (KCD). Les utilisateurs s’authentifient auprès d’applications privées à l’aide de Kerberos.

Cet article fournit un point de référence unique pour résoudre les problèmes les plus courants. Il explique également comment diagnostiquer des problèmes d'implémentation plus complexes.

Cet article repose sur les hypothèses suivantes.

• Déploiement du proxy d’application Microsoft Entra et accès général aux applications non-KCD. Pour plus d’informations, consultez Démarrage avec le proxy d’application.
• L’application publiée est basée sur IIS (Internet Information Services) et sur l’implémentation de Kerberos par Microsoft.
• Les hôtes de serveur et d’application se trouvent dans un même domaine Microsoft Entra. Pour plus d’informations sur les scénarios inter-domaines et inter-forêts, reportez-vous au livre blanc sur la délégation Kerberos contrainte.
• L’application est publiée dans un locataire Microsoft Entra ID où la préauthentification est 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 enrichis ne sont pas couverts par cet article.

Prérequis

La plupart des problèmes sont dus à de simples erreurs de configuration ou à des erreurs générales. Vérifiez toutes les conditions préalables dans Utilisation de l’authentification unique KCD avec le proxy d’application avant de résoudre les problèmes.

Les hôtes de connecteur ne communiquent pas uniquement avec des contrôleurs de domaine de sites locaux spécifiques. Vérifiez que le contrôleur de domaine utilisé n’a pas changé.

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 ce cas, il convient également de diriger le trafic vers les contrôleurs de domaine qui représentent les autres domaines respectifs, faute de quoi la délégation échouera.

Évitez les appareils IPS (système de prévention d’intrusion) ou IDS (système de détection d'intrusion) actifs entre les hôtes de connecteur et les contrôleurs de domaine. Ces appareils sont trop intrusifs et interfèrent avec le trafic RPC (appel de procédure distante) principal.

Testez la délégation dans des scénarios simples. Plus vous introduisez de variables, plus vous augmentez le nombre d’éléments à prendre en compte. Pour gagner du temps, limitez votre test à un seul connecteur. Ajoutez d’autres connecteurs une fois le problème résolu.

Certains facteurs environnementaux peuvent également contribuer à un problème. Pour écarter ces facteurs, réduisez l'architecture au minimum pendant le test. Par exemple, les listes de contrôle d’accès internes (ACL) mal configurées sont courantes. Si possible, envoyez directement le trafic d’un connecteur vers les contrôleurs de domaine et vers l’application principale.

Les connecteurs doivent être positionnés le plus près possible de leurs cibles. La présence d'un pare-feu entre eux lors du test accroît inutilement la complexité et peut prolonger vos investigations.

Quels sont les signes d'un problème de KCD ? Différents signes peuvent révéler un échec de l'authentification unique KCD. Les premiers signes d'un problème apparaissent dans le navigateur.

Les deux images présentent le même symptôme : échec de l’authentification unique. L'accès à l’application est refusé à l'utilisateur.

Dépannage

Séparez la résolution des problèmes en trois étapes.

Préauthentification du client

L’utilisateur externe s’authentifie via un navigateur. La possibilité de préauthentifier auprès de Microsoft Entra ID est nécessaire pour que l’authentification unique (SSO) KCD fonctionne. Vérifiez ce point et remédiez aux problèmes éventuels. L’étape de préauthentification n’a aucun lien avec la délégation Kerberos contrainte ou avec l’application publiée. Les éventuelles incohérences peuvent être facilement corrigées en vérifiant que le compte concerné existe dans Microsoft Entra ID. Vérifiez que l’application n’est pas désactivée ou bloquée. Le message d’erreur du navigateur est suffisamment descriptif pour permettre l’identification de la cause.

Service de délégation

Connecteur de réseau privé qui obtient un ticket de service Kerberos pour les utilisateurs à partir d’un centre de distribution de clés Kerberos (KCD).

Les communications externes entre le client et le serveur frontal Azure n'ont aucune incidence sur la délégation Kerberos contrainte. Elles veillent uniquement au bon fonctionnement de la délégation Kerberos contrainte. Un ID d’utilisateur valide est fourni au service de proxy d’application. Il sera utilisé pour l’obtention d’un ticket Kerberos. Sans cet identifiant, la délégation Kerberos contrainte est impossible et échoue.

Les messages d’erreur du navigateur fournissent de bonnes indications sur les raisons d’un échec. Enregistrez les champs activity ID et timestamp dans la réponse. Ces informations permettent de mettre le comportement en corrélation avec des événements réels dans le journal des événements du proxy d’application.

Les entrées correspondantes du journal des événements apparaissent en tant qu'événement 13019 ou 12027. Trouvez les journaux des événements des connecteurs sous Journaux des applications et des services>Microsoft>Réseau privé Microsoft Entra>Connecteur>Administrateur(-trice).

1. Utilisez un enregistrement A dans votre DNS (Domain Name System) interne pour l’adresse de l’application, et non un CName.
2. Vérifiez de nouveau que l’hôte de connecteur dispose du droit nécessaire de déléguer au nom de principal du service (SPN) du compte cible désigné. Vérifiez de nouveau que l'option Utiliser tout protocole d’authentification est sélectionnée. Pour plus d’informations, consultez l’article consacré à la configuration de l’authentification unique.
3. Vérifiez qu’il n'existe qu'une seule instance du SPN dans Microsoft Entra ID. Entrez setspn -x à partir d’une invite de commandes sur un hôte membre de domaine.
4. Vérifiez qu’une stratégie de domaine limitant la taille maximale des jetons Kerberos émis est appliquée. La stratégie empêche le connecteur d'obtenir un jeton s’il est excessif.

Pour obtenir d’autres informations de base sur les problèmes rencontrés, l’étape suivante consiste à assurer un suivi réseau capturant les échanges entre l’hôte de connecteur et une délégation Kerberos contrainte (KDC) du domaine. Pour plus d’informations, consultez le document consacré à la résolution approfondie des problèmes.

Si l’émission de tickets semble correcte, les journaux d’activité contiennent un événement mentionnant que l’authentification a échoué en raison du renvoi d’une erreur 401 par l’application. Cet événement indique que l’application cible a rejeté votre ticket. Passez à l’étape suivante.

Application cible

Consommateur du ticket Kerberos que le connecteur a fourni. À ce stade, attendez-vous à ce que le connecteur ait envoyé un ticket de service Kerberos au serveur principal. Le ticket correspond à un en-tête figurant dans la première demande d’application.

1. À l’aide de l’URL interne de l’application définie sur le portail, vérifiez que l’application est directement accessible à partir du navigateur sur l’hôte de connecteur. Vous pouvez alors vous connecter. Pour plus d’informations, reportez-vous à la page consacrée à la résolution des problèmes de connecteur.

2. Vérifiez que l’authentification entre le navigateur et l’application se fait à l’aide de Kerberos.

3. Exécutez les outils de développement (F12) d'Internet Explorer, ou utilisez Fiddler à partir de l’hôte de connecteur. Accédez à l’application à l’aide de l’URL interne. Pour vous assurer que Negotiate ou Kerberos est mentionné, examinez les en-têtes d’autorisation web retournés dans la réponse de l’application.

   • L’objet blob Kerberos suivant retourné dans la réponse du navigateur à l’application commence par YII. Ces lettres indiquent que Kerberos est en cours d'exécution. En revanche, NTLM (Microsoft NT LAN Manager) commence toujours par TlRMTVNTUAAB, soit NTLMSSP (NTLM Security Support Provider) lors d’un décodage en Base64. Si TlRMTVNTUAAB figure au début de l'objet blob, Kerberos n’est pas disponible. En revanche, si TlRMTVNTUAAB y figure, Kerberos est vraisemblablement disponible.

     Notes

     Si vous utilisez Fiddler, cette méthode nécessite de désactiver temporairement la protection étendue dans la configuration de l’application dans IIS.

     

   • L’objet blob présenté dans cette illustration ne commence pas par TIRMTVNTUAAB. Par conséquent, dans cet exemple, Kerberos est disponible, et l’objet blob Kerberos ne commence pas par YII.

4. Supprimez temporairement NTLM de la liste des fournisseurs sur le site IIS. Accédez à l’application directement à partir d’Internet Explorer sur l’hôte de connecteur. NTLM ne figure plus dans la liste des fournisseurs. Vous ne pouvez accéder à l’application qu'à l’aide de Kerberos. Un échec de l'accès peut indiquer qu'il existe un problème de configuration de l’application. L’authentification Kerberos ne fonctionne pas.

   • Si Kerberos n’est pas disponible, vérifiez les paramètres d’authentification de l’application dans IIS. Assurez-vous que Negotiate figure en haut, avec NTLM juste en-dessous. En présence de Not Negotiate, Kerberos or Negotiate ou PKU2U, ne continuez que si Kerberos fonctionne.

     

   • Une fois Kerberos et NTLM en place, désactivez temporairement la préauthentification de l’application sur le portail. Essayez d’y accéder sur Internet à l’aide de l’URL externe. Vous êtes invité à vous authentifier. Pour ce faire, vous pouvez utiliser le même compte qu'à l’étape précédente. Si l'authentification échoue, le problème vient de l'application principale, pas de la délégation Kerberos contrainte.

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

     Le connecteur de réseau privé Microsoft Entra ne peut pas authentifier l'utilisateur car le serveur principal répond aux tentatives d'authentification Kerberos par une erreur HTTP 401.

     

   • Vérifiez l’application IIS. Assurez-vous que le pool d’applications configuré et le nom principal du service (SPN) sont configurés pour utiliser le même compte dans Microsoft Entra ID. Naviguez dans IIS comme indiqué dans l’illustration suivante.

     

     Une fois l’identité connue, vérifiez que ce compte est configuré avec le SPN en question. par exemple setspn –q http/spn.wacketywack.com. Entrez le texte suivant dans une invite de commandes.

     

   • Comparez le SPN défini et les paramètres de l’application sur le portail. Assurez-vous que le SPN configuré sur le compte Microsoft Entra cible est identique à celui utilisé par le pool d’applications.

   • Accédez à IIS et sélectionnez l'option Éditeur de configuration de l’application. Accédez à system.webServer/security/authentication/windowsAuthentication. Assurez-vous que la valeur UseAppPoolCredentials est définie sur True.

     

     Remplacez la valeur par True. Supprimez tous les tickets Kerberos mis en cache sur le serveur principal en exécutant la commande.

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

Si vous laissez le mode noyau activé, les opérations Kerberos seront plus performantes. Toutefois, le ticket du service demandé sera déchiffré à l’aide du compte d’ordinateur. Ce compte est également appelé système local. Définissez cette valeur sur True pour rompre la délégation Kerberos contrainte lorsque l’application est hébergée sur plusieurs serveurs au sein d'une batterie.

• Pour approfondir la vérification, désactivez également la protection étendue. Dans certains scénarios, la protection étendue rompt la délégation Kerberos contrainte lorsqu’elle est activée avec des configurations spécifiques. Dans ce cas, une application est publiée en tant que sous-dossier du site web par défaut. Cette application est configurée pour l’authentification anonyme uniquement. Toutes les boîtes de dialogue sont grisées, ce qui indique que les objets enfants n’héritent pas des paramètres actifs. Si possible, nous vous recommandons d'effectuer un test, mais n’oubliez pas de réactiver cette valeur.

  Cette vérification supplémentaire vous permet d'utiliser votre application publiée. Vous pouvez lancer plus de connecteurs qui sont également configurés pour la délégation. Pour plus d’informations, lisez la procédure technique approfondie Résolution des problèmes de proxy d’application Microsoft Entra.

Si le problème persiste, contactez le support technique Microsoft. Émettez un ticket de support à partir du portail.

Autres scénarios

Le proxy d’application Microsoft Entra demande un ticket Kerberos avant d’envoyer sa requête à une application. Certaines applications n’aiment pas cette méthode d’authentification. Ces applications préfèrent les négociations plus conventionnelles. La première demande est anonyme, ce qui permet à l’application de répondre avec les types d’authentification qu’elle prend en charge via une erreur 401. Ce type de négociation Kerberos peut être activé à l’aide des étapes décrites dans ce document : Délégation contrainte Kerberos pour l’authentification unique.

L’authentification sur plusieurs tronçons est couramment utilisée dans les scénarios où une application est hiérarchisée. Les niveaux sont le serveur principal et le serveur frontal. Les deux niveaux exigent une authentification. Par exemple, SQL Server Reporting Services. Pour plus d’informations, consultez Configurer la délégation Kerberos contrainte pour les pages proxy d’inscription via le Web.

Étapes suivantes

Configurer la délégation Kerberos contrainte sur un domaine géré.