Guide des concepts de Microsoft BHOLD Suite

Microsoft Identity Manager 2016 (MIM) permet aux organisations de gérer l’ensemble du cycle de vie des identités d’utilisateur et leurs informations d’identification associées. Il peut être configuré pour synchroniser les identités, gérer de manière centralisée les certificats et les mots de passe, et approvisionner les utilisateurs dans des systèmes hétérogènes. Avec MIM, les organisations informatiques peuvent définir et automatiser les processus utilisés pour gérer les identités depuis leur création jusqu’à leur mise hors service.

Microsoft BHOLD Suite étend les fonctionnalités de MIM en ajoutant le contrôle d’accès en fonction du rôle. BHOLD permet aux organisations de définir des rôles d’utilisateur et de contrôler l’accès aux données sensibles et aux applications. L’accès est basé sur ce qui est approprié pour ces rôles. BHOLD Suite inclut des services et des outils qui simplifient la modélisation des relations de rôle au sein de l’organisation. BHOLD mappe ces rôles à des droits pour vérifier que les définitions de rôle et les droits associés sont correctement appliqués aux utilisateurs. Ces fonctionnalités sont entièrement intégrées à MIM pour que l’utilisateur final et les équipes informatiques bénéficient d’une expérience fluide.

Ce guide vous aide à comprendre le fonctionnement de BHOLD Suite avec MIM et contient les rubriques suivantes :

• Contrôle d’accès en fonction du rôle
• Attestation
• Rapports
• Connecteur Access Management

BHOLD n’est pas recommandé pour les nouveaux déploiements. Microsoft Entra ID fournit désormais des révisions d’accès, qui remplacent les fonctionnalités de la campagne d’attestation BHOLD, et la gestion des droits d’utilisation, qui remplace les fonctionnalités d’attribution d’accès.

Contrôle d’accès en fonction du rôle

La méthode la plus courante pour contrôler l’accès des utilisateurs aux données et aux applications est l’utilisation du contrôle d’accès discrétionnaire. Dans la plupart des implémentations courantes, chaque objet important a un propriétaire identifié. Le propriétaire a la possibilité d’accorder ou de refuser l’accès à l’objet aux autres utilisateurs en fonction de l’identité individuelle ou de l’appartenance à un groupe. Dans la pratique, le contrôle d’accès discrétionnaire entraîne généralement une multitude de groupes de sécurité, certains reflètent la structure organisationnelle, d’autres représentent des regroupements fonctionnels (par exemple, des types de tâches ou des attributions de projet) et d’autres sont constitués de regroupements d’utilisateurs et d’appareils improvisés qui sont associés à des fins plus temporaires. À mesure que les organisations se développent, l’appartenance à ces groupes devient de plus en plus difficile à gérer. Par exemple, si un employé est transféré d’un projet à un autre, les groupes utilisés pour contrôler l’accès aux ressources des projets doivent être mis à jour manuellement. Dans ce cas, il n’est pas rare que des erreurs se produisent, erreurs pouvant entraver la productivité ou la sécurité du projet.

MIM présente des fonctionnalités qui permettent d’atténuer ce problème en fournissant un contrôle automatique de l’appartenance aux listes de distribution et aux groupes. Toutefois, cela ne résout pas le problème de la complexité intrinsèque de la prolifération des groupes, lesquels ne sont pas nécessairement liés entre eux de façon structurée.

Le déploiement du contrôle d’accès en fonction du rôle (RBAC) est un moyen de réduire considérablement cette prolifération. RBAC ne remplace pas le contrôle d’accès discrétionnaire. RBAC s’appuie sur le contrôle d’accès discrétionnaire en fournissant un framework qui classifie les utilisateurs et les ressources informatiques. Cela vous permet de rendre explicite leur relation ainsi que les droits d’accès appropriés conformément à cette classification. Par exemple, si vous affectez à un utilisateur des attributs qui spécifient son poste et ses affectations de projet, il peut avoir accès aux outils nécessaires pour son travail et aux données dont il a besoin pour participer à un projet particulier. Quand l’utilisateur passe à une autre tâche et reçoit d’autres affectations de projets, le changement des attributs qui spécifient son poste et ses projets bloque automatiquement l’accès aux ressources exclusivement réservées à la fonction antérieure de l’utilisateur.

