PI Services

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …) 

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompagny" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server)  vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration des Managements Agents AD et SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Lors de cette septième et dernière partie, je vais vous présenter le second type de DLL que l'on peut développer pour le service de Synchronization FIM. Il s'agit des règles d'extension de la métaverse. Celles-ci permettent de créer des objets dans le connector space lorsque celui-ci n'existe pas. Lors d'une opération d'export, ces nouveaux objets seront aussi créés dans le système connecté. Dans notre cas, la règle d'extension de la métaverse prendra en charge la création des comptes utilisateur n'existant pas dans l'annuaire Active Directory (provisioning). Comme pour le précédent article, je vais d'abord vous présenter comment créer ce type de projet depuis la console d'administration de FIM Synchronization Service puis les différentes méthodes que l'on peut configurer avant de terminer sur un exemple d'implémentation.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Création d'une règle d'extension de la métaverse

Comme pour les règles d'extension des Managements Agents, celle de la métaverse repose sur une DLL (nous utiliserons également le C# et Visual Studio pour la créer). Néanmoins, il n'est possible de créer qu'une seule règle d'extension de la métaverse par environnement de FIM Synchronization Service. Pour réaliser cette opération, il suffit de se rendre dans le menu Tools de la console de gestion de FIM Synchronization Service. Il faut ensuite cliquer sur Options.

Un assistant apparaît. Pour activer la règle d'extension de la métaverse, il faut cocher la case Enable metaverse rules extension. Il est ensuite nécessaire de définir le nom de la DLL. Cette dernière sera située dans le même répertoire que les règles d'extensions (par défaut C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions). Afin que le provisioning soit traité par la règle d'extension, il convient de cocher la case Enable Provisioning Rules Extension. Aussi comme dans l'article précédent, on peut générer le squelette de la règle d'extension (un projet Visual Studio) via le bouton Create Rules Extension Project.

NB : La case Enable Synchronization Rule Provisioning n'est pas utile dans cette série d'articles. Cette dernière permet de gérer le provisioning au travers de la syntaxe déclarative utilisée par FIM Service / Portal. Pour rappel cette dernière simplifie la customisation des flux de synchronisation en outrepassant la nécessité de réaliser le développement d'une DLL. Néanmoins, elle nécessite le déploiement de FIM Service et FIM Portal et donc l'achat des CALs associés.

Enfin, si vous créez le projet, vous retrouver le même assistant que dans la partie 6. Ce dernier vous demande les informations nécessaires à la création du projet Visual Studio. Ce dernier sera composé de plusieurs fichiers dont une classe (fichier avec l'extension .cs portant le nom de la règle d'extension) contenant différentes méthodes qu'il faudra compléter pour définir les règles de provisioning/deprovisioning.

Notions

Généralités

Contrairement aux règles d'extensions des Management Agent, il n'est pas possible de choisir quand une dll d'extension de la métaverse est appelée. En effet, celle-ci est automatiquement exécutée lorsqu'un objet de la métaverse est modifié. Cela peut intervenir lors des actions suivantes :

• Une règle d'import modifie un attribut d'un objet.
• Un objet d'un connector space réalise une jointure (manuelle via l'outil Joiner ou automatique).
• Un objet d'un connector space réalise une projection.
• Un objet d'un connector space  a été déconnecté alors que l'objet de la métaverse n'a pas été supprimé.
• Une synchronisation complète est exécutée.

Contrairement à une règle d'extension d'un Management Agent, la règle de provisioning n'intervient pas en fonction d'une configuration dans FIM.

Méthodes

Initialize et Terminate

Ces dernières fonctionnent de la même façon que dans les règles d'extension d'un Management Agent (veuillez-vous référer à la partie 6 : LIEN).

ShouldDeleteFromMV

Cette méthode contrôle le comportement de suppression d'un objet dans la métaverse. Cela correspond à la configuration que nous avons abordé lors de la partie 5 (Object Deletion Rule). Ainsi, si les choix disponibles via l'interface graphique ne vous conviennent pas, il est possible d'indiquer un comportement particulier pour décider de la suppression d'un objet de la métaverse.

Pour rappel, les règles de suppression d'objets se configurent pour chaque type d'objet. La fonction ShouldDeleteFromMV ne s'appliquera donc sur un objet que si vous activez la suppression via règle d'extension pour son type.

Provision

Provision est la méthode permettant de gérer notamment le provisioning / deprovisioning via la création d'un objet dans un connector space (ce dernier est ensuite créé dans le système connecté lors de la prochaine opération d'export).

Aussi, grâce à celle-ci il est possible d’effectuer d’autres opérations comme les déplacements d'objets.

Ordre d'application

Enfin, après avoir vu toutes les étapes de synchronisation au travers des différents articles, il est temps de faire un récapitulatif sur l'ordre d'application dans lequel elles interviennent. Lors d'une synchronisation, il existe deux phases :

1. Synchronisation entrante : depuis le connector space vers la métaverse
2. Synchronisation sortante : depuis la métaverse vers le connector space

Lors de la première étape, voici les règles qui s'appliquent :

1. Object Deletion rule
2. Conntor Filter rule
3. Join Rule
4. Projection rule
5. Import Attribute Flow rule

Durant la synchronisation sortante, l'ordre d'application est le suivant :

1. Provisioning rule
2. Deprovisioning Rule
3. Export Attribute flow rule

Exemple

NB : Pour cet exemple, j'intègre aussi l'implémentation de la méthode Initialize qui va être en charge de récupérer une configuration au travers d'un fichier XML. Ce dernier contient uniquement l'unité d'organisation dans laquelle les utilisateurs doivent être créés. 

L'objectif de cet exemple est de créer des utilisateurs dans l'annuaire Active Directory. Pour effectuer cette opération, il faut créer un nouveau connecteur dans le Management Agent Active Directory. Pour ce faire, on récupère les connecteurs existants liés à l'objet dans la métaverse (en spécifiant le nom du Management Agent concernés) :

Il suffit ensuite de s'assurer qu'il n'en existe aucun en les comptant.

La création d'un nouveau connecteur s'effectue avec la méthode StartNewConnector (voir la code complet ci-dessous) en indiquant le type d'objet à créer dans le connector space en paramètre.

Il est ensuite nécessaire de peupler les attributs de l'objet. Il faut notamment créer le distinguishedName de l'objet. Cela s'effectue en concaténant le common name avec l'emplacement dans l'annuaire Active Directory (récupéré via le fichier de configuration XML). Les méthodes Concat et EscapeDNComponent sont ici utilisées pour la concaténation des chaînes et la transformation de celles-ci en type ReferenceValue.

Enfin, on peut sauvegarder le nouveau connecteur avec la méthode CommitNewConnector. Il est à noter que cette logique a été incluse dans une boucle incrémentant le common name avec un chiffre si un objet du même nom existe déjà dans l'unité d'organisation indiquée (une erreur du type ObjectAlreadyExistsException est alors retournée).

Voici le code complet de la règle d'extension de la métaverse :

Enfin, on remarque qu'il est possible de procéder au déplacement d'un objet dans l'annuaire Active Directory en changeant la valeur de l'attribut DN. Cette opération peut s'effectuer lorsqu'on détecte un connecteur existant.

Conclusion

De nombreuses personnalisations sont possibles au travers des règles d'extensions. Elle permettent de gérer tout les cas qui ne le sont pas au travers de l'interface graphique. De nombreux aspects de FIM Synchronization Service ont été abordés durant cette série d'articles. Néanmoins, il est possible de mettre en œuvre de nombreuses autres configurations en fonction du type de Management Agent déployé (et donc des sources de données) ainsi que des personnalisations à effectuer sur ceux-ci.

Contexte

Le problème décrit ci-dessous a été rencontré dans le cadre d'une infrastructure DirectAccess sous Windows Server 2012 R2. Celui-ci peut se produire lorsque l'authentification forte (par carte à puce ou OTP) est activée avec des clients Windows 7.

Problème rencontré

Lorsque des lecteurs réseaux sont montés à l'ouverture de la session, cela peut empêcher cette dernière de s'ouvrir correctement et laisser l'utilisateur bloqué sur la page de “Bienvenue” pendant plusieurs minutes voir plusieurs dizaines de minutes.

Analyse

Pour rappel, la connectivité DirectAccess est composée de deux tunnels :

• Le tunnel infrastructure utilisé notamment pour l'authentification et les stratégies de groupes.
• Le tunnel utilisateur qui permet d'accéder à des ressources d'entreprise (partages, applications, site web) en fonction des autorisations de la personne connectée.

Ce problème est une conséquence de l'activation de l'authentification forte. En effet, tant que cette dernière n'a pas eu lieu, le tunnel utilisateur n’est pas créé. Les lecteurs réseaux étant des ressources liés à l’utilisateur, elles sont accédées par ce tunnel. Le système d’exploitation tente de monter les lecteurs réseaux et il faut attendre un timeout de cette opération avant que la session ne s’ouvre.

Solution

Toutes les solutions présentées ici sont des contournements permettant d'éviter le problème mais présentant toutes des inconvénients (à voir selon le cas, celle qui est le plus acceptable pour vous).

1/ Authentification forte pendant l'ouverture de session

Demander l’authentification forte lors de l’ouverture de session permet de déclencher la création du tunnel utilisateur. Ainsi, les lecteurs réseaux peuvent être montés. Cependant, cette méthode implique deux inconvénients :

• Elle ne fonctionne que lorsque la méthode d’authentification forte utilisée est la carte à puce. En cas d’usage d’un OTP, cela ne peut être opérationnelle puisque DirectAccess à un processus propre pour gérer ce type d’authentification décorrélé de celui de l’ouverture de session. Pour plus d’informations, je vous invite à lire cet article : https://blog.piservices.fr/post/2015/11/23/DirectAccess-Deploiement-de-lauthentification-forte
• L’utilisateur est obligé de s’authentifier sur son poste client avec l’authentification. Cela dégrade l’expérience utilisateur lorsque l’on se trouve en entreprise et qu’on ne souhaite donc pas utiliser DirecAccess.

2/ Logon Script

Les lecteurs réseaux sont parfois mappés par un script s'exécutant après l'ouverture de session (logon script). Pour que cette solution soit fonctionnelle, il suffit d'intégrer un test vérifiant que la connectivité DirectAccess est montée et de boucler dessus tant que ce n'est pas le cas. Cela peut être fait en validant l'accès à une ressource d'entreprise comme un partage ou l'url du serveur NLS de DirectAccess. Cependant cette solution présente l'inconvénient de devoir parfois laisser un script tourner continuellement.

