2.3 Planification des aspects techniques de la mise en oeuvre d'Identity Manager

2.3.1 Utilisation du concepteur

Identity Manager est fourni avec un utilitaire appelé Designer (concepteur). Le concepteur permet de concevoir, tester et documenter les pilotes Identity Manager. Le concepteur permet de visualiser le flux de la synchronisation des mots de passe et des données. Pour plus d'informations, reportez-vous au Guide d'administration de la version 2.1 du concepteur pour Identity Manager 3.5.1.

2.3.2 Réplication des objets dont Identity Manager a besoin sur le serveur

Si votre environnement Identity Manager demande plusieurs serveurs afin d'exécuter plusieurs pilotes Identity Manager, votre plan doit veiller à ce que certains objets eDirectory soient répliqués sur les serveurs sur lesquels vous voulez exécuter ces pilotes Identity Manager.

Vous pouvez utiliser des répliques filtrées, à condition que tous les objets et attributs dont le pilote a besoin pour lire ou synchroniser soient inclus dans la réplique filtrée.

N'oubliez pas que vous devez donner à l'objet du pilote Identity Manager des droits eDirectory suffisants sur tout objet qu'il doit synchroniser, soit en lui accordant explicitement des droits soit en rendant la sécurité de l'objet du pilote équivalente à un objet qui dispose des droits souhaités.

Un serveur eDirectory qui exécute un pilote Identity Manager (ou auquel le pilote fait référence, si vous utilisez le chargeur distant) doit contenir une réplique maîtresse ou lisible et inscriptible de ce qui suit :

  • L'objet Ensemble des pilotes de ce serveur.

    Vous devez avoir un objet Ensemble des pilotes pour chaque serveur qui exécute Identity Manager. À moins d'avoir des besoins particuliers, n'associez pas plusieurs serveurs au même objet Ensemble des pilotes.

    REMARQUE :lors de la création d'un objet Ensemble des pilotes, le paramètre par défaut est la création d'une partition séparée. Novell recommande la création d'une partition séparée sur l'objet Ensemble des pilotes. Pour que Identity Manager fonctionne, le serveur doit comporter une réplique complète de l'objet Ensemble des pilotes. Si le serveur comprend une réplique complète de l'emplacement où l'objet Ensemble des pilotes est installé, la partition n'est pas nécessaire.

  • L'objet Serveur de ce serveur.

    L'objet Serveur est nécessaire car il permet au pilote de générer des paires clés pour les objets. Il est également important pour l'authentification du chargeur distant.

  • Les objets que vous souhaitez que cette instance du pilote synchronise.

    Le pilote ne peut pas synchroniser des objets à moins qu'une réplique de ces objets se trouve sur le même serveur que le pilote. En fait, un pilote Identity Manager synchronise des objets dans tous les conteneurs répliqués sur le serveur à moins de créer des règles d'indication contraire (règles de filtrage des étendues).

    Si vous voulez qu'un pilote synchronise tous les objets utilisateur, par exemple, la manière la plus simple consiste à utiliser une instance du pilote sur un serveur qui contient une réplique maîtresse ou lisible/inscriptible de tous vos utilisateurs.

    Cependant, de nombreux environnements n'ont pas de serveur avec une réplique de tous les utilisateurs. L'ensemble des utilisateurs est plutôt réparti sur plusieurs serveurs. Dans ce cas, vous disposez de trois options :

    • Regrouper les utilisateurs sur un seul serveur. Pour créer un seul serveur avec tous les utilisateurs, ajoutez des répliques sur un serveur existant. Les répliques filtrées peuvent être utilisées pour réduire la taille de la base de données eDirectory si nécessaire, à condition que les objets et attributs utilisateur nécessaires fassent partie de la réplique filtrée.

    • Utilisez plusieurs instances du pilote sur plusieurs serveurs, avec un filtrage des étendues. Si vous ne voulez pas regrouper les utilisateurs sur un seul serveur, vous devez déterminer l'ensemble de serveurs qui contiendra tous les utilisateurs et configurer une instance du pilote Identity Manager sur chacun de ces serveurs.

      Pour éviter que les instances séparées d'un pilote tentent de synchroniser les mêmes utilisateurs, vous devez utiliser le filtrage des étendues pour définir les utilisateurs que chaque instance du pilote doit synchroniser. Le filtrage des étendues signifie que vous ajoutez des règles à chaque pilote pour limiter l'étendue de la gestion du pilote à des conteneurs spécifiques. Reportez-vous à Utilisation du filtrage de l'étendue pour gérer les utilisateurs sur des serveurs différents.

    • Utilisez plusieurs instances du pilote sur plusieurs serveurs, sans filtrage des étendues. Si vous voulez exécuter plusieurs instances d'un pilote sur différents serveurs sans utiliser de répliques filtrées, vous devez définir des stratégies sur les différentes instances du pilote qui permettent au pilote de traiter différents ensembles d'objets au sein du même coffre-fort d'identité.

  • Les objets Modèle que vous voulez que le pilote utilise lors de la création d'utilisateurs, si vous choisissez d'utiliser des modèles.

    Les pilotes Identity Manager n'exigent pas que vous indiquiez des objets Modèle eDirectory pour créer des utilisateurs. Cependant, si vous indiquez qu'un pilote doit utiliser un modèle lors de la création d'utilisateurs dans eDirectory, l'objet Modèle doit être répliqué sur le serveur sur lequel le pilote est exécuté.

  • Tout conteneur que vous voulez que le pilote Identity Manager utilise pour la gestion des utilisateurs.

    Par exemple, si vous avez créé un conteneur nommé Utilisateurs inactifs qui contient les comptes utilisateur désactivés, vous devez avoir une réplique maîtresse ou lisible/inscriptible (de préférence une réplique maîtresse) de ce conteneur sur le serveur sur lequel le pilote est exécuté.

  • Tout autre objet auquel le pilote doit se rapporter (par exemple, les objets Bon de travail pour le pilote Avaya* PBX).

    Si les autres objets ne doivent être que lus par le pilote, la réplique de ces objets sur le serveur peut être une réplique en lecture seule.