Comme les rôles peuvent être contenus dans d’autres rôles de manière hiérarchique, (par exemple, les rôles de responsable des ventes et de commercial peuvent être contenus dans le rôle plus général des ventes), il est facile d’affecter les droits appropriés à des rôles spécifiques tout en continuant à fournir les droits appropriés à toute personne qui partage le rôle plus inclusif. Par exemple, dans un hôpital, l’ensemble des équipes médicales peuvent recevoir le droit d’afficher les dossiers des patients, mais seuls les médecins (un sous-rôle du rôle médical) peuvent recevoir le droit d’entrer des ordonnances pour le patient. De même, les utilisateurs appartenant au rôle des employés administratifs peuvent ne pas être autorisés à accéder aux dossiers des patients, à l’exception des employés chargés de la facturation (sous-rôle du rôle des employés administratifs), qui peuvent avoir accès aux parties des dossiers dont ils ont besoin pour facturer au patient les services fournis par l’hôpital.

Un autre avantage de RBAC est de pouvoir définir et appliquer une séparation des tâches. Cela permet à une organisation de définir des combinaisons de rôles qui accordent des autorisations qui ne doivent pas être données au même utilisateur. Par exemple, un utilisateur spécifique ne peut pas recevoir des rôles qui l’autorisent à lancer et autoriser un paiement en même temps. RBAC fournit la possibilité d’appliquer ce type de stratégie automatiquement au lieu de devoir évaluer l’implémentation effective de la stratégie pour chaque utilisateur.

Objets du modèle de rôle BHOLD

Avec BHOLD Suite, vous pouvez spécifier et organiser des rôles au sein de votre organisation, mapper des utilisateurs aux rôles et mapper les autorisations appropriées aux rôles. Cette structure est appelée modèle de rôle. Elle contient et relie cinq types d’objets :

• Unités d’organisation
• Utilisateurs
• Rôles
• Autorisations
• Applications

Unités d’organisation

Les unités d’organisation représentent le principal moyen d’organiser les utilisateurs dans le modèle de rôle BHOLD. Chaque utilisateur doit appartenir à au moins une unité d’organisation. (En fait, quand un utilisateur est supprimé de la dernière unité d’organisation dans BHOLD, l’enregistrement de ses données est supprimé de la base de données BHOLD.)

Important

Il ne faut pas confondre les unités d’organisation dans le modèle de rôle BHOLD avec les unités d’organisation dans Active Directory Domain Services (AD DS). En règle générale, la structure des unités d’organisation dans BHOLD est basée sur l’organisation et les stratégies de votre entreprise, et non pas sur les exigences de votre infrastructure réseau.

Sans être une obligation, les unités d’organisation sont très souvent structurées dans BHOLD pour représenter la structure hiérarchique de l’organisation, comme celle présentée ci-dessous :

Dans cet exemple, le modèle de rôle peut commencer par une unité organisationnelle représentant l’entreprise dans sa globalité (représentée par le président, car il ne fait pas partie des autres unités d’organisation). L’unité d’organisation racine BHOLD (qui existe toujours) peut être utilisée dans ce but. Les unités d’organisation qui représentent les divisions de l’entreprise gérées par les vice-présidents sont placées dans l’unité d’organisation de l’entreprise. Ensuite, les unités d’organisation qui correspondent aux directeurs des ventes et marketing sont ajoutées aux unités d’organisation des ventes, et les unités d’organisation qui représentent les responsables de ventes régionaux sont placées dans l’unité d’organisation du responsable des ventes de la région est. Les commerciaux, qui ne gèrent pas d’autres utilisateurs, deviennent membres de l’unité d’organisation du responsable des ventes de la région est. Notez que les utilisateurs peuvent être membres d’une unité d’organisation à n’importe quel niveau. Par exemple, un assistant administratif, qui n’a pas de poste de responsable et rapporte directement à un vice-président, est membre de l’unité d’organisation du vice-président.