3/ Management servers

L’une des autres possibilités est d’ajouter les serveurs de fichiers utilisés par ces lecteurs réseaux dans la liste des serveurs de management. Ainsi, l’accès à ceux-ci se fait via le tunnel infrastructure qui ne nécessite pas d’authentification forte et qui est monté dès le démarrage de l’ordinateur avant l’ouverture de session (si une connexion à internet est disponible). Cependant, cette méthode est contraire à la volonté de sécuriser les accès aux ressources d’entreprise avec de l���authentification forte. En effet, si l’utilisateur ouvre une session, il pourra accéder aux serveurs de fichiers sans authentification forte et par rebond à d’autres serveurs. Cette solution affaiblit donc la sécurité de l’infrastructure.

Si toutefois vous souhaitez implémenter cette solution, il suffit de lancer la console de gestion DirectAccess et de se rendre dans la configuration du serveur ou du cluster via le menu éponyme. Ensuite, il faut cliquer sur le bouton “Edit” de l’étape 3 de l’assistant de configuration.

Dans l’onglet “Management”, il faut indiquer les noms DNS des serveurs de fichiers (les IP ne peuvent être indiquées que si vos serveurs communiquent en IPv6). Vous pouvez ensuite cliquer sur le bouton “Finish”.

N’oubliez pas de mettre à jour les stratégies de groupe en cliquant sur le bandeau qui apparait en bas de la console de gestion DirectAccess. Enfin, il faut récupérer cette nouvelle version des GPOs DirectAccess sur vos postes clients (via la commande “gpupdate” par exemple).

4/ Déclenchement de la connectivité DirectAccess après le logon

Le démarrage d'un des services requis pour la connectivité DirectAccess après l'ouverture de session permet de corriger le phénomène. Le service IP Helper (iphlpsvc) permettant notamment de générer les interfaces de transitions IPv4/IPv6 est l'un deux. En effet, aucun tunnel dédié à DirectAccess n'existera tant que ce service n'est pas démarré. Ainsi, le client ne tentera pas de monter les lecteurs réseaux. Néanmoins, via cette méthode, le tunnel infrastructure n'existe pas non plus tant que l'utilisateur n'est pas connecté. Ainsi, un utilisateur qui se connecte pour la première fois sur un ordinateur ne pourra le faire via DirectAccess. Aussi, les patchs ne pourront être récupérés et les stratégies de groupes ne seront pas mises à jour tant qu'un utilisateur n'a pas ouvert de session. Si toutefois vous souhaitez réaliser cette manipulation, il suffit de créer une stratégie de groupe avec les paramètres ci-dessous.

Dans “Computer Configuration / Preferences / Services”, il faut changer le mode de démarrage du service IP Helper afin qu'il démarre manuellement.

Dans “Configuration / Preferences / Scheduled Tasks”, il faut créer une tâche planifiée lancée par le compte “SYSTEM”.

On définit l'exécution de celle-ci à l'ouverture de session.

Enfin, on indique qu'il faut lancer le service IP Helper via la commande “net start”.

Aussi, il est nécessaire de gérer le cas d'un utilisateur qui ferme sa session afin de ne pas rencontrer le problème lors de la prochaine ouverture de session. Pour cela, il faut créer une seconde tâche se déclenchant à la fermeture de session.

Celle-ci est quasiment identique en dehors de la commande exécutée (“net stop”) et du déclencheur. Ce dernier est paramétré pour détecter l'événement 4647 du journal d'événements Sécurité. Celui-ci correspond à une demande de fermeture de session par l'utilisateur.

Enfin, cet évènement n'est pas généré par défaut. Pour l'obtenir, il faut activer l'audit sur la catégorie “Logoff”. Cette opération s'effectue par stratégie de groupe dans “Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies”.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration des Managements Agents AD et SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Durant la configuration des Managements Agents, j'ai évoqué plusieurs configurations pouvant être personnalisées via du développement. Malgré que cela puisse paraître compliqué, il n'est pas nécessaire de posséder de très grandes compétences en développement pour réaliser ce type d'implémentation. Le langage utilisé est le VB.Net ou le C#. Dans cet article j'utiliserai le C#. J'expliquerai comment créer une règle d'extension à partir de FIM, les notions liées à FIM pour le développement de celles-ci, ainsi qu'un exemple concret avec une règle simple réalisant une transformation d'un attribut lors d'un d'import. Pour réaliser ce guide, il est nécessaire de posséder Visual Studio (en version 2008 ou supérieure).

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Ajout d'une règle d'extension

Avant de créer le projet Visual Studio est de développer nos règles personnalisés, il faut les ajouter au sein du Management Agent. Prenons l'exemple d'une règle standardisant le formatage du prénom des objets de type person. Celle-ci permettra d'avoir tous les prénoms avec la première lettre de chaque mot en majuscule et le reste en minuscule. Pour ce faire, il est nécessaire d'éditer le flux d'attribut du Management Agent. Dans cet article, nous allons effectuer cette modification lors de l'import des données dans la métaverse (dans le Management Agent SQL). Toutefois, cela aurait aussi été possible pendant l'export des données dans l'annuaire Active Directory et donc dans le Management associé (à la différence que la transformation ne sera pas visible dans la métaverse).

Le changement de flux d'attribut consiste à définir le type à Advanced au lieu de Direct.

Un panel s'ouvre. Il faut alors choisir le type Rule Extension. Le nom associé peut être customisé. Il sera utilisé lors du développement pour identifier les actions qui seront associées.

Enfin, il convient de définir le nom de la DLL dans l'onglet Configure Extensions. Ces dernières sont contenues dans l'arborescence 2010\Synchronization Service\Extensions du dossier d'installation de FIM Synchronisation Service (par défaut C:\Program Files\Microsoft Forefront Identity Manager\).

Attention, lorsque cette configuration est appliquée, le Management Agent n'est plus fonctionnelle tant que la DLL n'a pas été créée. De plus, le flux d'import échouera si la méthode permettant de traiter cette règle avancée n'a pas été implémentée dans la DLL.

Création du projet Visual Studio

Les règles d'extensions reposent sur une DLL que l'on peut générer à partir de Visual Studio. Aussi, FIM Synchronisation Service inclus des options permettant de simplifier le développement de celles-ci. Ainsi, il va être possible de générer un projet et l'intégralité du squelette C# ou VB.Net. Ce dernier contient toutes les règles de personnalisation qu'il convient ou nous de compléter en fonction de ses besoins. Il ne restera plus qu'à compléter le projet. Une méthode C# correspond à chaque personnalisation possible (c’est-à-dire à chaque endroit dans la configuration du Management Agent où l'on peut indiquer une règle d'extension). Nous reviendrons sur les possibilités offertes par chaque méthode dans le chapitre suivant. Si les règles à intégrer sont simples, il ne faudra alors que quelques lignes pour mettre en place ce type de configuration (c'est ce que nous verrons dans l'exemple décrit en fin d'article).

Par convention, une dll d'extension est attribuée à un Management Agent à la fois. Celle-ci contiendra donc toutes les règles de personnalisation d'un Management Agent. Pour créer une nouvelle règle d'extension. Il est nécessaire de se rendre dans l'onglet Management Agent, de sélectionner le Management Agent pour lequel on souhaite développer une règle d'extension puis de cliquer sur le menu Actions et enfin de cliquer sur Rules Extension dans Create Extension Projects.

Un assistant permet de définir le langage, la version de Visual Studio, le nom du projet et l'emplacement où il sera stocké. A noter que si vous utiliser une version supérieure à Visual Studio 2012, vous pouvez indiquer cette dernière comme version cible. Aussi, en cochant la case Launch in VS.Net IDE, vous avez la possibilité d'ouvrir directement le projet dans Visual Studio. Cette option ne sera fonctionnelle que si Visual Studio est installé sur le même serveur que FIM Synchronisation Service. Cette implémentation est en général envisageable lorsque l'on travaille sur un serveur de développement. Il suffira ensuite d'exporter le Management Agent et la DLL sur le serveur de production.

Lorsque le projet est ouvert, on constate que l'arborescence reste simple. Le fichier qui nous intéresse est celui avec l'extension .cs portant le nom de la règle d'extension. Le développement à réaliser ne concernera que la modification de ce fichier.

Lorsque vous générer la solution via le menu Build, la DLL est automatiquement placée dans le répertoire adéquat de FIM Synchronisation Service.

Notions

Les méthodes

En dehors des méthodes initialize et terminate qui ne s'exécute qu'une seule fois par exécution d'un Management Agent, les autres méthodes sont appelées pour chaque objet qui est traité lorsqu'il satisfait une configuration appelant une règle d'extension (la règle de flux d'import par exemple). Chaque méthode ne peut donc modifier qu'un objet d'un connector space ou de la métaverse à la fois.

Initialize

Cette méthode est exécutée la première fois qu'une règle d'extension est appelée lors de l'exécution d'un Management Agent. Elle permet de gérer un code d'initialisation du Management Agent comme le chargement de paramètres via un fichier XML (exemple : des paramètres de logging, une ouverture de connexion à une base de données).

Terminate

Contrairement à la première méthode, celle-ci est appelée lorsqu'aucune règle d'extension n'a été exécutée depuis 5 minutes (FIM considère alors que la synchronization est terminée). Celle-ci est utilisée pour libérer des ressources qui auraient pu être instanciées pendant la méthode initialize (exemple : clore la connexion à une base de données).

ShouldProjectToMV

Il s'agit d'une méthode influant le comportement des règles de projection. En temps normal, si aucune règle de jointure ne permet de créer un connecteur alors un objet d'un connector space est créé si une règle de projection a été défini. Lorsque cette dernière est configurée pour utiliser une règle d'extension alors on peut utiliser cette méthode pour traiter des cas particulier. En effet, le retour de cette méthode définit si l'objet doit être projeter dans la métaverse ou non.

Deprovision

La méthode Deprovision est en charge de définir l'action de deprovisioning lorsqu'un objet d'un connector space est déconnecté suite à la suppression de son équivalent dans la métaverse. Au lieu de définir une seule action possible comme nous l'avions vu dans les articles sur la configuration des Management Agent, on peut choisir de calculer cette action en fonction de paramètres spécifiques. Les actions possibles restent les mêmes :

