Introduction
Avec le développement de l'authentification unique en entreprise, ADFS (Active Directory Federation Services) est devenu un rôle de plus en plus déployé. Même si son déploiement reste simple et très documenté (grâce notamment, au déploiement d'Office 365), il est courant de rencontrer des difficultés lorsque l'on souhaite ajouter une fédération ou réaliser une configuration spécifique.
Au cours de cette article, il sera question de résoudre une erreur pouvant se produire lors de l'ajout d'une fédération, c’est-à-dire lorsque l'on veut utiliser son système d'authentification d'entreprise avec un partenaire (une application SAAS par exemple). Généralement, les informations permettant d'établir une fédération sont contenues dans un fichier de métadata qui est accessible depuis une url ou qu'il faut importer via un fichier. Cependant, des erreurs dans le fichier de métadata fourni par le partenaire peuvent empêcher d'avoir une configuration correcte.
Problème rencontré
L'ajout d'une fédération s'effectue dans la console de gestion ADFS via l'action "Add relying party trust" dans le menu "Trust Relationships / Relying Party Trusts".
Lorsque l'assistant s'ouvre, il est possible de choisir la méthode de configuration de la fédération. Il existe trois méthodes :
-
Une url d'accès au metadata : il s'agit de la méthode nécessitant le moins de maintenance. Les mises à jour des métadata sont prises en compte automatiquement. Si vous souhaitez fournir les vôtres via cette méthode (afin de faciliter la configuration pour le partenaire), il suffit d'ouvrir l'accès à l'url suivante https://NOM_DNS/federationmetadata/2007-06/federationmetadata.xml (n'oublier pas de remplacer NOM_DNS par le nom DNS d'accès au service ADFS).
-
Un fichier de metadata : il s'agit d'un fichier fourni par le partenaire dont le contenu est identique à celui présent via la première méthode.
-
Une configuration manuelle : il faut insérer chaque paramètre manuellement
La méthode qui nous intéresse ici et qui peut poser problème est la seconde. En effet, si le fichier contient des erreurs de syntaxe, le message suivant peut apparaitre :
Some of the content in the federation metadata was skipped because it is not supported by AD FS. Review the properties of the trust carefully before you save te trust to the ADFS configuration database.
Même si celle-ci n'est pas bloquante, elle peut entrainer une mauvaise configuration de la fédération.
Résolution
Les conseils ci-dessous sont issues de retour d'expérience. Lorsque l'erreur ci-dessus est rencontrée, il convient de modifier le fichier est de faire des tests de façon dichotomique afin d'obtenir une configuration valide. Par exemple, on peut supprimer les assertions une à une afin de trouver celle(s) qui posent problème. Il faudra ensuite vérifier si elle est nécessaire pour le bon fonctionnement de la fédération (auquel cas, un correctif devra être trouvé) ou si elle peut être supprimée.
La principale erreur rencontrée dans un fichier de métadata est la présence d'assertion pour plusieurs versions de SAML. En effet ADFS supporte les standards SAML en version 1.0, 1.1 et 2.0 permettant d'échanger des informations avec un partenaire de manière sécurisée. Même si cela permet à un partenaire de ne maintenir qu'un seul fichier de métadata, ADFS ne tolère la présence que d'une version de SAML par fichier. Par exemple, la présence concomitante de ces deux assertions doit être proscrite :
Dans ce cas là, il suffira de supprimer les assertions en SAML v1.0.
D'autre part, une erreur courante est d'intégrer des URLs non sécurisées (HTTP au lieu de HTTPS). Cela n'est pas autorisé.
Dernière erreur courante, ADFS est permissif sur la syntaxe et plus précisément sur la casse des assertions. Ainsi, l'assertion suivante est invalide si HTTP-Redirect est remplacé par HTTP-REDIRECT.
Aussi, si vous souhaitez accéder à la syntaxe complète du langage SAML afin de valider un fichier de métadata, vous trouverez ci-dessous des liens détaillant la syntaxe selon la version :