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 :
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 :
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 :
-
Full Import
-
Full Synchronization
-
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.