En plus de représenter la structure organisationnelle, les unités d’organisation peuvent également servir pour regrouper des utilisateurs et d’autres unités d’organisation en fonction de critères fonctionnels, comme pour certains projets ou une spécialisation. Le diagramme suivant montre comment les unités d’organisation sont utilisées pour regrouper les commerciaux en fonction du type de client :

Dans cet exemple, chaque commercial appartient à deux unités d’organisation : une qui représente sa zone géographique dans la structure de gestion de l’organisation et l’autre qui représente la clientèle du commercial (détaillants ou grands groupes). Chaque unité d’organisation peut avoir des rôles différents qui, à leur tour, peuvent recevoir des autorisations différentes pour accéder aux ressources informatiques de l’organisation. Par ailleurs, les rôles peuvent être hérités d’unités d’organisation parentes, ce qui simplifie le processus de propagation des rôles sur les utilisateurs. En revanche, des rôles spécifiques peuvent ne pas être hérités pour qu’ils soient associés uniquement aux unités d’organisation appropriées.

Vous pouvez créer des OrgUnits dans BHOLD Suite à l’aide du portail web BHOLD Core.

Utilisateurs

Comme indiqué ci-dessus, chaque utilisateur doit appartenir à au moins une unité d’organisation. Comme les unités d’organisation constituent le mécanisme principal d’association d’un utilisateur à des rôles, dans la plupart des organisations, un utilisateur donné appartient à plusieurs unités d’organisation pour lui associer plus facilement des rôles. Toutefois, dans certains cas, il peut être nécessaire d’associer un rôle à un utilisateur en dehors des unités d’organisation auxquelles il appartient. Par conséquent, un utilisateur peut recevoir directement un rôle, mais aussi en obtenir des unités d’organisation auxquelles il appartient.

Quand un utilisateur n’est pas actif dans l’organisation (en congé maladie, par exemple), il peut être suspendu, ce qui a pour effet de révoquer toutes ses autorisations sans le supprimer du modèle de rôle. Quand il reprend son travail, l’utilisateur peut être réactivé, ce qui entraîne la restauration de toutes les autorisations que lui accordent ses rôles.

Les objets pour les utilisateurs peuvent être créés individuellement dans BHOLD via le portail web BHOLD Core ou à l’aide d’Access Management Connector avec le service de synchronisation FIM pour importer des informations utilisateur à partir de sources telles que des applications services de domaine Active Directory ou de ressources humaines.

Vous pouvez créer les utilisateurs directement dans BHOLD sans utiliser le service de synchronisation FIM. Cela peut être utile pour modéliser des rôles dans un environnement de préproduction ou de test. Vous pouvez également autoriser des utilisateurs externes (par exemple, les employés d’un sous-traitant) à recevoir des rôles et, par conséquent, un accès aux ressources informatiques, sans les ajouter à la base de données d’employés. Toutefois, ces utilisateurs ne peuvent pas utiliser les fonctionnalités libre-service de BHOLD.

Rôles

Comme indiqué précédemment, dans le modèle de contrôle d’accès en fonction du rôle (RBAC), les autorisations sont associées aux rôles plutôt qu’aux utilisateurs individuels. Il est alors possible de donner à chaque utilisateur les autorisations nécessaires pour effectuer ses tâches en changeant ses rôles au lieu de lui accorder ou refuser les autorisations une par une. Par conséquent, l’attribution d’autorisations n’implique plus la participation des équipes informatiques et s’effectue dans le cadre de la gestion de l’entreprise. Un rôle peut agréger des autorisations pour accéder à différents systèmes, directement ou par le biais de sous-rôles, ce qui réduit davantage le besoin d’implication de l’équipe informatique pour gérer les autorisations des utilisateurs.

Notez que les rôles sont une fonctionnalité du modèle RBAC lui-même. En général, les rôles ne sont pas approvisionnés pour cibler des applications. Vous pouvez donc utiliser RBAC avec des applications existantes qui ne sont pas conçues pour utiliser des rôles ou changer les définitions de rôle afin de s’adapter à l’évolution des modèles d’entreprise sans avoir à modifier les applications elles-mêmes. Si une application cible est conçue pour utiliser des rôles, vous pouvez associer les rôles du modèle de rôle BHOLD avec les rôles de l’application correspondante en traitant ces derniers comme des autorisations.