• Déconnexion (l'objet peut être reconnecté s'il satisfait une règle de jointure ou une règle de projection)
• Déconnexion explicite (l'objet ne peut être reconnecté automatiquement, il faut alors utiliser l'onglet Joiner)
• Suppression (dans le connector space puis sur le système connecté lors du prochain export)

FilterForDisconnection

Cette méthode permet de définir un filtre personnalisé pour exclure des objets du connector space d'être synchronisé. Cela correspond à la règle d'extension que l'on peut configurer dans l'onglet Configure Connector Filter.

MapAttributesForJoin

MapAttributesForJoin offre la possibilité d'ajouter des valeurs calculés pour effectuer une jointure. Cette dernière retourne une collection d'attributs présent sur l'objet du connector space ou ajoutées par cette fonction.

ResolveJoinSearch

Grâce à cette méthode, il est possible d'affiner la résolution d'une jointure lorsque des règles directes ne peuvent pas faire correspondre un objet d'un connector space avec un objet de la metaverse. En effet, il est ainsi possible d'éviter le cas où plusieurs objets de la metaverse correspondent.

MapAttributesForImport

et

MapAttributesForExport

Il s'agit des méthodes permettant de gérer les flux d'attributs entre la metaverse et le connector space (et à fortiori le système connecté). La première est en charge des modifications d'attributs lors des opérations d'import (connector space vers metaverse) tandis que la seconde est utile pour les opérations d'export. Grâce à elles, il est possible de transformer des attributs. On peut aussi utiliser plusieurs attributs en entrée pour calculer la valeur d'un attribut en sortie. La méthode MapAttributesForImport ne permet de modifier qu'un objet de la métaverse (l'objet correpondant dans le connector space n'est accessible qu'en lecture) et vice versa pour la méthode MapAttributesForExport.

NB : Par défaut, toutes les méthodes possèdent la ligne de code ci-dessous :

Celle-ci signifie qu'aucun traitement n'a été implémenté. Néanmoins, il n'est pas nécessaire de changer ce comportement pour les méthodes qui ne seront jamais appelées par le Management Agent.

Les variables

csentry

Cette variable correspond à l'objet au sein du connector space en cours d'accès.

mventry

Cette variable correspond à l'objet au sein de la métaverse en cours d'accès.

flowRuleName

Il s'agit du nom de la règle qui a été défini dans le Mangement Agent. En effet, la dll contient toutes les règles d'extension. Par exemple, si nous définissons plusieurs règles avancées d'import lors du flux d'attribut, le code associé pour celles-ci sera inclus au sein de la méthode MapAttributesForImport. Cette variable permet ainsi de savoir qu'elle règle a été appelée pour exécutée le bon traitement. La convention est d'utiliser une structure algorithmique de type switch sur la valeur de cette variable pour différencier les règles d'extensions (nous verrons cette structure dans le paragraphe suivant).

Exemple de règle d'import

Le but de cet exemple simple et de montrer le code nécessaire à la standardisation du format de l'attribut firstname comme nous l'avons vu au début de cet article lors de la configuration de la règle d'extension.

Astuce : Si vous ajouter toutes vos règles d'extension dans la configuration du Management Agent avant de créer le projet Visual Studio alors la structure algorithmique contenant les différents nom de règles est pré générée. Cela facilite encore plus le développement.

Vous trouverez ci-dessous la fonction MapAttributesForImport complète. On remarque qu'un test est effectué afin de savoir si l'objet du connector space possède une valeur pour l'attribut firstname. Si tel est le cas, la valeur est récupérée(grâce à la variable csentry) via la propriété value. Elle est ensuite formatée (première lettre de chaque mot en majuscule) puis affectée à l'objet correspondant dans la métaverse (via la variable mventry) Le cas par défaut remonte une erreur d'implémentation si aucune règle porte le bon nom de la structure de type switch :

Il ne reste plus qu'à compiler la solution via le menu Build afin que la dll soit générée dans le répertoire adéquat. Cet exemple se veut simple mais il est possible d'imaginer des cas de personnalisations beaucoup plus complexes ou faisant intervenir d'autres types de configuration (filtrage, jointure, …) via les autres méthodes disponibles.

NB : Même si cette possibilité n'a pas été utilisée dans cet exemple, une méthode permet de rechercher des objets dans la métaverse. Ces derniers ne sont toutefois accessibles qu'en lecture. Néanmoins cela peut être utile pour consolider des informations dans l'objet en cours de traitement (le manager d'un employé par exemple). L'une des façons les plus simples de l'utiliser correspond à l'exemple ci-après :

Le premier paramètre est le nom de l'attribut sur lequel la recherche est effectuée (quelque soit le type d'objet) tandis que le second correspond à la valeur attendue. Il est fortement recommandé d'effectuer cette recherche sur des attributs indexés afin d'optimiser le temps de traitement.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …) 

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server)  vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration des Managements Agents AD et SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Lors de cette cinquième partie, je vais évoquer l'administration du service de synchronisation de FIM avec d'une part l'administration des Managements Agents et d'autre part la gestion de la métaverse. Pour cette dernière, nous verrons notamment comment ajouter des attributs ou même créer des objets afin de ne pas se limiter à ceux par défaut. Enfin, nous aborderons la gestion du cycle de vie des objets dans la métaverse et les différentes configurations possibles.  

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Administration

Vérification du résultat d'une synchronisation

Dans l'article précèdent, nous avons vu comment créer des profils de synchronisation. Lorsque ces derniers sont exécutés, nous pouvons accéder au détail des actions effectués dans l'onglet Operations de la console de gestion de FIM Synchronization Service. Ainsi, dans l'exécution ci-dessous, on remarque que quatre objets n'ont pas été modifiés lors de l'import dans le connector space Active Directory tandis que trois ont été projetés dans la métaverse pendant la phase de synchronisation (un objet a été filtré). Il est aussi possible d'avoir le listing de ses objets en cliquant sur le chiffre indiquant le nombre de changement. Ainsi, il est possible à chaque étape d'avoir un véritable contrôle des modification.

Recherche dans la metaverse

Il est possible de vérifier l'état d'un objet dans la métaverse. Pour ce faire, il suffit de se rendre dans l'onglet Metaverse Search. Ensuite, il faut indiquer un filtre. Ce dernier est composé :

• Du type d'objet à rechercher.

• D'une ou plusieurs conditions contenant des valeurs attendus pour les attributs de l'objet.

Un clic sur le bouton Search permet de lancer la recherche.

Lorsque l'on ouvre les propriétés d'un objet retourné lors de la recherche, tous ses attributs sont affichés. On remarque également la date de dernière modification de ceux-ci ainsi que le Management Agent ayant écrit cette valeur (utile dans le cas de plusieurs Management Agent contribuant à un même objet dans la métaverse).

Enfin, dans l'onglet Connectors d'un objet, on accède à tous les connecteurs de l'objet. Ci-dessous on remarque le connecteur avec le référentiel SQL. Ce dernier a été créé avec une règle de projection. Lorsqu'un import et une synchronisation auront lieu avec le Management Agent Active Directory, un deuxième connecteur avec une règle de jointure sera présent.

Recherche dans un connector space

Il est aussi possible de rechercher des objets dans un connector space via le bouton Search Connector Space présent dans le menu des actions de chaque Management Agent.

La recherche est cette fois-ci moins simple puisqu'il n'est possible de faire une recherche qu'au travers du DN (pour rappel, dans le Management Agent SQL que nous avons configuré précédemment, il s'agit de l'id) ou d’une partie de celui-ci (l’unité d’organisation pour un objet Active Directory par exemple).

Comme pour les objets présents dans la métaverse, il est possible de voir leurs propriétés via l'onglet Import. L'onglet Lineage permet d'accéder à son status (si l'objet est connecté ou non à la métaverse). Ici, j'ai ouvert la fiche de l'objet dmills qui est un travailleur détaché. Pour rappel, dans note exemple, ces derniers ne doivent pas être synchronisés, c'est pourquoi il apparaît en tant que filtered disconnector.

Enfin sur chacun des onglets d'un objet,  un bouton Preview est présent. Ce dernier fourni un outil pour pré visualiser les changements lors d'une synchronisation complète (Full) ou incrémentielle (Delta). Cet outil est utile pour effectuer des tests. Si les résultats sont ceux attendus, il est même possible de les enregistrer avec le bouton Commit Preview. Ainsi, il n'est pas nécessaire de relancer un profil d'exécution de synchronisation.

Grâce aux outils que nous venons de voir (onglet Operations, recherche dans la metaverse et dans un connector space, outil de prévisualisation), il est possible de connaitre à chaque instant l'état d'un objet et d'identifier rapidement les erreurs de configuration.

Export / import d'un Management Agent

Dans l'onglet Management Agent, il est possible d'exporter ou d'importer un Management Agent. Ces opérations offrent plusieurs possibilités :

• Sauvegarde / Restauration : Cela permet de conserver les paramètres de configuration d'un Management Agent et de les réinjecter en cas d'une erreur de configuration.
• Migration / Passage en production : La configuration d'un Management Agent peut être transférer d'un serveur à un autre lorsque ce dernier est changé ou lorsque l'on possède plusieurs environnement et que l'on souhaite transférer la configuration à l'identique d'un environnement à un autre (exemple : du développement à la production).  Il reste alors simplement à insérer les paramètres de production (comme le domaine, le compte de service ou encore les unités d'organisation d'un Management Agent Active Directory). Attention : lorsqu'un Management Agent est importer d'un serveur à un autre, il est nécessaire de copier les DLL déclarées. Ces dernières ne sont pas inclues dans l'export.

NB : Lorsqu'un Management Agent est modifié, il est nécessaire de déclencher une opération de Full Import afin de prendre en compte les nouvelles règles pour tous les objets du connector space. 

Gestion de la metaverse

La métaverse est le point central des données de l'environnement FIM Synchronization Service. Chaque objet d'un connector space qui possède un connector est lié à un objet de la métaverse. Pour rappel, un objet de la métaverse peut avoir plusieurs connectors. En effet, ces différentes propriétés peuvent être alimentés par plusieurs systèmes connectés comme c'est le cas pour la société "MyCompany". Chaque objet de type person est connecté à un collaborateur du référentiel SQL et un utilisateur Active Directory. Aussi, un certain nombre de propriétés sont paramétrable sur la métaverse, son fonctionnement et les objets qui la compose. Toutes ces actions se déroulent dans l'onglet Metaverse Designer de la console de gestion de FIM Synchronization Service.

