Une popup dans une botte de foin

#Ad   #Kerberos   #Ntlm   #Popup   #Chrome   #Edge   #Firefox  

Je partage cette analyse sur un souci souvent rencontré dans la mise en place d’une authentification Kerberos sur une application web. Dans le cas où cette application est aussi accédée par des utilisateurs dont on ne maitrise pas l’environnement de A à Z (accès, poste, navigateur) on rencontre cette fameuse popup dont on se passerait bien…

Contexte

Une application web est configurée pour authentifier l’utilisateur via le protocole Kerberos, en cas d’échec l’utilisateur doit être redirigé vers la page d’authentification par formulaire. L’enchaînement de ces étapes définit la chaîne d’authentification. Il s’agit de la chaîne d’authentification normale et attendue dans un environnement maitrisé (poste utilisateur, navigateur, réseau, domaine active directory)

Mais entre ces deux étapes attendues, sur les navigateurs dont le moteur est Chromium donc tout sauf Firefox et Safari finalement, l’utilisateur se voit présenter une fenêtre de type popup d’authentification (intempestive et inutile) car :

Explications

Un serveur HTTP n’envoie pas de réponse HTTP demandant spécifiquement l’authentification Kerberos dès le début.

Il commence par répondre que l’accès n’est pas autorisé, au travers une réponse de type 401 - unauthorized (non autorisée) avec un en-tête WWW-Authenticate:, en-tête qui détermine les types de mécanismes d’authentification pris en charge par le serveur Web comme basic, bearer, digest, negotiate, etc.

Dans le cas de Kerberos, la valeur de l’en-tête est positionnée à negotiate , mais cette valeur comme son nom l’indique (négocier) supporte à la fois l’authentification Kerberos et l’authentification NTLM. Il s’agit de négocier le protocole, en proposant Kerberos dans un premier temps car plus sécurisé et NTLM dans un second temps, si Kerberos échoue.

Il est possible de forcer le NTLM avec l’en-tête WWW-Authenticate: NTLM mais pour du Kerberos la seule option est la négociation au travers de l’en-tête WWW-Authenticate: negotiate. Il n’existe donc malheureusement pas d’option du type WWW-Authenticate: Kerberos qui n’autoriserait que le protocole Kerberos…

C’est une norme qui est défini dans la RFC 4559, ce n’est en aucun cas lié à la configuration de l’application web.

Donc si le navigateur peut effectuer l’authentification Kerberos, c’est à dire que : le poste est bien dans le domaine, que l’utilisateur à ouvert une session, que le navigateur autorise la prise en charge de la valeur WWW-Authenticate: negotiate pour l’url de l’application web (via une GPO ), alors il obtient un ticket de service Kerberos pour l’application web et l’envoie dans un en-tête HTTP Authorization: au serveur Web pour être authentifié.

En revanche, si le navigateur ne peut pas effectuer l’authentification Kerberos car ne respecte pas les conditions énoncées plus haut (désactivé par défaut ou non configuré pour le faire, ne peut pas contacter le centre de distribution de clés Kerberos (KDC qui est sur l’AD), etc.) alors conformément au mécanisme negotiate, le navigateur s’adapte et bascule sur l’utilisation de NTLM (“Fallback NTLM”).

À ce stade, le navigateur affiche la popup d’authentification NTLM et n’avance pas automatiquement selon la chaîne d’authentification normale.

Pour faire du NTLM, le navigateur demande un nom d’utilisateur et un mot de passe. Il s’agit de la popup qui apparaît et qu’on peut confondre avec une popup utilisée pour l’authentification HTTP Basic. Mais non, ces informations seraient légitimement utilisés dans le contexte du protocole NTLM car c’est le hash MD4 dérivé du mot de passe de l’utilisateur qui permet de chiffrer le challenge NTLM, bref …

Si l’utilisateur saisit ses informations d’authentification et clique sur le bouton Valider, l’authentification échouera quand même puisque l’application attend uniquement du Kerberos pas du NTLM. Donc échec d’authentification, la chaîne d’authentification reprend son cours et redirige l’utilisateur sur la page d’authentification par formulaire.

Si l’utilisateur appuie sur le bouton Annuler sans rien saisir, le navigateur envoie une autre demande sans informations d’authentification. Donc échec d’authentification, la chaîne d’authentification reprend son cours et redirige l’utilisateur sur la page d’authentification par formulaire.

Conclusion

Même si des contournements ont été imaginés au travers de mécanismes de redirection initiés par des directives “meta redirect” dans le corps des pages HTML ou bien par l’intermédiaire de redirection javascript qui recharge immédiatement la page, l’objectif final étant d’essayer d’empêcher l’affichage de la popup :

Car si Kerberos fonctionne, le rechargement contiendra les informations d’authentification Kerberos et si Kerberos ne fonctionne pas, le rechargement ne contiendra pas les informations d’identification Kerberos mais contiendra quand même le cookie d’état et le navigateur sera redirigé vers la page d’authentification par formulaire. Mais ces redirections sont plus ou moins bien supportées selon les versions des navigateurs et d’OS… et ça ne marche donc pas de manière pérenne.

Rien n’y fait et c’est définitivement bien au navigateur de corriger ce problème d’expérience utilisateur, le protocole fonctionnant comme prévu.

Firefox a réglé le problème il y a quelques années mais Chromium a en 2019 classé ça en “Wontfix” (ne réparera pas) …

Ressources