Dans BHOLD, vous pouvez attribuer un rôle à un utilisateur par deux mécanismes principaux :

• En attribuant un rôle à une unité d’organisation dont l’utilisateur est membre
• En attribuant un rôle directement à un utilisateur

Un rôle attribué à une unité d’organisation parente peut éventuellement être hérité de ses unités d’organisation membres. Quand un rôle est attribué à une unité d’organisation ou qu’elle en hérite, il peut être désigné comme rôle effectif ou proposé. S’il s’agit d’un rôle effectif, tous les utilisateurs de l’unité d’organisation reçoivent le rôle. En revanche, le rôle proposé doit être activé pour chaque utilisateur ou unité d’organisation membre afin d’être effectif pour cet utilisateur ou les membres de l’unité d’organisation. Vous pouvez donc attribuer à des utilisateurs une partie des rôles associés à une unité d’organisation, au lieu d’attribuer automatiquement tous les rôles de l’unité d’organisation à tous les membres. Par ailleurs, les rôles peuvent avoir des dates de début et de fin, et des limites peuvent être placées sur le pourcentage d’utilisateurs dans une unité d’organisation pour lesquels un rôle peut être effectif.

Le diagramme suivant illustre la façon dont un utilisateur individuel peut recevoir un rôle dans BHOLD :

Dans ce diagramme, le rôle A est attribué à une unité d’organisation sous forme de rôle héritable. Il est donc hérité de toutes ses unités d’organisation membres et de tous les utilisateurs dans ces unités d’organisation. Le rôle B est attribué comme rôle proposé pour une unité d’organisation. Il doit être activé pour qu’un utilisateur de l’unité d’organisation puisse bénéficier des autorisations du rôle. Le rôle C est un rôle effectif, ses autorisations s’appliquent donc immédiatement à tous les utilisateurs de l’unité d’organisation. Le rôle D est lié directement à l’utilisateur et, par conséquent, ses autorisations s’appliquent immédiatement à cet utilisateur.

Par ailleurs, un rôle peut être activé pour un utilisateur en fonction des attributs de ce dernier. Pour plus d’informations, consultez Autorisation basée sur les attributs.

Autorisations

Une autorisation dans BHOLD correspond à une autorisation importée d’une application cible. Autrement dit, quand BHOLD est configuré pour utiliser une application, il reçoit une liste des autorisations qu’il peut lier aux rôles. Par exemple, quand Active Directory Domain Services (AD DS) est ajouté à BHOLD comme application, il reçoit une liste des groupes de sécurité qui, en tant qu’autorisations BHOLD, peuvent être liés aux rôles dans BHOLD.

Les autorisations sont propres aux applications. BHOLD fournit une seule vue unifiée des autorisations, ce qui permet d’associer les autorisations aux rôles sans que les responsables de rôle soient obligés de comprendre les détails d’implémentation de ces autorisations. Dans la pratique, différents systèmes peuvent appliquer une autorisation autrement. Le connecteur de l’application qui relie le service de synchronisation FIM à l’application détermine la manière dont les changements d’autorisation pour un utilisateur sont transmis à cette application.

Applications

BHOLD implémente une méthode d’application du contrôle d’accès en fonction du rôle (RBAC) dans les applications externes. Autrement dit, quand BHOLD est approvisionné avec les utilisateurs et les autorisations d’une application, il peut associer ces autorisations aux utilisateurs en leur attribuant des rôles, puis en liant les autorisations aux rôles. Le processus en arrière-plan de l’application peut ensuite mapper les autorisations appropriées à ses utilisateurs en fonction du mappage rôle/autorisation de BHOLD.

Développement du modèle de rôle BHOLD Suite

Pour vous aider à développer votre modèle de rôle, BHOLD Suite fournit Model Generator, un outil complet facile à utiliser.