2.3.3 Utilisation du filtrage de l'étendue pour gérer les utilisateurs sur des serveurs différents

Le filtrage des étendues signifie l'ajout de règles à chaque pilote pour limiter l'étendue des actions du pilote à des conteneurs spécifiques. Voici deux situations dans lesquelles vous devez utiliser le filtrage des étendues :

  • Vous voulez que le pilote ne synchronise que les utilisateurs d'un conteneur particulier.

    Par défaut, un pilote Identity Manager synchronise les objets de tous les conteneurs répliqués sur le serveur sur lequel il est exécuté. Pour limiter cette étendue, vous devez créer des règles de filtrage des étendues.

  • Vous voulez qu'un pilote Identity Manager synchronise tous les utilisateurs, mais vous ne voulez pas que tous les utilisateurs soient répliqués sur le même serveur.

    Pour synchroniser tous les utilisateurs sans les répliquer sur un seul serveur, vous devez déterminer l'ensemble de serveurs qui contient tous les utilisateurs, puis créer une instance du pilote Identity Manager sur chacun de ces serveurs. Pour éviter que deux instances du pilote tentent de synchroniser les mêmes utilisateurs, vous devez utiliser le filtrage des étendues pour définir les utilisateurs que chaque instance du pilote doit synchroniser.

    REMARQUE :vous devez utiliser le filtrage des étendues même si les répliques de votre serveur ne sont pas en chevauchement pour l'instant. À l'avenir, des répliques peuvent être ajoutées à vos serveurs et un chevauchement peut être créé involontairement. Si le filtrage des étendues est en place, vos pilotes Identity Manager ne tentent pas de synchroniser les mêmes utilisateurs, même si des répliques sont ajoutées à vos serveurs à l'avenir.

Voici un exemple d'utilisation du filtrage des étendues :

L'illustration suivante montre un coffre-fort d'identité avec trois conteneurs d'utilisateurs : Marketing, Finance et Développement. Elle montre également un conteneur Identity Manager qui contient les ensembles de pilotes. Chacun de ces conteneurs constitue une partition distincte.

Figure 2-5 Exemple d'arborescence de filtrage des étendues

Dans cet exemple, l'administrateur Identity Manager a deux serveurs de coffre-fort d'identité, le serveur A et le serveur B, tel qu'illustré dans Figure 2-6. Aucun des serveurs ne contient une copie de tous les utilisateurs. Chaque serveur contient deux des trois partitions, l'étendue de ce que les serveurs peuvent contenir est donc en chevauchement.

L'administrateur souhaite que tous les utilisateurs de l'arborescence soient synchronisés par le pilote GroupWise®, mais veut éviter d'avoir à regrouper les répliques des utilisateurs sur un seul serveur. Il choisit plutôt d'utiliser deux instances du pilote GroupWise, une sur chaque serveur. Il installe Identity Manager et configure le pilote GroupWise sur chaque serveur Identity Manager.

Le serveur A contient des répliques des conteneurs Marketing et Finance. Se trouve également sur le serveur une réplique du conteneur Gestion de l'identité, qui contient l'ensemble de pilotes du serveur A et l'objet pilote GroupWise du serveur A.

Le serveur B contient des réplications des conteneurs Développement et Finance, et le conteneur Gestion de l'identité contenant l'ensemble de pilotes du serveur B et l'objet pilote GroupWise du serveur B.

Comme le serveur A et le serveur B contiennent une réplique du conteneur Finance, ils contiennent tous deux l'utilisateur JBassad, qui est dans le conteneur Finance. Sans filtrage des étendues, le pilote GroupWise A et le pilote GroupWise B synchroniseraient JBassad.

Figure 2-6 Deux serveurs avec des répliques en chevauchement, sans filtrage des étendues

L'illustration suivante montre que le filtrage des étendues empêche les deux instances du pilote de gérer le même utilisateur, car il définit les pilotes qui synchronisent chaque conteneur.

Figure 2-7 Le filtrage des étendues définit les pilotes qui synchronisent chaque conteneur

Identity Manager 3.5.1 comporte des règles prédéfinies. Deux règles aident au filtrage des étendues. « Transformation de l'événement - Filtrage des étendues - Inclure des sous-arborescences » et « Transformation de l'événement - Filtrage des étendues - Exclure les sous-arborescences » documentés dans la Présentation des stratégies d'Identity Manager 3.5.1.

Dans cet exemple, vous utiliseriez la règle prédéfinie Inclure les sous-arborescences pour le serveur A et le serveur B. Vous définiriez l'étendue de chaque pilote différemment de façon à ce qu'ils ne synchronisent que les utilisateurs des conteneurs indiqués. Le serveur A synchroniserait le conteneur Marketing et Finance. Le serveur B synchroniserait le conteneur Développement.