Modification d'objets

Pour chaque objet, il est possible de les modifier en ajoutant ou supprimant des attributs. Cela permet de synchroniser des informations complémentaires. Pour ce faire, il suffit de sélectionner le type d'objet puis de cliquer sur le bouton Add Attribute dans le panel Actions (en bas à droite). Une fenêtre listant tous les attributs disponibles s'ouvre. Elle contient tous les attributs déjà déclarés dans la métaverse. Pour en ajouter un à un objet, il suffit de cocher la case de l'attribut concerné.

Aussi, si ce dernier n'existe pas dans la liste, il peut être créé via le bouton New Attribute. Grâce à cette option, pour la société "MyCompany", on peut ajouter la propriété Status permettant de synchroniser cette valeur contenue dans le référentiel SQL vers la métaverse (il faut aussi ajouter une règle de flux d'attribut dans le Management Agent SQL et éventuellement dans le Management Agent Active Directory si l'on souhaite exporter cette valeur vers cet annuaire).

Lorsque l'on ajoute un nouvel attribut, il existe plusieurs possibilités. Tout d'abord un objet être de plusieurs types :

• Chaîne de caractère (String)
• Valeur binaire (Binary)
• Nombre (Number)
• Bouléen (Boolean)
• Référence (Reference)

Les types chaîne de caractère, binaire et nombre peuvent être indexés ou non en cochant la case Indexed. Cela permet d'optimiser les recherches d'objets sur ces attributs. A noter qu'une bonne pratique est d'indexer tous les champs sur lesquels une jointure peut être effectuée afin d'optimiser l'opération de recherche d'un objet correspondant dans la métaverse. Aussi, en dehors du champ Boolean, tous les attributs peuvent être multi-évalué et donc contenir une liste de valeurs (exemple : le champs userCertificate d'Active Directory qui contient tous les certificats d'un utilisateur). Enfin, le type Reference permet d'indiquer une référence vers un autre objet de la métaverse. Cela peut notamment être utilisé dans le cadre de la synchronisation du manager d'une personne ou encore de la liste des membres d'un groupe.

Création d'objets

En complément de la modification d'objet, il est aussi possible d'en ajouter de nouveaux au travers de l'onglet Metaverse Designer. Cela permet de gérer d'autres types d'objets que vous aurez conçu vous-même comme les contacts. Pour créer un objet, il suffit de cliquer sur Create Object Type dans le menu Actions. 

NB : L'action Copy Object Type, permet de dupliquer un type d'objet ainsi que ses propriétés (le type sélectionné sert alors de modèle).

Ensuite, il faut entrer le type d'objet à créer et éventuellement ajouter les attributs qui le caractérise (comme nous l'avons vu dans le paragraphe précédent, cela peut être modifié ultérieurement).

Flux d'attributs

Lorsque plusieurs systèmes connectés interagissent avec le même attribut, il est possible de choisir celui qui aura la priorité pour en définir la valeur. Cette opération s'effectue en sélectionnant un attribut sur l'un des types d'objet déclarés dans l'onglet Metaverse Designer puis en cliquant sur le bouton Configure Attribute Flow Precedence (on remarque dans l'exemple ci-dessous que l'attribut accountName possède deux règles d'import, il faut donc déterminer l'ordre d'application).

L'assistant qui s'ouvre montre les Management Agents qui ont une règle de flux avec l'attribut sélectionné. La configuration par défaut indique que le premier Management Agent synchronisant une valeur (par ordre croissant) est autoritaire. Ainsi dans l'exemple ci-dessous le Management Agent Active Directory MA est prioritaire. RefIdentité MA ne sera utilisé pour cet attribut que si aucune valeur n'est fournie par l'autre Management Agent. Ainsi, même si une nouvelle valeur est transmises par le Management Agent RefIdentité MA, elle ne sera pas prise en compte. Il est possible de changer cet ordre avec les flèches présentes dans l'assistant.

NB : Dans cet exemple, un changement de nom de compte impliquerai de déconnecté un objet puisque l'attribut samAccountName est utilisé pour la jointure de l'objet auprès de la Métaverse.

Aussi deux options sont disponibles pour ce paramétrage :

• Use manual precedence : Il est possible de définir la priorité d'un Management Agent manuellement. Cela n'est possible que pour les règles de flux personnalisées (type Rules Extension) qui ont été développés en C# ou VB.Net.
• Use equal precedence : Chaque Management bénéficie d'une priorité identique. Ainsi, s'il s'agit d'un attribut possédant une valeur unique, le dernier Management Agent qui s'est exécuté contribue à la valeur dans la métaverse (cela peut donc provoquer des effets de bord avec des changements à chaque exécution de Management Agent). Dans le cas où l'attribut est une liste de valeur, FIM réalise une fusion des différentes valeurs.

Déprovisioning

Par défaut, un objet présent dans la métaverse est supprimé lorsqu'il n'a plus aucun connecteur avec un Management Agent. Cependant, ce comportement peut être modifié. Cela s'effectue via le bouton Object Deletion Rule présent dans la configuration de chaque type d'objet de la métaverse.

Pour l'option par défaut, on remarque qu'il existe une liste de tous les Management Agent. En effet, il est possible d'ignorer certains Management Agent en les cochant. Ainsi lorsque la règle sera évaluée, elle ne prendra pas en compte les connector space des Management Agent sélectionnés pour savoir si l'objet doit être supprimé.

La seconde option (Delete the metaverse object when the last connector space object from a specified management agent is disconnected), consiste à supprimer l'objet dès qu'il n'y a plus de lien avec l'un des connector space. Contrairement à la première option, la liste de Management Agent permet ici de définir les connector space associés qui seront utilisés pour évaluer la suppression.

Enfin, la dernière option offre la possibilité de gérer la suppression d'un objet de la métaverse au travers d'une règle développée en C# ou VB.Net. Cela permet de gérer des cas plus spécifiques.

Joiner

L'outil Joiner est un outil intégré dans la console de gestion de FIM 2010 Synchronization Service consacré à la manipulation des disconnectors d'un Management Agent. Ainsi, il est possible de traiter ces objets afin de les connecter à la métaverse via une projection ou une jointure ou de les écarter définitivement via un disconnector explicite. Toutes ces opérations sont manuelles. 

Pour effectuer une opération sur un objet dans l'onglet Joiner, il suffit d'effectuer une recherche par Management Agent en le sélectionnant dans le champ adéquat puis en cliquant sur le bouton Search (avant cela il est possible de réaliser un filtre plus spécifique en choisissant un type de disconnector).  

Le type de Disconnector peut être changé lorsqu'on sélectionne un objet puis que l'on clique sur le bouton Set Disconnector Type. Par exemple, on peut souhaitez qu'un objet ne soit plus traiter par le Management Agent et qu'il soit définitivement écarté de tout traitement. Il faut alors définir un Explicit Disconnector. Aussi, même si l'objet satisfait toutes les règles de filtrages ultérieurement, il ne sera pas synchronisé tant que le Disconnector sera de type explicite. Il faudra tout d'abord rechanger ce dernier via une nouvelle opération dans l'onglet Joiner.

Lorsqu'un objet est sélectionné, il est possible de le joindre à un objet de la métaverse. Pour ce faire, il est nécessaire de réaliser une recherche sur celle-ci afin de trouver l'objet correspondant. Cette opération est réalisée en créant un filtre avec le bouton Configure Search Filter. Un assistant s'ouvre alors et il est nécessaire de cliquer sur le bouton Add pour ajouter un filtre.

Ce dernier peut rechercher des objets en fonction du type ainsi qu'en fonction d'une valeur sur un attribut. 

Le bouton Apply Filter déclenche la recherche. La jointure s'effectue en cliquant sur le bouton Join après avoir sélectionné un objet de la métaverse (un avertissement permet de confirmer l'opération). Toutefois, il reste aussi possible d'effectuer une projection (bouton Project) sans passer par le filtrage si l'objet n'existe pas dans la métaverse. Les opérations effectuées dans l'onglet Joiner n'ont pas besoin de respecter les filtres configurés dans le Management Agent gérant l'objet traité.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service de Forefront Identity Manager qui répond à un grand nombre de ces problématiques. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration du Management Agent SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Dans ce quatrième article, j'aborderai la configuration du second Management Agent de notre étude de cas. Ce dernier nous permettra de synchroniser les objets Active Directory. Aussi, nous verrons également la notion de profil d'exécution. Ces derniers vont nous permettre de lancer nos tâches de synchronisation et même de les planifier.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Configuration du management Agent Active Directory

Dans l'article précédent nous avons vu la configuration d'un Management Agent. Pour la plupart d'entre eux, les onglets suivants sont identiques :

• Configure Connector Filter
• Configure Join and Projection Rules
• Configure Attribute Flow
• Configure Deprovisioning
• Configure Extensions

En effet, pour chaque Management Agent, la partie qui change est celle consacrée à l'accès aux données. Les autres sections permettent d'interagir avec les données présentes dans le connector space ou dans la metaverse.

Prérequis

Afin de synchroniser des informations avec un annuaire Active Directory, il est nécessaire d'avoir un compte de service permettant de le lire. Pour que ce dernier support les opérations de type delta (afin de ne traiter que les changements depuis la dernière synchronisation), il est nécessaire d'ajouter la permission Replicate directory changes au compte de service. Cette dernière s'ajoute au niveau du domaine.

Ce compte sera également utilisé pour répliquer les éventuels changements sur un objet depuis la métaverse. Ce dernier devra donc avoir des droits d'écriture sur les objets et même éventuellement de création / suppression si l'on souhaite mettre en place du provisioning. Il est d'ailleurs recommandé d'ajouter les permissions au fur et à mesure des besoins en donnant les droits au compte de service sur les unités d'organisation à traiter. Il faut aussi éviter d'insérer un compte avec des droits importants comme un compte membre du groupe Administrateurs du domaine.

Création du management Agent