Avant d’utiliser Model Generator, vous devez créer une série de fichiers qui définissent les objets utilisés par Model Generator pour construire le modèle de rôle. Pour plus d’informations sur la création de ces fichiers, consultez les informations de référence techniques sur Microsoft BHOLD Suite.

La première étape d’utilisation de BHOLD Model Generator est d’importer ces fichiers pour charger les blocs de construction de base dans Model Generator. Quand les fichiers sont chargés, vous pouvez spécifier des critères qu’utilise Model Generator pour créer plusieurs classes de rôles :

• Les rôles d’appartenance sont attribués à un utilisateur selon les unités d’organisation auquel il appartient
• Les rôles d’attribut sont attribués à un utilisateur selon ses attributs dans la base de données BHOLD
• Les rôles proposés sont liés à une unité d’organisation, mais doivent être activés pour des utilisateurs spécifiques
• Les rôles de propriété accordent un contrôle utilisateur sur les unités d’organisation et les rôles pour lesquels un propriétaire n’est pas spécifié dans les fichiers importés

Important

Lors du téléchargement de fichiers, cochez la case Conserver le modèle existant uniquement dans les environnements de test. Dans les environnements de production, vous devez utiliser Model Generator pour créer le modèle de rôle initial. Vous ne pouvez pas l’utiliser pour changer un modèle de rôle existant dans la base de données BHOLD.

Une fois que Model Generator a créé ces rôles dans le modèle de rôle, vous pouvez exporter le modèle de rôle dans la base de données BHOLD sous forme de fichier XML.

Fonctionnalités BHOLD avancées

Les sections précédentes ont décrit les fonctionnalités de base du contrôle d’accès en fonction du rôle (RBAC) dans BHOLD. Cette section présente des fonctionnalités supplémentaires de BHOLD susceptibles d’améliorer la sécurité et la flexibilité de l’implémentation de RBAC dans votre organisation. Cette section fournit une vue d’ensemble des fonctionnalités BHOLD suivantes :

• Cardinalité
• Séparation des tâches
• Autorisations adaptées au contexte
• Autorisation basée sur les attributs
• Types d’attributs flexibles

Cardinalité

La cardinalité fait référence à l’implémentation de règles métier conçues pour limiter le nombre de fois où deux entités peuvent être liées entre elles. Dans le cas de BHOLD, les règles de cardinalité peuvent être établies pour des rôles, des autorisations et des utilisateurs.

Vous pouvez configurer un rôle pour limiter les éléments suivants :

• Le nombre maximal d’utilisateurs pour lesquels un rôle proposé peut être activé
• Le nombre maximal de sous-rôles pouvant être liés au rôle
• Le nombre maximal d’autorisations pouvant être liées au rôle

Vous pouvez configurer une autorisation pour limiter les éléments suivants :

• Le nombre maximal de rôles pouvant être liés à l’autorisation
• Le nombre maximal d’utilisateurs pouvant être liés à l’autorisation

Vous pouvez configurer un utilisateur pour limiter les éléments suivants :

• Le nombre maximal de rôles pouvant être liés à l’utilisateur
• Le nombre maximal d’autorisations pouvant être attribuées à l’utilisateur par les attributions de rôle

Séparation des tâches

La séparation des tâches est un principe d’entreprise qui vise à empêcher certains individus à pouvoir effectuer des actions qui ne doivent pas être disponibles pour une même personne. Par exemple, un employé ne doit pas pouvoir demander un paiement et l’autoriser. Le principe de séparation des tâches permet aux organisations d’implémenter un système de freins et contrepoids pour réduire leur exposition aux risques d’erreur et de faute des employés.

BHOLD implémente la séparation des tâches en vous permettant de définir des autorisations incompatibles. Quand ces autorisations sont définies, BHOLD applique la séparation des tâches en empêchant la création de rôles liés aux autorisations incompatibles, qu’ils soient liés directement ou par héritage, et en empêchant les utilisateurs de recevoir plusieurs rôles qui, quand ils sont combinés, accordent des autorisations incompatibles, par attribution directe ou par héritage. Éventuellement, les conflits peuvent être remplacés.

