On est quelques un à s’être cassé les dents dessus. Le fameux cas ou quoi que l’on fasse nos utilisateurs de services fédérés avec la solution ADFS ne peuvent pas s’authentifier sur Office 365. C’est un cas que l’on peut reproduire avec toutes les versions d’ADFS. En fait, nos utilisateurs peuvent s’authentifier autant qu’ils le veulent, ça les ramène toujours à la mire d’authentification.
Sur ce sujet, Microsoft a écrit de beaux articles :
- A federated user is repeatedly prompted for credentials during sign-in to Office 365, Azure, or Intune
- Possible causes of Authentications failures for federated users in Office 365
J’ai eu beau retourner ces articles dans tous les sens, impossible de trouver le pourquoi. J’avais juste quelques premières constatations. Quelque chose me disait qu’il y avait un coupable mais impossible de savoir comment le colonel moutarde avait tué dans la bibliothèque. Voilà quelles étaient mes premières constatations :
- Si on s’authentifie avec un compte qui n’existe pas ou un mot de passe faux, tout se déroule normalement
- Du point de vue ADFS, cela fonctionne, j’ai bien un Event qui m’indique qu’un ticket Kerberos a été délivré
- Ça ne concerne pas tous les comptes (sinon c’est pas drôle)
Après quelques heures de recherche, j’ai exclus Office 365 de la liste des suspects, tout comme les F5 BIG-IP et même les serveurs Web Application Proxy. En procédant par élimination, il ne restait donc que les deux serveurs ADFS de ma ferme. Vu que j’arrivais toujours à reproduire le problème en bloquant l’un ou l’autre de mes serveurs ADFS, j’en ai donc conclus que le problème était partagé par les deux serveurs de la ferme. Plus la peine de descendre plus bas, le coupable est nécessairement à cet étage. C’est en observant le fonctionnement de la ferme ADFS avec des comptes pour lesquels cela fonctionne et d’autres pour lesquels cela ne fonctionne pas que j’ai mis le doigt dessus.
Lorsqu’on reprend le processus de fonctionnement d’ADFS de bout en bout, notre serveur ADFS doit interroger l’annuaire Active Directory. Dans mon contexte, mon infrastructure ADFS utilise un compte de service GMSA. Voyant un token ADFS généré, je me disais qu’il n’y avait pas de problème. Erreur de ma part. J’ai fini par comparer les ACL sur les comptes différents comptes et finir par m’apercevoir d’un détail qui me choquait :
Ça a l’air de rien mais cette permission change tout lorsqu’on regarde un utilisateur, ou même un device :
C’est étrange mais quand elle est là (et que le compte de service de votre ferme ADFS n’est pas membre du groupe Admin du domaine), c’est tout de suite beaucoup plus facile pour ADFS de fonctionner normalement. Avec ces quatre permissions magiques, l’authentification ADFS fonctionne comme un charme. Maintenant qui m’a mis sur la voie ? Une fonctionnalité méconnue d’Active Directory : Effective Permissions, un vieux truc introduit avec Windows Server 2008 R2 !
En comparant les permissions effectives entre un compte pour lequel ADFS fonctionnait et un pour lequel la même infrastructure ADFS ne fonctionnait pas, j’ai fini par comprendre qu’il y avait une différence entre mes deux comptes et trouver les permissions manquantes. Accessoirement, ces permissions sont décrites dans le schéma comme on peut le voir ci-dessous :
Vu que le schéma n’avait pas altéré, j’en ait déduit qu’il y a eu modification des permissions au niveau de la racine du domaine (pas glop). Ne restait donc plus qu’à propager les bonnes permissions.
BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)