Lors de la création du Management Agent (pour rappel, elle s'effectue via le bouton Create), on choisit le type Active Directory Domain Services, puis on le nomme et on ajoute éventuellement une description.

La section suivante permet d'indiquer le nom de la forêt Active Directory ainsi que le compte de service qui sera utilisé pour lire les informations dans l'annuaire.

Il est ensuite possible de spécifier les différentes partitions de domaine qui seront accédées par FIM. Dans le cas d'une forêt mono domaine vous n'aurez ici qu'un seul choix possible (il est néanmoins possible d'accéder aux autres partitions de l'annuaire via le bouton Show All mais cela n'est pas utile). Il est ainsi possible de réaliser un filtrage sur le domaine à synchroniser.

La section Domain Controller connection settings permet de définir, si besoin, une liste de contrôleur de domaine à utiliser. Cette opération s'effectue avec le bouton Configure tout en prenant soin de cocher la case Only use preferred domain controllers si on ne souhaite utiliser que cette liste. Il est également possible de définir des identifiants d'accès différents. Aussi, la section Password Synchronization peut être utilisé dans le cas d'une synchronisation du mot de passe Active Directory vers la métaverse afin de le répliquer sur d'autres applications. Cela nécessite une implémentation spécifique qui ne sera pas abordée dans cette série d'articles.

Le bouton Containers permet de sélectionner les unités d'organisation ou container que vous souhaitez synchroniser. Il s'agit ici d'un autre niveau de filtrage.

L'onglet Configure Provisioning Hierarchy offre la possibilité de créer automatiquement les objets d'arborescence nécessaires à la création de la hiérarchie (comme les unités d'organisation) si ces derniers n'existent pas lors du déplacement ou de la création d'un objet. Dans notre exemple, ce dernier n'est pas configuré. Néanmoins si vous souhaitez l'activer, il suffit d'établir un lien entre un objet composant le distinguished name dans la métaverse et son équivalent dans l'annuaire (voir screenshot ci-dessous).

L'onglet Select Object Types permet de définir les objets que l'on souhaite synchroniser. Par défaut, il est nécessaire de laisser les cases container, domainDNS et OrganizationalUnit cochées. En effet, ces objets permettent de construire le distinguishedName des objets Active Directory, ce qui est obligatoire si l'on souhaite les synchroniser. Aussi, on peut ajouter d'autres types d'objets via le bouton Show All. Conformément à notre étude de cas, nous ajoutons les utilisateurs.

Au travers de la section Select Attributes, il est possible de sélectionner les attributs qui vont être utilisés par le service de synchronisation de FIM. Ces derniers ne sont pas tous affichés par défaut. Il faut cocher la case Show All afin d'obtenir un listing complet.

J'ai choisi les attributs department, givenName (prénom), sn (nom) et samAccountName.

NB : Le compte de service doit avoir les droits d'écriture sur tous les attributs cochées si ces derniers doivent être modifiés par le Management Agent (ce qui est le cas avec l'entreprise MyCompany).