Autorisations adaptées au contexte

En créant des autorisations qui peuvent être changées automatiquement en fonction de l’attribut d’un objet, vous pouvez réduire le nombre total d’autorisations à gérer. Les autorisations adaptées au contexte vous permettent de définir une formule comme attribut d’autorisation qui modifie la façon dont l’autorisation est appliquée par l’application associée. Par exemple, vous pouvez créer une formule qui change l’autorisation d’accès à un dossier de fichiers (à travers un groupe de sécurité associé à la liste de contrôle d’accès du dossier) si un utilisateur appartient à une unité d’organisation contenant des employés à plein temps ou contractuels. Si l’utilisateur est transféré d’une unité d’organisation à une autre, la nouvelle autorisation est appliquée automatiquement et l’ancienne autorisation est désactivée.

La formule des autorisations adaptées au contexte peut interroger les valeurs des attributs qui ont été appliqués à des applications, autorisations, unités d’organisation et utilisateurs.

Autorisation basée sur les attributs

L’autorisation basée sur les attributs est une façon de contrôler si un rôle lié à une unité d’organisation est activé pour un utilisateur particulier dans l’unité d’organisation. Ce type d’autorisation vous permet d’activer automatiquement un rôle uniquement quand certaines règles basées sur les attributs de l’utilisateur sont suivies. Par exemple, vous pouvez lier un rôle à une unité d’organisation qui devient actif pour un utilisateur uniquement si le poste de l’utilisateur correspond au poste défini dans la règle d’autorisation basée sur les attributs. Cela vous évite de devoir activer manuellement un rôle proposé pour un utilisateur. Au lieu de cela, un rôle peut être activé pour tous les utilisateurs d’une unité d’organisation qui ont une valeur d’attribut conforme à la règle d’autorisation basée sur les attributs du rôle. Les règles peuvent être combinées pour qu’un rôle soit activé uniquement quand les attributs d’un utilisateur répondent à toutes les règles d’autorisation basée sur les attributs spécifiées pour le rôle.

Notez que les résultats des tests de règle d’autorisation basée sur les attributs sont limités par les paramètres de cardinalité. Par exemple, si le paramètre de cardinalité d’une règle spécifie qu’un rôle peut être attribué à deux utilisateurs maximum et qu’une règle d’autorisation basée sur les attributs active au contraire un rôle pour quatre utilisateurs, le rôle est activé uniquement pour les deux premiers utilisateurs qui réussissent le test de la règle d’autorisation basée sur les attributs.

Types d’attributs flexibles

Le système d’attributs de BHOLD est très extensible. Vous pouvez définir de nouveaux types d’attributs pour des objets comme les utilisateurs, les unités d’organisation et les rôles. Les attributs peuvent être définis pour avoir des valeurs de type entier, booléen (oui/non), alphanumérique, date, heure et adresses e-mail. Ils peuvent être spécifiés sous forme de valeurs uniques ou de liste de valeurs.

Attestation

BHOLD Suite fournit des outils que vous pouvez utiliser pour vérifier que les utilisateurs individuels ont reçu les autorisations appropriées pour effectuer leurs tâches professionnelles. L’administrateur peut utiliser le portail fourni par le module Attestation BHOLD pour concevoir et gérer le processus d’attestation.

Le processus d’attestation est effectué au moyen de campagnes dans lesquelles des délégués de campagne ont la possibilité et les moyens de vérifier que les utilisateurs dont ils sont responsables ont l’accès approprié aux applications gérées par BHOLD et les autorisations appropriées dans ces applications. Un propriétaire de campagne est désigné pour surveiller la campagne et vérifier qu’elle s’effectue correctement. Une campagne peut être créée pour se produire une seule fois ou de façon récurrente.

En règle générale, le délégué d’une campagne est un responsable qui atteste des droits d’accès des utilisateurs appartenant à une ou plusieurs unités d’organisation dont il est en charge. Les délégués peuvent être sélectionnés automatiquement pour les utilisateurs à attester dans une campagne en fonction des attributs de l’utilisateur, ou ils peuvent être définis en les listant dans un fichier mappant chaque utilisateur à attester dans la campagne à un délégué.

