3.3 Instructions pour eDirectory

eDirectory correspond au coffre-fort d'identité qui conserve les objets synchronisés via la solution Identity Manager. Les sections suivantes contiennent des instructions pour vous aider à planifier votre déploiement eDirectory.

3.3.1 Objets Identity Manager dans eDirectory

La liste suivante répertorie les principaux objets Identity Manager stockés dans eDirectory et les relations qui les unissent. L'installation d'Identity Manager ne crée aucun objet. Les objets Identity Manager sont créés pendant la configuration de la solution Identity Manager.

  • Ensemble de pilotes : un ensemble de pilotes est un conteneur pour les pilotes Identity Manager et les objets de bibliothèque. Vous ne pouvez activer qu'un seul ensemble de pilotes à la fois sur un serveur. Cependant, plusieurs serveurs peuvent être associés à un même ensemble de pilotes. De plus, un pilote peut être associé à plus d'un serveur à la fois. Toutefois, le pilote ne doit être exécuté que sur un serveur à la fois. Il doit être à l'état désactivé sur les autres serveurs. Le serveur méta-annuaire doit être installé sur tous les serveurs associés à un ensemble de pilotes.

  • Bibliothèque : l'objet de bibliothèque est un espace de stockage des stratégies souvent utilisées et pouvant être référencées depuis plusieurs sites. La bibliothèque est stockée dans l'ensemble de pilotes. Vous pouvez placer une stratégie dans la bibliothèque, de façon à ce qu'elle puisse être référencée par chaque pilote de l'ensemble.

  • Pilote : un pilote assure la connexion entre une application et le coffre-fort d'identité. Il permet également de synchroniser et de partager des données entre différents systèmes. Le pilote est conservé dans l'ensemble de pilotes.

  • Travail : un travail permet d'automatiser une tâche récurrente. Par exemple, un travail peut configurer un système afin qu'il désactive un compte un jour donné ou qu'il initie un workflow pour demander l'extension de l'accès d'une personne à une ressource de l'entreprise. Le travail est stocké dans l'ensemble de pilotes.

3.3.2 Réplication des objets nécessaires à Identity Manager sur le serveur

Si votre environnement Identity Manager nécessite plusieurs serveurs afin d'exécuter plusieurs pilotes Identity Manager, votre plan doit garantir que certains objets eDirectory sont répliqués sur les serveurs sur lesquels vous voulez exécuter ces pilotes.

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 exécutant 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 lecture-écriture des éléments suivants :

  • 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 :lorsque vous créez un objet Ensemble de pilotes, une partition distincte est créée par défaut. 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. La partition n'est pas obligatoire si le serveur dispose d'une réplique complète de l'emplacement d'installation de l'objet Ensemble des pilotes.

  • 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 les objets dans tous les conteneurs qui sont répliqués sur le serveur à moins que vous ne créiez des règles pour le filtrage des étendues indiquant autre chose.

    Ainsi, si vous souhaitez qu'un pilote synchronise tous les objets utilisateur, la manière la plus simple consiste à utiliser une instance du pilote sur un serveur détenant une réplique maîtresse ou lecture-écriture 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 à la section 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.

3.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 conservant les ensembles des pilotes. Chacun de ces conteneurs constitue une partition distincte.

Figure 3-4 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 la Figure 3-5. 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 ne veut pas 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. Le serveur contient également une réplique du conteneur Identity Manager, qui stocke l'ensemble des pilotes pour le serveur A et l'objet de pilote GroupWise pour le serveur A.

Le serveur B contient des répliques des conteneurs Développement et Finance et le conteneur Gestion des identités conservant l'ensemble des pilotes pour le Serveur B et l'objet pilote GroupWise pour le 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 3-5 Deux serveurs avec des répliques qui se chevauchent, 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 3-6 Le filtrage des étendues définit les pilotes qui synchronisent chaque conteneur

Identity Manager comporte des règles prédéfinies. Deux règles permettent de filtrer les étendues. Les stratégies Transformation de l'événement - Filtrage de l'étendue - Inclure les sous-arborescences et Transformation de l'événement - Filtrage de l'étendue - Exclure les sous-arborescences sont documentées dans la section Understanding Policies for Identity Manager 4.0.1 (Présentation des stratégies d'Identity Manager 4.0).

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.