Contexte et Introduction

Après l’installation des 4 serveurs ADFS 3.0 lors de la migration 2.0 → 3.0, il y avait un problème avec le Relying Party  « Microsoft Office 365 Identity Platform » qui sert à authentifier les users sur O365.
Il utilise un custom attribute store qui n’est pas migré par le script de MS pour faire la migration et ce car cet attribut utilise une dll qui doit être compatible avec la nouvelle version de l’ADFS.

Cette documentation a pour but de montrer comment le problème a été résolu et comment le résoudre lorsqu’il y aura une migration vers une version supérieure de l’ADFS.

Solution

Lorsque nous copions la dll sur le nouveau serveur ADFS 3.0, il ne se chargeait pas et affichait cette erreur : 

During processing of the Federation Service configuration, the attribute store 'I2AAttributeStore' could not be loaded. Attribute store type: ID.SABA.Mailing.Exchange.ADFS.I2AAttributeStore, ID.SABA.Mailing.Exchange.ADFSUser ActionIf you are using a custom attribute store, verify that the custom attribute store is configured using AD FS Management snap-in.Additional DataCould not load file or assembly 'Microsoft.IdentityServer.ClaimsPolicy, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

La solution était d’avoir la DLL mais compatible avec cette version d’ADFS.
Dans l’erreur, nous pouvons lire que la version de la référence de l’assembly de la DLL n’était pas celle qu’il attendait.

Documentation de Microsoft

Microsoft fournit une documentation pour pouvoir compiler cette DLL pour un custom attribute mais celui-ci est générique et non pour notre cas.

Lien de la documentation : https://blogs.technet.microsoft.com/cloudpfe/2013/12/27/how-to-create-a-custom-attribute-store-for-active-directory-federation-services-3-0/

Dé-compilation de la DLL qui servait à ADFS 2.0

Pour savoir à quoi servait cette DLL et ne pas à avoir coder la dll de A à Z, nous avons utiliser l’outil ILSpy. Ce logiciel permet de dé-compiler tout logiciel développé en dotnet (C#, VB.NET…). Dans notre cas, nous avons pu dé-compiler la dll et mettre à jour la référence.

Lien pour télécharger ILSpy : https://github.com/icsharpcode/ILSpy/releases

File > Open > Ouvrir la dll en question (ADFS 2.0) récupéré au préalable.

Lorsque nous ouvrons ID.SABA.Mailing.Exchange.ADFS, nous verrons plusieurs namespaces.

Il faut garder ces namespaces, ils nous seront utiles lorsque nous devrons développer la DLL pour la refaire dans les règles ainsi que dans l’ajout de l’attribute dans ADFS.

Dans chacun des namespaces, nous pouvons voir une classe. La classe I2AAttributeStore sert à ADFS et la classe O365Log est appelé depuis la première classe.

En cliquant sur une classe, nous pouvons voir le code de la classe. 

Avec ça, nous avons tout pour pouvoir créer la nouvelle DLL compatible avec ADFS 3.0 !

Développement de la nouvelle version de la DLL

Pour ça, nous avons adapter la documentation de Microsoft à nos besoins.

Pour pouvoir coder et compiler la DLL, vous devez installer Visual Studio (pas la version Code).

Pré-requis :

Création du projet

File > New Project

Le nom du projet est le nom de la DLL soit ID.SABA.Mailing.Exchange.ADFS
On fait bien attention à la version de .NET Framework, je vous conseille de mettre le version 4.5 pour éviter tout problème de comptabilité vu que cette version est installé par défaut sur les versions de Windows datant de 2012.

Ajout de la référence

Browse > Sélectionner la DLL d’ADFS, c’est cette DLL qui avait besoin d’être à la dernière version, c’est pour ça que nous l’avons récupéré depuis ADFS 3.0 > Puis OK.

Ajout de l’accès à la référence

Clique droit sur « References » puis ajouter en faisant une recherche : 

System.IdentityModel est pour l’ADFS, System.Runtime.Serialization est utile à notre classe O365Log, sans elle, nous ne pourrons pas compiler car il y aura des erreurs.

Création des classes

Pour notre DLL, nous allons suivre la façon dont était faite la DLL que nous avons dé-compilé, soit de créer deux fichiers C-Sharp : 

  • I2AAttributeStore.cs
  • O365Log.cs

Comme suit :

Compilation de la DLL

Build > Build Solution

La DLL sera disponible dans le dossier bin\Debug situé dans le répertoire du projet Visual Studio (indiqué lorsque vous avez fait « nouveau projet ».

Ajout du Custom Attribute Store

Ensuite, vous allez avoir une fenêtre vous demandant les noms des classes.
Vous indiquerez :

ID.SABA.Mailing.Exchange.ADFS.I2AAttributeStore,ID.SABA.Mailing.Exchange.ADFS

Comme ci-dessous : 

Information supplémentaire : 

I2AAttributeStore -> Espace de nom : ID.SABA.Mailing.Exchange.ADFS
O365Log -> Espace de nom : ID.SABA.Mailing.Exchange.ADFS.Model

Conclusion

Voilà, maintenant, notre custom attribute fonctionne de nouveau sur la nouvelle version d’ADFS.


Alexy DA CRUZ

Administrateur systèmes depuis maintenant plus d'un an. Passionné par le développement, j'écris des articles sur mon portfolio.

0 commentaire

Laisser un commentaire