Quand une campagne commence, BHOLD envoie un message de notification par e-mail au propriétaire et aux délégués de la campagne, puis envoie régulièrement des rappels pour les aider à maintenir la progression de la campagne. Les délégués sont dirigés vers un portail de campagne où ils peuvent afficher la liste des utilisateurs dont ils sont chargés et les rôles qui sont attribués à ces derniers. Les délégués peuvent ensuite confirmer s’ils sont responsables de chacun des utilisateurs listés, et approuver ou refuser les droits d’accès de chacun d’eux.

Les propriétaires de campagne utilisent également le portail pour surveiller la progression de la campagne, et les activités de campagne sont journalisées pour permettre aux propriétaires de campagne d’analyser les actions qui ont été effectuées pendant la campagne.

Rapports

Le module BHOLD Reporting vous permet d’afficher des informations dans le modèle de rôle par le biais d’une variété de rapports. Le module BHOLD Reporting fournit un ensemble complet de rapports intégrés et inclut un Assistant qui vous permet de créer des rapports personnalisés de base et avancés. Quand vous exécutez un rapport, vous pouvez immédiatement afficher les résultats ou les enregistrer dans un fichier Microsoft Excel (.xlsx). Pour afficher ce fichier à l’aide de Microsoft Excel 2000, Microsoft Excel 2002 ou Microsoft Excel 2003, vous pouvez télécharger et installer le module de compatibilité Microsoft Office pour les formats de fichiers Word, Excel et PowerPoint.

Vous utilisez le module BHOLD Reporting surtout pour produire des rapports basés sur les informations du rôle en cours. Pour générer des rapports afin d’auditer les changements d’informations d’identité, Forefront Identity Manager 2010 R2 présente une fonctionnalité de création de rapports pour le service FIM qui est implémentée dans l’entrepôt de données de System Center Service Manager. Pour plus d’informations sur la création de rapports FIM, consultez la documentation de Forefront Identity Manager 2010 et Forefront Identity Manager 2010 R2 dans la bibliothèque technique de Forefront Identity Management.

Les catégories couvertes par les rapports intégrés sont les suivantes :

• Administration
• Attestation
• Commandes
• Contrôle d'accès vers l’intérieur
• Journalisation
• Modèle
• Statistiques
• Workflow

Vous pouvez créer des rapports et les ajouter à ces catégories, ou définir vos propres catégories dans lesquelles vous placez des rapports intégrés et personnalisés.

Quand vous générez un rapport, l’Assistant vous guide en fournissant les paramètres suivants :

• Informations d’identification, notamment le nom, la description, la catégorie, l’utilisation et l’audience
• Champs à afficher dans le rapport
• Requêtes qui spécifient les éléments à analyser
• Ordre dans lequel les lignes doivent être triées
• Champs utilisés pour diviser le rapport en sections
• Filtres pour affiner les éléments retournés dans le rapport

À chaque étape de l’Assistant, vous pouvez afficher un aperçu du rapport tel qu’il est défini jusqu'à présent et l’enregistrer si vous n’avez pas besoin de spécifier de paramètres supplémentaires. Vous pouvez également revenir aux étapes précédentes pour changer des paramètres que vous avez déjà spécifiés dans l’Assistant.

Connecteur Access Management

Le module BHOLD Suite Access Management Connector prend en charge la synchronisation initiale et actuelle des données dans BHOLD. Access Management Connector fonctionne avec le service de synchronisation FIM pour déplacer des données entre la base de données principale de BHOLD, le métaverse de MIM ainsi que les applications cibles et les magasins d’identités.

Les versions précédentes de BHOLD nécessitaient plusieurs agents de gestion pour contrôler le flux de données entre MIM et les tables de base de données BHOLD intermédiaires. Dans BHOLD Suite SP1, Access Management Connector vous permet de définir des agents de gestion dans MIM qui fournissent un transfert de données directement entre BHOLD et MIM.

Étapes suivantes

• Guide d’installation de BHOLD
• Informations de référence pour les développeurs BHOLD
• Historique des versions BHOLD