PI Services

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 :

• SAML v2 : https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

• SAML v1.1 : https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

Introduction

Active Directory Federation Services (ADFS) permet de transmettre n'importe quel attribut d'un objet Active Directory à un partenaire par le biais d'une fédération. Cela reste facilement paramétrable via l'interface de gestion ADFS Management (ce paramétrage sera d'ailleurs détaillé dans la suite de cet article).

Cependant, il peut arriver que l'on souhaite transformer un attribut Active Directory en réalisant notamment des manipulations de chaines de caractères. Dans cet article nous étudierons le cas de l'attribut ObjectGuid qui est envoyé de manière encodée (en base 64) et dont le but sera de le transmettre sous la forme standard (exemple : {3F2704E0-4289-11D3-9B0C-0305E92C1301}). Il est aussi possible d'imaginer d'autres cas d'usage comme : mettre en majuscule un attribut, tronquer une chaîne de caractère...

Cette opération se réalise en deux étapes :

• Le développement d'une DLL contenant l'opération de transformation de l'attribut.

• Le déploiement de cette DLL sur un environnement ADFS. Cette dernière sera utilisé au travers d'un "custom attribute store" ADFS en conjonction avec une règle personnalisée de transformation de revendications lors de la configuration de la fédération.

Pour réaliser toutes ces manipulations, il est nécessaire d'avoir un environnement ADFS déjà opérationnel ainsi que Visual Studio (en version 2013 ou supérieure).

Les notions de développements abordées pendant cet article sont très accessibles y compris pour quelqu'un ne développant pas. Le langage utilisé est le C#.

En bonus, vous trouverez une petite application console permettant de tester les attributs retournés par vos fédérations.

NB : Cette article a été rédigé à partir d'une infrastructure ADFS 3.0 (Windows 2012 R2) et de Visual Studio 2015. Il est inspiré d'un article de Tino Donderwinkel : ici.

Fonctionnement

Tout d'abord, voici le principe de fonctionnement lorsqu'une nouvelle revendication doit être transmise à une fédération :

• Une règle basée sur le template LDAP récupère l'attribut AD que l'on souhaite transmettre.

• Une règle personnalisée traite la première revendication et la retourne dans une deuxième revendication après qu'elle ait subit sa transformation via une méthode appelée dans un custom attribute store

Le custom attribute store est composé d'une DLL qui contiendra toutes nos méthodes permettant de transformer des revendications. En effet, dans cet article nous modifions une revendication provenant d'un annuaire Active Directory mais celle-ci peut très bien être issue d'un autre référentiel puisque notre custom attribute store traite une revendication et non un attribut LDAP.

Le développement du custom attribute store nécessite d'implémenter des références à une DLL ADFS. Cela passe par l'ajout d'une DLL contenu dans le répertoire d'ADFS. Cette dernière contient 3 méthodes qu'il faut implémenter :

• Initialize : Elle permet de fournir des paramètres de configuration à l'attribute store. Elle ne sera pas utiliser dans notre cas.

• BeginExecuteQuery : Cette méthode contient une reqête sur l'attribute store. Cela sera modélisé par une méthode de transformation de notre attribut.

• EndExecuteQuery : Elle est appelé lorsque la méthode EndExecuteQuery a terminé son exécution. Elle prend en paramètre le résultat retourné par la méthode précédente.

Prérequis

Pour développer un nouvel attribute store, il faut copier la DLL nommée “Microsoft.IdentityServer.ClaimsPolicy.dll” depuis un serveur ADFS sur l'ordinateur où Visual Studio est installé (celle-ci est située dans “C:\Windows\ADFS”).

Développement

Lorsque le prérequis est rempli, nous pouvons lancer Visual Studio est créer un nouveau projet via le bouton “File” puis “New” et enfin “Project”.

Dans la section “template”, on choisit la catégorie Visual C# et le modèle bibliothèque de classes (“Class Library”). La version 4.5 du Framework .Net ainsi qu'un chemin pour stocker les fichiers doivent être définies.

Le fichier qui nous intéresse le plus et le fichier “Class1.cs” qu'il est possible de renommer via un clic droit puis “Rename” en oubliant pas de valider la popup suivante permettant de modifier toutes les références à ce fichier dans notre projet.

Nous devons ensuite ajouter des références à notre projet. Pour rappel, ces dernières vont nous permettre de communiquer avec l'infrastructure ADFS en joignant entre autre la DLL précédemment copiée (“Microsoft.IdentityServer.ClaimsPolicy.dll”).

Cette première dépendance s'ajoute en effectuant un clic droit sur le champ “References” dans le menu de droite (Solution Explorer) puis en cliquant sur “Add Reference”.

Il faut choisir l'onglet “Browse” et enfin se rendre à l'emplacement de la DLL et la sélectionner

La seconde dépendance s'ajoute de la même manière Il s'agit de “System.IdentityModel”. Il est seulement nécessaire de se rendre dans le menu “Assemblies” au lieu de “Browse”.

Enfin, on ajoute les lignes de codes ci-dessous dans le fichier de classe.

Cela permet d'indiquer les références utilisées dans la classe.

Une fois les références ajoutées, il faut implémenter les méthodes explicitées dans le paragraphe précédent. Pour se faire, on doit ajouter ce qu'on appelle une interface à notre classe. Cela nous donnera accès aux méthodes permettant d'interagir avec ADFS. Notre classe représente l'attribute store que l'on souhaite créé.

Pour ajouter l'interface, il suffit d'ajouter “ : IAttributeStore” après “public class CustomStringAttributeStore”. Un avertissement est levé car Visual Studio ne trouve pas le code permettant de dire que notre classe est un attribute store (il cherche les 3 méthodes évoquées précédemment). Pour corriger cela, il suffit de faire un clic droit sur “IattributeStore” puis de cliquer sur “Implement Interface”. Le code de base pour les 3 méthodes est automatiquement généré.

Ci-dessous, vous trouverez le code pour chacune d'entre elles.

Initialize :

BeginExecuteQuery :

Il s'agit de la méthode où se déroule toute la logique de transformation. La section la plus importante est contenue à l'intérieure de la structure logique Switch. En fonction de la requête demandée, une transformation sera appliquée. Dans notre exemple, je n'ai qu'un seul cas possible, mais on peut améliorer cet attribute store afin qu'il contienne toutes les règles de transformations dont nous avons besoin.

NB : Une méthode Base64ToGuid est appelée dans le case Base64ToGuid. Cette méthode permet de convertir en chaîne lisible, le Guid d'un objet AD qui est normalement encodé en base 64.

EndExecuteQuery :

Le lien suivant mène vers le code complet de la classe : ici

Il suffit ensuite de générer la DLL en passant par le menu “Build” puis en cliquant sur “Build Solution”. La DLL est générée dans le sous répertoire “bin\Debug” du projet défini lors de la création. Par défaut il s'agit du chemin “C:\Users\nom_d'utilisateur\Documents\Visual Studio 2015\Projects”.

Déploiement

Une fois la DLL copiée, il faut la copier sur tous les serveurs ADFS dans le répertoire “C:\Windows\ADFS” (Attention : La DLL ne doit pas être déployée sur les serveurs Web Application Proxy). On peut ensuite passer à la configuration qui se fait via la console ADFS Management.

Configuration du Custom Attribute Store

Dans la section "Trust Relationship", effectuer un clic droit sur “AttributeStore” et cliquer sur “Add Custom Attribute Store”.

Une popup s'ouvre. Il faut renseigner le champ “Custom attribute store class name”. Ce champ doit être rempli avec attention et nécessite une syntaxe particulière :

Namespace.Classe,Nom_du_fichier_dll

Namespace : il s'agit du nom indiquer à côté de ce mot clé dans notre fichier de classe (Ici : CustomStringTransformAttributeStore).

Classe : Le nom de la classe (Ici : StringTransform)

Nom_du_fichier_dll : le nom de la DLL sans son extension (ici : CustomStringTransformAttributeStore)

Lorsque la configuration est validée, un évènement 251 apparait dans le journal Admin d'ADFS (dans la catégorie Applications and Services de l'observateur d'évènements). Lorsqu'il y a une erreur de configuration, un évènement avec l'ID 159 est présent.

Configuration de la fédération de test

Nous allons maintenant créer une fédération de test. Celle-ci ne doit pas forcément pointer vers un service réel. L'outil fourni dans le chapitre suivant permettra de générer des tokens. Dans la section Trust Relationship, il faut se rendre dans la section “Relying Party Trusts” puis choisir l'option “Add Relying Party Trust”.

Cliquez sur le bouton “Start” après l'ouverture de l'assistant. Choisir l'option “Enter data about the relying party manually”.

Insérez un nom pour la fédération puis cliquez sur “Next”.

Cliquez sur “Next” sur les onglets suivants jusqu'à “Configure Identifiers”. Entrez une url dans le champ “Relying party trust identifier” puis cliquez sur “Add”. Cette url n'a pas besoin de répondre.

Il faut ensuite cliquez sur suivant jusqu'à la fin de l'assistant en laissant cocher la case “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes”. Cela nous permettra d'ajouter nos règles sur les revendications dès la création de la fédération (sinon, il vous faudra faire un clic droit sur la fédération et choisir “Edit Claim Rules”).

Dans l'assistant d'édition des règles de revendications, nous allons ajouter deux règles dans l'onglet “Issuance Transform Rules”. Pour se faire cliquez sur “Add Rule”.

Dans l'assistant, nous ajoutons une première règle qui va récupérer un attribut LDAP. On sélectionne donc le modèle “Send LDAP Attributes as Claims”.

On peut ensuite définir un nom puis choisir “Active Directory” en tant qu'attribute store. Enfin, on entre l'attribut LDAP qui nous intéresse pour la colonne “LDAP Attribute” (il peut être inséré à la main s'il n'est pas présent dans la liste comme c'est le cas pour “objectGUID”) puis on choisit une valeur pour “Outgoing Claim Type” (ici, j'ai choisi “Common Name”).

On ajoute ensuite une seconde règle qui va utiliser notre custom attribute store. Cette fois-ci le template à utiliser est “Send Claims Using a Custom Rule”. On défini ensuite un nom et on peut insérer le code suivant dans le champs “Custom Rule”.

Cette règle récupère la revendication “CommonName” que nous avons défini précédemment en tant que revendication de sortie de notre annuaire Active Directory et la transmet à notre custom attribute store (elle est retournée en tant que revendication de type “nameidentifier” en lui appliquant la méthode Base64ToGuid qui correspond au cas que l'on a défini dans notre classe “Transform.cs”. Il est bien entendu possible de changer les revendications, la requête ou le nom du custom attribute store en fonction de vos valeurs.

Test

Afin de tester vos fédérations, je met un outil console à disposition que j'ai développé et que vous pouvez récupérer via le lien suivant : ici. Il sera utile pour valider le bon fonctionnement de notre custom attribute store mais il vous permettra aussi de voir les revendications envoyées à vos partenaires pour n'importe laquelle de vos fédérations. En plus de ce dernier vous devez avoir dans le magasin racine de confiance, le certificat permettant de signé les tokens d'authentification (Token-Signing). Dans un déploiement par défaut, il est auto-signé.

L'outil est composé d'un .exe et d'un fichier .config. Ce dernier doit être rempli. Les paramètres à changer sont :

• relyingPartyId : il s'agit de l'url d'accès à la fédération (le champ "identifier") : https://adfstest.myenterprise.com/adfs/services/trust.

• adfsEndpoint : il s'agit du point d'accès pour effectuer l'authentification (exemple : https://fs.myenterprise.com/adfs/services/trust/13/windowsmixed). Le programme se base sur l'authentification windows. L'url “/trust/13/windowsmixed” doit être active sur l'infrastructure ADFS. Pour se faire, il faut se rendre dans la catégorie “Endpoints” de la console de gestion ADFS, puis effectuer un clic droit et choisir “Enable” sur cette url.

• certSubject : La valeur doit être celle du champ objet du certificat de type Token-Signing. Exemple : CN = ADFS Signing - fs.myenterprise.com.

Une fois l'outil paramétré, il suffit de le lancer l'exécutable. Ce dernier affiche toutes les revendications par un couple "Nom de la revendication : valeur". Voici un exemple de résultat obtenu :

On remarque qu'on obtient bien les deux revendications représentant le GUID, l'une le représentant sous forme d'une chaîne de caractère et l'autre encodé en base 64 (la revendication originale). Notre custom attribute store est donc bien opérationnel.

Si l'on souhaite ajouter de nouvelles transformations de revendications, il suffit maintenant d'ajouter des cas supplémentaires dans la classe et de la redéployer.

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

• Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

• Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

• Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

Sur les serveurs ADFS :

On récupère, le certificat en utilisant la commande suivante :

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

• Renouvellement manuel

• Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

• CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

• CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

• CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

• CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

• CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

Préambule

L'ensemble des manipulations ont été réalisées sur une infrastructure Windows 2012 R2 / ADFS 3.0.

Problématique

Avec quelques connaissances en développement web (CSS et Javascript), il est possible de customiser les pages de logon ADFS. On peut positionner un logo qui remplacera le nom de la federation ou encore changer l'illustration par défaut. De plus, Microsoft offre aussi la possibilité de changer une partie du code Javascript et CSS. Nous verrons donc comment gérer ses templates ADFS puis je détaillerai un script Javascript permettant d'ajouter automatiquement le suffixe UPN de l'utilisateur. Ainsi toute personne souhaitant se connecter n'aura qu'à entrer son samAccountName. Attention, cette méthode n'est fonctionnelle que dans le cas où tous les utilisateurs possèdent le même suffixe UPN.

Gestion des templates ADFS

Microsoft fourni quelques indications pour customiser les pages ADFS sur le lien suivant :
http://technet.microsoft.com/en-us/library/dn280950.aspx . On retrouve notamment les modifications les plus basiques comme les changements d'images ou de messages (erreur, aide,...).

Aussi, dans ADFS 3.0, il est possible de gérer plusieurs templates via les Cmdlets Powershell adéquates. Le template de base se nomme "default". On peut d'ailleurs récupérer la liste des thèmes avec la Cmdlet Get-ADFSWebTheme. On remarque qu'il s'agit bien du template de base grâce à l'attribut IsBuiltinTheme.

Les étapes de customisation d'un thème sont les suivantes :

• création d'un nouveau thème 
• export des fichiers du thème 
• modification des fichiers 
• import des fichiers modifiés dans le thème créé

Pour ajouter un nouveau thème il suffit d'utiliser la commande New-AdfsWebTheme en spécifiant le nom du thème ainsi que les sources du nouveau thème. En général, on se basera sur le thème par défaut que l'on customisera ultérieurement.

Il nous faut ensuite exporter les fichiers de ce thème (vers le dossier C:\ADFSTheme par exemple) :

Attention le dossier d'export doit exister (il ne sera pas généré automatiquement).

On remarque que l'on a accès à un certain nombre de fichiers mais pas à tous. En général, ceux que l'on voudra customiser sont le fichier onload.js et le fichier style.css.

Une fois modifiée, il ne reste plus qu'à importer le fichier dans le thème nommé custom. Un exemple avec le fichier onload.js :

Enfin pour définir le thème custom comme actif il faut utiliser la Cmdlet ci-dessous :

Ajout automatique du suffixe UPN

Afin de faciliter l'expérience utilisateur lors d'un usage en situation de mobilité ou via un navigateur ne supportant pas ADFS, il peut être utile d"ajouter automatiquement le suffixe UPN lorsque ce dernier a été omis dans le formulaire d'authentification. Pour les utilisateurs ne connaissant pas les notions de nom de domain Netbios ou d'UPN, cette customisation peut être interessante. Celle-ci nécessite du code Javascript.

ADFS se base sur la valeur entrée dans le champ “UserName” avec l’ID “userNameInput” du fomulaire. Il faut donc modifier cette valeur. Une autre solution (utilisée ici), consiste à changer l’ID et le nom du champ original. Puis, on ajoute un nouveau champ, invisible à l’utilisateur et contenant la bonne valeur ainsi que l’ID et le nom mentionné précédemment. Cette seconde solution est esthétiquement plus réussi (l’utilisateur ne voit pas le changement)

Ci-dessous, se trouve le script a ajouté à la fin du fichier onload.js est à intégrer dans le thème ADFS via la méthode vu précédemment :

Voici les opérations réalisées par le script lorsque le formulaire est valider (via la touche “Entrée” ou un clic sur le bouton de connexion) :

• Récupération du champ contenant l’identifiant utilisateur
• Vérification de la présence d’un suffixe UPN

Si le suffixe est manquant :

• On renomme le champ contenant l’identifiant utilisateur (UserName) et on change son ID (userNameInput).
• On ajoute un nouveau champ non visible portant les valeurs initiales (Id et nom). Il contiendra la valeur entrée par l’utilisateur avec le suffixe UPN. Celles-ci seront transmises à ADFS.

Une amélioration pourrait être d'ajouter une balise “select” contenant une liste de tous les suffixes UPN possibles. Cela permettrait de gérer les infrastructures utilisant de multiples suffixes UPN.