Comme lors de l'article précédent l'assistant nommé Connector Filter configure le filtrage des objets à traiter via des conditions (valeur d'un attribut par exemple). Pour rappel, ces filtres sont exclusifs. Contrairement au Management Agent SQL, nous avons plus de choix puisque nous synchronisons plusieurs types d'objets. Il est donc possible d'établir un filtrage pour chacun d'entre eux. En dehors des types utilisateurs, groupes et contacts, il n'existe pas de besoin pour créer des filtres sur les autres objets qui ne sont utilisés que pour la synchronisation complète de l'architecture.

Durant le panel Configure Join and Projection Rules que nous avons aussi rencontré lors de la configuration Management SQL, nous ajoutons une règle de jointure sur les objets de type person au travers de l'attribut samAccountName. Cette dernière crée le lien entre les objets de la metaverse et ceux de l'annuaire Active Directory. Cela crée aussi indirectement le lien avec les objets issus du référentiel SQL puisque nous les avons précédemment créé dans la métaverse via la règle de projection du Management Agent SQL.

Optionnellement, il est possible d'ajouter une règle de projection si l'on souhaite créer les objets utilisateurs qui n'auraient pas d'équivalent dans la métaverse.

Comme pour le Management Agent SQL, nous définissons des règles de flux pour les attributs suivants : nom, prénom, et service d'appartenance de chaque collaborateur en export vers l'annuaire Active Directory et samaccountname en import. Cependant, le sens du flux est différent puisqu'il s'agit d'exporter les changements vers l'annuaire Active Directory.

NB : Cette configuration force les attributs du référentiel SQL dans l'annuaire LDAP. Si un attribut est modifié dans l'annuaire Active Directory, il sera écrasé lors de la prochaine synchronisation (en dehors su samAccountname puisqu'il permet la jointure avec l'objet dans la métaverse). Pour garder une valeur de l'annuaire LDAP, il convient de réimporter les changements dans la metaverse en ajoutant des règles de flux d'attributs d'imports. Il est aussi nécessaire de définir le Management Agent qui à la priorité sur l'attribut puisque plusieurs Management Agent sont susceptibles d'écrire une valeur. Nous verrons ce second aspect dans le chapitre concernant l'administration de la métaverse dans le prochain article.

Le panel traitant du Deprovisioning conserve sa configuration par défaut car notre étude de cas ne traite que la synchronisation pour le moment.

Enfin, nous n'avons pas créé de règles d'extension (nécessitant un développement en C# ou VB) donc la case adéquate reste grisée. Aussi, le Management Agent AD inclus la possibilité de provisionner des boîtes aux lettres Exchange via la liste déroulante associée au label Provision For. Si l'on choisit une version d'Exchange, il faut aussi configurer l'url d'un serveur d'accès client pour exécuter des commandes Powershell Exchange. Néanmoins, cette configuration doit être associé à une dll développée en C# ou VB.

Profil d'exécution

Maintenant que les Managements Agents sont configurés, il convient de les exécuter. Pour ce faire, il est nécessaire de créer des profils d'exécution. Cette opération s'effectue en sélectionnant le Management Agent puis en cliquant sur Configure Run Profiles.

Un profil d'exécution contient une ou plusieurs étapes permettant d'effectuer des opérations d'import, d'export, de synchronisation. Pour rappel, je vous invite à consulter la partie 1 de cette série d'articles qui définit toutes ces notions.

Pour créer un nouveau profil d'exécution, il suffit de cliquer sur New Profile et de définir un nom pour celui-ci.

La section suivante offre la possibilité de définir la première étape du profil d'exécution. Celle-ci peut avoir les types suivants :

• Import Full
• Import Delta
• Export
• Synchronization Full
• Synchronization Delta
• Delta Import and Delta Synchronization
• Full Import and Delta Synchronization
• Full Import and Full Synchronization

Il est donc possible de sélectionner des traitements incrémentiels ou complets. Aussi, on remarque que certains actions possèdes deux étapes (import et synchronisation). Cependant, tous les types ne sont pas représentés. Comment peut-on réaliser un import suivi d'une synchronisation puis d'un export ? Il suffira d'ajouter une étape au profil d'exécution ! La première étape peut être du type Full Import and Full Synchronization et le seconde de type Export. Il aurait été aussi possible de réaliser cette action en trois étapes :

1. Full Import
2. Full Synchronization
3. Export

Chaque profil d'exécution peut ne posséder qu'une seule étape. Cette façon offre la possibilité d'avoir un plus grand contrôle sur l'exécution (notamment en phase de test), pour vérifier à chaque instant que les changements sont correctement répliqués. Ainsi, si nous avons une étape import, un changement sur un objet ne sera visible que sur le Connector Space du Mangement Agent et non pas dans la métaverse. Il est ainsi possible de mettre en place des actions correctrices avant de modifier la métaverse de façon irréversible.

Pour chaque étape il est possible de définir un fichier de log. Ce dernier peut également servir de fichier de test qui est écrit sans qu'aucun changement n'ait lieu sur le Connector Space.

La section Threshold définit les valeurs maximum d'objets pouvant être importés (Specify number of objects to process) ou supprimés (Specify number of deletions to process) pendant une exécution. Il s'agit de garde-fous évitant par exemple une suppression de masse suite à une mauvaise manipulation.

Enfin, la dernière étape de l'assistant configure des limites d'écriture au niveau du Connector Space, de lecture sur le système connecté ainsi qu'un timeout de connexion sur celui-ci. Ces valeurs ne doivent en général pas être personnalisées.

Dans notre exemple, j'ai créé un profil d'exécution avec les étapes Full Import / Full Synchronisation pour le Management Agent SQL et un second avec les étapes Full Import / Full Synchronisation / Export pour le Management Agent AD. Pour ce dernier, nous exécutons toutes les étapes au travers d'un profil d'exécution.

Aussi, l'une des fonctionnalités utile offertes par le panneau de gestion des profils d'exécution est le bouton Script. En effet, celui-ci génère des scripts VBS qui exécute le profil sélectionné. Il n'y a plus qu'à les utiliser dans des tâches planifiées pour lancer à intervalle régulier un cycle de synchronisation. Malheureusement, pour des scripts en Powershell, il faudra les écrire vous-même.

Il est dorénavant possible d'exécuter chaque Management Agent avec le bouton Run puis en sélectionnant le profil d'exécution qui nous convient.

Lors de la prochaine partie, nous verrons comment analyser les résultats d'une exécution puis nous nous intéresserons à l’administration du service de synchronisation de FIM.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service de Forefront Identity Manager qui répond à un grand nombre de ces problématiques. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration du Management Agent SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Lors de cette troisième partie, nous allons nous attarder sur la configuration d'un Management Agent. Ceux-ci vont nous permettre d'interagir avec les nos différents systèmes. Dans notre cas, il s'agira d'une base de données SQL et d'un annuaire Active Directory. Au cours de cet article, nous verrons la configuration du Management Agent SQL. Nous aborderons les options offertes lors de la configuration d'un Management Agent. Une partie d'entre elles est commune à tous les Management Agent. Seule la synchronisation d'attributs sera traitée. Le provisioning ne sera abordé que lors de la dernière partie de cette série d'articles.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Problématiques

Pour établir une synchronisation, il faudra tout d'abord définir les attributs traité par outil. Il n'est en effet pas obligatoire de synchroniser tout les attributs d'un objets. De même, nous verrons que nous ne sommes pas obligés de traiter tous les objets. Enfin, l'une des problématiques principales sera d'établir le lien entre les objets contenus dans l'annuaire Active Directory et ceux dans le référentiel RH (la base de données SQL).

Configuration du management Agent SQL

Pour cette étude de cas, nous allons commencer par la configuration du management agent SQL qui contient les données du référentiel RH à importer dans l'annuaire Active Directory. Pour rappel, les données vont transiter par la métaverse. Chaque objet de cette dernière aura des liens vers l'objet correspondant du connector space Active Directory et du connector space SQL (s'ils existent dans ces connector space). Je vous invite à relire la partie 1 si vous souhaitez revoir les concepts du service de synchronisation FIM.

Lancez la console Synchronisation Service Manager puis rendez-vous dans l'onglet Management Agents. Cliquez sur Create afin d'exécuter l'assistant de création de Management Agent.

Sur le premier onglet, vous pouvez définir le nom, une description ainsi que le type de Management Agent parmi une liste. Dans notre cas, nous choisissons le type SQL Server.

L'onglet suivant permet de définir la localisation des données ainsi que les informations d'authentification pour y accéder.

Ainsi, on peut définir le nom du serveur SQL et de la base de données. Il faut également indiquer le nom de la table ou de la vue SQL qui contient les informations. Attention, il n'est possible de spécifier qu'une seule table ou vue par Management Agent. Si vous souhaitez accéder à plusieurs tables / vues, il faudra créer plusieurs Management Agent ou alors créer une vue contenant l'union des données que vous souhaitez. Il est par ailleurs plus simple d'adapter son modèle de données en ajoutant des vues supplémentaires plutôt qu'en créant des managements agent qui vont alourdir l'exploitation et la maintenabilité du système.

Enfin, on spécifie un compte utilisateur permettant d'accéder aux données (ce dernier peut s'authentifier en SQL ou au travers d'une authentification intégrée Windows). Ce dernier doit pouvoir lire les données de la table spécifiée.

NB : Les informations optionnelles ne seront pas utilisées dans cet exemple. L'option Delta View permet de spécifier une vue contenant les changements depuis la dernière synchronisation complète. Cela permet d'effectuer des opérations de synchronisation différentielles. Dans le cas contraire et contrairement au Management Agent Active Directory, le Management Agent SQL ne réalisera que des synchronisation complètes. L'option Multivalue Table offre quant à elle la possibilité de gérer des champs pouvant contenir plusieurs valeurs. L'un des exemples les plus courants est l'attribution d'un manager à un collaborateur. En effet, un manager peut posséder plusieurs personnes sous sa responsabilité. Pour approfondir le sujet, je vous invite à lire l'article Technet suivant : https://technet.microsoft.com/en-us/library/cc708679(v=ws.10).aspx

L'assistant va ensuite tenter d'accéder aux données de la base SQL avec les informations fournies. Si l'opération réussie, nous obtenons un listing des différentes colonnes. On peut ensuite définir l'ancre via le bouton Set Anchor. En général, il s'agira de la colonne représentant l'ID car celle-ci sera unique au sein de la table. Enfin, il est possible d'indiquer un type. Ce dernier n'a pas de lien avec le type utilisé dans la metaverse. Il s'agit d'une chaîne de caractère.

L'onglet Configure Connector Filter permet de filtrer des objets en fonctions d'un critère comme la valeur d'un attribut. On peut imaginer le cas où on ne souhaite pas synchroniser les collaborateurs ayant le statut de travailleur détaché. Attention, les objets satisfaisants ces filtres sont exclues de la synchronisation.

Il est ensuite possible de configurer les règles de jointures (Join Rules) et de projection (voir partie 1). Pour rappel, les premières permettent de créer le lien entre un objet de la metaverse existant et celui du connector space. Pour ce faire on définit le type d'objets correspondant (il est possible d'indiquer la valeur Any si l'on souhaite chercher sur toute la metaverse), ainsi que l'attribut de la metaverse et du connector space qui doivent être identiques pour réaliser la jointure. Dans notre cas, j'ai réalisé la jointure sur le login utilisateur (samAccountName dans la base de données et accountName dans la metaverse).

Si plusieurs objets de la metaverse correspondent, vous rencontrerez alors des erreurs à moins d'avoir défini une règle de résolution qui nécessite un développement spécifique en C# ou en VB.Net. Il est important de définir la jointure sur des attributs uniques. Si vous souhaitez établir des jointures en vous basant sur plusieurs attributs, il faudra aussi écrire la règle en C# (ou VB.Net) au travers des règles avancées. Celles-ci seront détaillées plus précisément lors de la partie 6. Chaque Management Agent doit posséder au moins une règle de jointure.

NB : Plusieurs règles de jointures peuvent exister à la fois. Cependant, dès qu'une règle est satisfaite, une jointure est réalisée et les suivantes ne sont pas évaluées. Il est donc important de faire attention à l'ordre des règles (l'ordre de traitement se faisant par ordre croissant).

Concernant les règles de projection, il ne peut y en avoir qu'une par Management Agent. Il convient simplement de définir le type d'objet qui sera créé dans la metaverse si aucune règle de jointure n'a été satisfaite. Contrairement aux règles de jointure, il n'est pas obligatoire d'avoir une règle de projection par Management Agent. Cette dernière est en effet optionnelle.

La section Configure Attribute Flow configure le flux d'attributs entre l'objet dans le connector space (qui est une représentation de l'objet provenant du système connecté) et son équivalent dans la metaverse. Pour chaque information à synchroniser, on définit le nom de l'attribut source et de l'attribut cible ainsi que le sens du flux (Flow Direction) :

• Import : si la valeur de l'attribut est copiée de la base de données vers la metaverse
• Export : si la valeur de l'attribut est copiée de la metaverse vers la base de données (dans notre cas, il pourrait s'agir d'une valeur de l'annuaire Active Directory à copier vers la base de données)

Le champ mapping type permet de définir des règles directes s'il convient simplement de transposer l'attribut ou avancés. Le type Advanced permet de spécifier des règles personnalisées (via du développement C# ou VB.Net), une constante (une valeur toujours identique pour tous les objets) ou une référence de type distinguishedName (elle permet AAA).

Conformément à notre exemple, j'ai choisi de synchroniser sans transformation le nom, le prénom, le samaccountname, le status et le service d'appartenance de chaque collaborateur.

NB : Nous verrons dans un prochain article qu'il est possible de transformer des attributs ou d'en utiliser plusieurs pour définir une valeur cible au travers du mapping de type avancé.

L'avant dernière section (Configure Deprovisioning) définit les règles de suppression des objets d'un connector space lorsque le lien avec l'objet dans la métaverse n'existe plus (par exemple : lorsque l'objet est supprimé de la metaverse). Il existe quatre options :

• Make them disconnector : L'objet est marqué comme déconnecté. Il peut cependant être reconnecté ou recréé dans la metaverse lors de la prochaine synchronisation. Il s'agit du choix par défaut
• Make them explicit disconnectors : L'objet dans le connector space est déconnecté. Contrairement à la première option, il ne peut être reconnecté ou recréé qu'explicitement (par exemple via une action manuelle au travers de l'onglet Joiner que nous verrons dans la partie 5).
• Stage a delete on the objet for the next export run : Cette option indique que l'objet sera supprimé du système connecté lors de la prochaine opération d'export. Cette opération est donc destructrice.
• Determine with a rules extension : Il s'agit d'une règle développée en C# ou VB.Net qui déterminera lequel des trois états précédemment expliqués sera appliqué.

De plus, lorsque l'objet est supprimé du système (la base de données), il est aussi supprimé du connector space et déconnecté de la metaverse. Le comportement par défaut dans cette situation est de supprimer tous les attributs peuplés par le Managament Agent. L'option Do not recall attributes contributed by objects from this management agent when disconnected permet d'indiquer que les attributs fournis par un système ne seront pas supprimés de la metaverse lorsqu'il sera déconnecté. Dans notre exemple, cela pourrait être utile dans le cas où nous souhaiterions conserver le compte Active Directory et tous ses attributs (y compris ceux fournis par le référentiel RH) alors même que le compte a été supprimé du référentiel RH.

Enfin, la dernière étape de l'assistant ne serait pas utilisée dans cet article. Celle-ci permet d'indiquer le nom d'une DLL. Cette dernière contient toutes les règles personnalisées (de jointure, de flux attributs, etc) que nous aurions pu ajouter au cours de l'assistant (Ici, la case est grisée car nous n'en avons pas configuré).

Lors du prochain article, j’aborderai la configuration du management agent Active Directory ainsi que les profils d’exécution permettant d’exécuter les tâches de synchronisation.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service de Forefront Identity Manager qui répond à un grand nombre de ces problématiques. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration du Management Agent SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Cette seconde partie s'intéresse à l'installation du rôle Synchronization Service de FIM. Les prérequis du produit ainsi qu'une installation étape par étape seront détaillées.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Architecture

Le schéma ci-dessous présente un rappel de l’architecture générale d'un environnement FIM 2010 R2 SP1 type pour le service de synchronisation :

Ce dernier est composé d'une base de données SQL Server qui peut être située sur le même serveur que FIM ou sur un serveur différent. Ce dernier communique sur le port TCP 1433. Attention, il n'est pas possible d'utiliser la version Express de SQL Server. Il faut donc disposer d'une licence pour le serveur de base de données.

Haute disponibilité

Il n'existe pas de haute disponibilité pour le service de synchronisation de FIM. Microsoft recommande d'avoir un second serveur passif. Ce dernier possèdera la même configuration et se connectera sur la même base de données mais n'exécutera aucune synchronisation. Ainsi, si le serveur principal connaît une défaillance, il suffit d'activer la synchronisation sur le second serveur. Dans le cadre de ce type de service, il est tolérable d'avoir une coupure de service qui sera rapidement corrigée à la prochaine synchronisation. De plus, le service de synchronisation ne s'exécute pas constamment mais à intervalle régulier. Une coupure de service peut donc être invisible si les serveurs sont supervisés et que l'activation du second serveur se fait rapidement.

Prérequis

Système d'exploitation

FIM 2010 R2 SP1 peut être installé sur Windows 2012. Pour l'installer sur Windows 2012 R2, il faut se tourner vers MIM 2015 (Microsoft Identity Manager).

Compte de service

FIM utilise à compte de service pour s’exécuter. Il est donc nécessaire d’en créer un pour tout nouvel environnement.

Dans le cadre du respect des bonnes pratiques de déploiement de FIM mais aussi afin de respecter des préconisations de sécurité, un paramétrage du compte de service FIM est à effectuer. Ce dernier permet d'empêcher un utilisateur d'utiliser ce compte pour se connecter au serveur.

Cette opération doit se réaliser dans la console Local Security Policy (secpol.msc) du serveur FIM. Il faut se rendre dans « Local Policies » puis « User Rights Assignment » et renseigner le nom du compte de service FIM sur les 3 éléments ci-dessous :

• Deny access to this computer from the network
• Deny log on as batch job
• Deny log on locally

Groupes de sécurité

Par défaut, FIM 2010 R2 utilise des groupes d’administration locaux. Pour utiliser des groupes de sécurité du domaine, il est nécessaire de les créer avant l'installation (de type domain local afin de donner des accès à des utilisateurs répartis sur plusieurs domaines Active Directory). Ils sont au nombre de cinq et correspondent aux groupes locaux suivants :

• FIMSyncAdmins
• FIMSyncBrowse
• FIMSyncJoiners
• FIMSyncOperators
• FIMSyncPasswordSet

En dehors du groupe FIMSyncAdmins qui donne des droits d'accès complets au serveur de synchronisation, nous reviendrons sur les autorisations données à chacun de ses groupes dans la partie 5 de cette série d'article.

L'implémentation des groupes de sécurité de domaine est recommandé si on possède plusieurs serveurs FIM (haute disponibilité avec serveur passif par exemple).

Logiciels

Le framework .Net 3.5 (disponible dans les sources d'installation de Windows Server depuis la version 2012) ainsi que SQL Native Client 2012 doivent être installés sur le serveur de Synchronisation avant de commencer l'installation.

Installation

Lorsque les prérequis sont remplis, on peut procéder à l'installation. Sur le serveur de synchronisation, il faut ouvrir une session avec un compte Administrateur Local du serveur. Ce compte doit aussi permettre de créer la base de données sur le serveur SQL qui contiendra la base de données. Pour ce faire, on peut donner temporairement les droits sysadmin au compte réalisant l'installation sur la base de données.

Il faut ensuite se rendre dans le dossier Synchronization Service et exécuter le fichier setup.exe.

Sur le premier écran, cliquez sur Next.

Le second onglet permet simplement de valider la licence en cochant la case I accept the license terms in the License Agreement.

Il est ensuite possible de définir le chemin d'installation via le bouton Change.

Puis, on définit le serveur SQL qui sera utilisé. Il peut être local (sur le même serveur) ou distant. On peut aussi spécifier s'il s'agit d'une instance SQL par défaut ou nommée.

L'onglet suivant permet d'indiquer le compte de service utilisé par le service de synchronisation FIM. Il s'agit du compte créée lors des prérequis.

Les groupes de sécurités doivent ensuite être défini. S'il s'agit de groupe Active Directory, il est nécessaire de changer les groupes inscrit par défaut dont voici la liste de correspondance :

• Administrator : FIMSyncAdmins
• Operator : FIMSyncOperators
• Joiner : FIMSyncJoiners
• Connector browse : FIMSyncBrowse
• WMI Password management : FIMSyncPasswordSet

On peut également créer automatiquement les règles dans le pare feu Windows permettant de communiquer en RPC avec le service de synchronisation. Cette option ne sera pas utilisée au cours de cette série d'article.

L'installation commence après avoir cliqué sur le bouton Install.

Si vous n'avez pas suivi les recommandations de sécurisation du compte de service énoncées dans les prérequis alors vous obtiendrez le message suivant.

Enfin, lorsque l'installation est terminée, un message d'avertissement indique que la clé de chiffrement va être sauvegardé. Il faut alors définir un nom de fichier et un emplacement. Cette dernière est utile si vous devez restaurer la configuration. En effet, sans cette clé, les données de configuration ne peuvent être lues.

L'installation se termine. Nous allons pouvoir passer à la configurations des Managements Agents dans le prochain article.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestion de compte (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Forefront Identity Manager (FIM) est une suite de produits répondant à un grand nombre de ces problématiques. Voici une liste des différents composants de FIM et de leur utilité :

• FIM Synchronization Service : Il s'agit du service le plus connu, car il est le plus utilisé et forme notamment la base des outils comme Dirsync/Azure AD Connect (pour la synchronisation AD On premise / Office 365). Il représente le moteur de synchronisation pouvant interagir entre différents référentiels. Il permet de répercuter les changements d'un référentiel à un autre.
• FIM Service : Ce composant ajoute une surcouche offrant la possibilité de définir une politique de gestion des identités avec un système de Workflow. Par exemple, il est possible de gérer les membres d'un groupe Active Directory. Cette action est aussi réalisable directement via FIM Sync. Cependant, elle nécessite une implémentation qui peut être plus complexe via ce dernier. En effet FIM Service et FIM Portal donne la possibilité d'utiliser une syntaxe dite déclarative, qui est plus simple dans un environnement où il n'y a pas de développeur.
• FIM Portal : Il s'agit d'une interface web d'administration pour les autres composants de FIM. Ainsi, il devient possible de configurer simplement FIM Service.
• Password Change Notification Service : Associé à FIM Portal, il permet d'implémenter un portail de réinitialisation de mot de passe "self service".
• FIM Certificate Management : Il s'agit d'un portail de gestion des certificats sur carte à puce ("smartcard"). Ce dernier n'est pas intégré à FIM Portal. Il devient ainsi possible de gérer le cycle de vie de ce type de certificat via des Workflow spécifiques tels que l'enrôlement des cartes à puces. Ce composant nécessite l'installation d’un module sur l'autorité de certification émettrice.
• FIM Reporting : Cet outil permet de générer des rapports. Par exemple, on peut vouloir obtenir un rapport sur les changements de membre au sein d'un groupe ou encore un historique des workflows qui ont été exécutés par FIM Service.

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration du Management Agent SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommée pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Licensing

Le licensing de FIM a évolué depuis Avril 2015. Désormais, il n'est plus nécessaire d'avoir une licence serveur. Celle-ci est incluse avec la licence de Windows Server (Standard et Datacenter). Cependant le système de CAL existe toujours et Microsoft a d'ailleurs publié un schéma récapitulatif à ce sujet. En effet, tous les services ne nécessitent pas forcément d'avoir une CAL. Ainsi, on remarque que tous les services à l'exception de celui de synchronisation nécessite une CAL pour chaque utilisateur géré par le service. Toutes les opérations réalisées durant cette série d'article ne nécessiteront donc pas de CAL.

NB : La licence SQL Server n'est pas inclue et doit donc être prévue (SQL Express n'est pas compatible avec FIM Synchronization Service).

Concepts

Lors de ce chapitre, J’aborderai les différents concepts que nous pouvons rencontrés avec le service de synchronisation FIM. Ces derniers doivent être compris dès que l'on souhaite mettre en place une synchronisation entre différents référentiels d'identité. Grâce à ceux-ci, nous allons pouvoir savoie à chaque instant où la donnée est stockée. En effet, FIM Synchronization Service repose sur un schéma plus complexe qu'une simple base de données.

Metaverse (MV)

Il s'agit du cœur de FIM, il centralise la totalité des informations de tous les objets gérés par l'outil. Il peut s'agir d'utilisateur, de groupe, de contact, etc. Il est même possible de créer ses propres objets. La metaverse n'existe qu'une fois par serveur FIM. Cette dernière peut contenir différents types d'attributs :

• Chaîne de caractère
• Nombre
• Booléen
• Reference (correspond à un lien vers un autre objet)
• Binaire

En dehors du type booléen, tous les champs peuvent être de type "Multi-valued", c’est-à-dire qu'ils peuvent posséder une liste de valeur au lieu d'une valeur unique. Aussi, les champs de type chaîne de caractères, binaire et nombre peuvent être indexés, ce qui permet d'effectuer des recherches dessus. Cette option pourra être utile dans le cas de règles développées en C# ou en VB.Net lorsque celles-ci nécessiteront de trouver un objet (ou une liste d'objets) précis dans la metaverse.

NB : Les types indexés possèdent certaines propriétés supplémentaires. Par exemple, une chaîne de caractère indexée est limitée à une longueur de 448 caractères (illimité dans le cas contraire).

Connector Space (CS)

C'est une entité logique représentant tous les objets d'un système connecté à FIM. Ce dernier peut être une base de données, un annuaire LDAP, un fichier à plat, ... Ces objets interagissent avec le système connecté ou avec la metaverse au travers d'actions que nous verrons plus loin. Attention, il faut bien noter qu'un connector space ne contient qu'une représentation de l'objet pour un système donné. Si vous modifiez cet objet, cela n'aura pas d'impact sur le système connecté ou sur la metaverse tant que cette modification n'aura pas été poussé sur l'un de ces éléments. Il existe un connector space par système connecté à FIM.

Management Agent (MA)

Il s'agit de l'ensemble de règle déterminant les mécanismes de synchronisation entre le système de données, le connector space et la metaverse. Il interagit avec ces trois systèmes.

Connector

Un Connector est le nom donné à un objet d'un connector space d'un système connecté à FIM qui est lui-même connecté à un objet dans la metaverse. S'il ne l'est pas il s'agit d'un disconnector. Ces derniers peuvent être explicites à cause d'une action voulue dans le Management Agent et ne peuvent être connectés à la metaverse sans l'outil Joiner que nous verrons dans la partie 4 (celui-ci permet de joindre manuellement un objet d'un connector space à la metaverse). On parle alors de connector explicite si la jointure entre un connector space et la metaverse a eu lieu avec cet outil. Un disconnector peut être aussi de type filtered si un filtre dans la configuration du Management Agent empêche de connecter l'objet du connector space à la metaverse. Ce comportement peut être modifié facilement en changeant le filtre. A noter qu'un connector explicite ne peut devenir un filtered disconnector via un filtre. Ces derniers ne s'appliquent pas à ce type d'objet.

Join

C'est l'opération consistant à joindre un objet d'un Connector Space à un objet de la metaverse. Attention, ceux-ci doivent exister tous les deux. Elle a pour effet de créer un connector.

Projection

Lorsqu'un objet dans un connector space n'existe pas dans la metaverse, il peut être projeter. Cette opération correspond à la création d'un objet dans la metaverse. Cela permet aussi de créer un connector.

Import

Cette opération importe les données depuis un système connecté vers le connector space associé.

Export

Il s'agit d'exporter les données vers un système connecté depuis le connector space associé.

Synchronisation

C'est l'étape qui permet d'appliquer tout changement entre la metaverse et un connector space. Celle-ci est bidirectionnelle. Cette opération suit généralement un import et précède un export.

Provisioning

Le provisioning est la notion définissant l'action qui crée un nouvel objet dans un connector space lorsqu'il n'existe pas. Lors de celle-ci, un nouveau connecteur va être créé avec un objet de la metaverse. Ce nouvel objet ne sera visible dans le système connecté qu'après une opération d'export.

Delta

Les opérations d'import, d'export et de synchronisation peuvent être complètes ou incrémentielles. Ce second type est aussi nommé "delta" et n'est pas disponible pour tous les types de système. Il est parfois nécessaire d'implémenter quelques modifications sur le système connecté pour traiter ce type d'opération (exemple : un référentiel SQL nécessite une table des changements qui ont eu lieu depuis la dernière synchronisation).

Schéma fonctionnel

Enfin, voici un schéma avec deux systèmes connectés reprenant le cas pratique qui sera développé au cours de cette série d'article (un annuaire Active Directory et une base de données SQL Server) montrant les interactions entre les différents entités :

Introduction

Azure AD Connect est devenu, depuis quelques mois, le nouvel outil de synchronisation d'identité entre une infrastrcture Active Directory On-Premise et Azure Active Directory. Ce dernier doit remplacé les outils existants (Dirsync et Azure AD Sync) en consolidant les fonctionnalités de chacun de ceux-ci. Aussi, il apporte de nombreuses fonctionnalités comme la synchronisation des attributs étendus, la synchronisation Azure AD vers Active Directory On premise des groupes ou encore une interface de monitoring Azure AD Connect Health. Malheureusement, toutes ces nouvelles fonctionnalités nécessitent de souscrire à la version basic voir premium d’Azure Active Directory.

Du point de vue de l'installation, Microsoft à simplifié les choses pour les personnes disposant déjà d'un des outils précédemment cités. Le but de cet article est de partager un retour d'expérience sur la mise à jour de Dirsync vers Azure AD Connect au travers d'un guide pas à pas puis de détailler les changements entre les deux outils.

Azure AD Connect peut être téléchargé via le lien suivant :

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Mise à jour

Lors du lancement du programme d'installation, il est d'abord demandé d'accepter la licence utilisateur.

Il s'en suit une analyse du serveur existant afin de valider que la configuration Dirsync est compatible avec le processus de migration Azure AD Connect. Si celle-ci n'est pas compatible, il faudra alors réaliser une installation complète du produit. Cela implique de reconfigurer intégralement l'outil (comptes, base de données, règles de filtrage, ….). Plusieurs causes peuvent être responsables de la non prise en charge de la migration :

• Un trop grand nombre d'objets à synchroniser (+ de 50000)

• L'utilisation d'une DLL d'extension personnalisée. Ces dernières permettent d'étendre les fonctionnalités de synchronisation en réalisant du filtrage plus poussé ou une transformation sur certains attributs. Il s'agit d'un concept hérité de Forefront Identity Manager (FIM). En effet Azure AD Connect, comme ses prédécesseurs est toujours basé sur cet outil.

• La suppression d'attributs dans les règles de synchronisation.

Lorsque l'analyse est terminée, il faut indiquer le chemin d'installation ainsi que les informations d'accès à la base de données et éventuellement un compte de service. Comme pour Dirsync, ce dernier doit posséder les droits "Replicate Directory Changes" au niveau du domaine.

Le programme installe ensuite les prérequis.

Les informations (login/mot de passe) du compte utilisé par Dirsync pour accéder à Azure Active Directory doivent être renseignées.

Puis, il est nécessaire d'indiquer un compte Active Directory ayant les droits administrateur de l'entreprise.

La dernière étape consiste à choisir si l'on a activé le mode hybride et s'il faut démarrer la synchronisation dès la fin de l'installation. Ne pas cocher la case permet néanmoins de valider que la configuration a été correctement reportée depuis Dirsync.

Enfin, l'installation s'exécute (une dizaine de minutes).

Revue post installation

Une fois l'installation terminée, DirSync est désinstallé et est remplacé par Azure AD Connect. De nouvelles icônes apparaissent :

• Azure AD Connect : Permet de voir et configurer les paramètres principaux de l'outil

• Synchronization Rules Editor : Cet utilitaire sert à la configuration des règles de filtrages et de transferts d'attributs et ne se trouvent plus dans la console de gestion de FIM.

• Synchronization Service : Cet icône mène à la console de FIM contenant les connecteurs de gestion des identités qui a été renommé pour l'occasion. Comme pour Dirsync, il y a deux connecteurs :

  • Active Directory on premise / Azure AD Connect : import uniquement (sauf en cas d'utilisation du writeback avec Azure AD Premium)

  • Azure AD Connect / Azure Active Directory

• Synchronisation Service Key Management Utility : Utilitaire de gestion de la clé encryptant les données dans Azure AD Connect

NB : Elles sont identiques à celles présentes dans Azure Active Directory Sync.

De plus, comme pour Dirsync, une tâche planifiée nommée Azure AD Sync Scheduler est créée. Elle s'exécute toutes les trois heures (mais il est bien sûr possible de changer ce comportement).

Revue de la configuration

Azure AD Connect :

L'utilitaire Azure AD Connect permet plusieurs options :

• Revue de la configuration actuel

• Configuration des options de synchronisation

• Mise à jour du connecteur

• Gestion du mode staging

La première option permet simplement une revue de la synchronisation mise en place avec une visualisation des annuaires synchronisés et des options activées (synchronisation du mot de passe, des attributs étendues, mapping de l'attribut servant d'UPN dans Office 365). En effet depuis Windows Azure Active Directory Sync, il est possible d'implémenter une synchronisation multi-forêt. Aussi, une synchronisation vers des annuaires différents d'Active Directory est prévue par Microsoft mais cette fonctionnalité n'est pas encore implémentée.

NB : L'option de filtrage par groupe n'est disponible que pour une nouvelle installation et n'est conseillé par Microsoft que dans le cadre d'un déploiement progressif.

Les trois autres options nécessitent d'indiquer un compte administrateur Azure Active Directory  afin de modifier certaines options de configuration.

Le second onglet offre la possibilité d'ajouter d'autres annuaires Active Directory pour la synchronisation.

Il permet aussi d'activer ou désactiver certaines options comme la gestion du mode hybride d'Exchange ou l'écriture inversée (Azure AD vers Active Directory On premise).

L'actualisation du connecteur peut être utilisée après une mise à jour de votre schéma Active Directory. Ainsi, Azure AD Connect pourra mettre à jour ses connecteurs en cas de changement.

Enfin, la dernière option concerne l'activation du mode staging. Lorsqu'il est activé, aucun changement n'est synchronisé/exporté vers Active Directory (si le Writeback est activé) ou vers Office 365. Cela permet de valider sa configuration avant d'appliquer un changement.

Synchronization Service :

Il s'agit de la console Synchronisation Service de Forefront Identity Management. Cependant pour chaque connecteur (appelé Management Agent), les options de configuration sont bien plus légères que dans Dirsync. Il n'est possible de configurer que les paramètres de connexion à l'annuaire, les attributs accessibles et le filtrage par unité d'organisation (via le bouton Container de l'onglet Configure Directory Partitions). En effet, la configuration des filtres par attribut et des règles de jointure d'attribut s'effectue via l'outil présenté dans le chapitre suivant. Cette nouveauté était apparue avec Azure Active Directory Sync.

Synchronization Rules Editor :

Cet outil  change la manière dont sont gérées les règles de synchronisation. Cette gestion ne s'effectue plus au sein de la console de synchronisation héritée de Forefront Identity Manager. Néanmoins, cette nouveauté permet d'utiliser la syntaxe déclarative de FIM qui n'était utilisable qu'au travers de FIM portal (et qui nécessite des CAL pour chaque utilisateur géré par ce système). Ce langage donne la possibilité d'effectuer des opérations simples sans passer par du développement en C# ou VB.Net. Les deux liens ci-dessous expliquent la syntaxe et la détaille :

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-understanding-declarative-provisioning-expressions/

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-functions-reference/

L'utilitaire offre une vision globale des règles entrantes (import depuis Active Directory On premise ou Azure AD) et sortantes (export vers Active Directory On premise ou Azure AD). Toutes ces règles ont une priorité (la plus faible étant prioritaire sur les autres). Si ces dernières ont un poids supérieur à 100 alors elles correspondent aux règles par défaut de l’outil.

Nous remarquons sur l'image précédente qu'il y a une règle avec une priorité de 99. Il s'agit d'une règle personnalisée reprise lors de la migration de Dirsync. Celle-ci filtre les utilisateurs via un attribut Active Directory. On peut définir le type d'objet source (ici l'annuaire Active Directory On premise) et le type d'objet dans la Metaverse, c’est-à-dire dans la base de données d'Azure AD Connect. Enfin, on peut redéfinir la priorité de la règle. 

L'onglet suivant permet de définir le ou les attributs utilisé(s) pour filtrer les objets (ici des utilisateurs mais cela peut aussi s'appliquer à des groupes par exemple). La définition du filtrage se fait de la même façon que sur Dirsync (les objets satisfaisants la règle étant exclus de la synchronisation).

Ensuite, il est possible de définir une règle de jointure entre un objet provenant de la source (annuaire Active Directory ou Azure Active Directory) et la metaverse. Cette jointure s'effectue sur un attribut. Dans le cas de notre règle de filtrage, il n'existe pas de règle de jointure. Cependant il n'est pas nécessaire d'en ajouter.

En effet, si l'on ouvre la règle avec la priorité 100 (In From AD - User Join), on remarque qu'une règle de jointure existe déjà pour les objets de types utilisateurs.

Enfin, on définit les valeurs transmises depuis la source vers la metaverse. Elles peuvent être de trois types :

• une valeur constante

• un attribut source

• un attribut source transformé via la syntaxe déclarative

Dans le cadre d'un filtrage par attribut pour la synchronisation, les objets non synchronisés doivent posséder l'attribut cloudFiltered avec la valeur True dans la metaverse.

Conclusion

L'installation est donc très similaire à celle de Dirsync et demande les mêmes informations (compte administrateur de l'entreprise, serveur SQL, ...). De plus, le processus de mise à jour est simplifiée au maximum. Néanmoins, pour les personnes n'ayant pas utilisées Azure Active Directory Sync, l'administration et notamment la configuration les règles de synchronisation est différente.

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