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 :
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.