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 :
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 :
-
Synchronisation entrante : depuis le connector space vers la métaverse
-
Synchronisation sortante : depuis la métaverse vers le connector space
Lors de la première étape, voici les règles qui s'appliquent :
-
Object Deletion rule
-
Conntor Filter rule
-
Join Rule
-
Projection rule
-
Import Attribute Flow rule
Durant la synchronisation sortante, l'ordre d'application est le suivant :
-
Provisioning rule
-
Deprovisioning Rule
-
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.