Lors de votre planification, vérifiez que certains objets eDirectory sont répliqués sur les serveurs sur lesquels vous voulez exécuter les pilotes DirXML.
Vous pouvez utiliser les répliques filtrées, tant que tous les objets et attributs dont le pilote a besoin pour lire ou synchroniser sont inclus dans les répliques filtrées.
N'oubliez pas que vous devez attribuer à l'objet pilote DirXML des droits eDirectory suffisants sur les objets qu'il doit synchroniser, soit en attribuant explicitement des droits soit en rendant la sécurité de l'objet Pilote équivalente à un objet qui dispose des droits souhaités.
Un serveur eDirectory qui exécute un pilote DirXML (ou auquel le pilote fait référence, si vous utilisez le chargeur distant) doit contenir une réplique principale ou une réplique en lecture/écriture des éléments suivants :
Vous devez disposer d'un objet Ensemble de pilotes pour chaque serveur qui exécute Identity Manager. Sauf en cas de besoins spécifiques, n'associez pas plusieurs serveurs au même objet Ensemble de pilotes.
NOTE: lorsque vous créez un objet Ensemble de pilotes, le paramètre par défaut doit créer une partition séparée, mais cela n'est pas obligatoire.
L'objet Serveur est nécessaire parce qu'il permet au pilote de générer des paires de clés pour les objets. Il est également important pour l'authentification du chargeur distant.
Le pilote ne peut pas synchroniser d'objet sauf si une réplique de ces objets se trouve sur le même serveur que le pilote. En fait, un pilote DirXML synchronisera les objets dans tous les conteneurs répliqués sur le serveur sauf si vous créez des règles indiquant le contraire (règles de filtrage d'étendue).
Si vous voulez qu'un pilote synchronise, par exemple, tous les objets Utilisateur, la façon la plus simple est d'utiliser une instance du pilote sur un serveur qui contient une réplique principale ou une réplique en lecture/écriture de tous vos utilisateurs.
Toutefois, dans de nombreux environnements, une réplique de tous les utilisateurs ne se trouve pas sur un seul serveur. L'ensemble complet des utilisateurs est plutôt réparti sur plusieurs serveurs. Dans ce cas, deux choix se présentent :
Des utilisateurs regroupés sur un seul serveur :vous pouvez créer un seul serveur qui contient tous les utilisateurs en ajoutant des répliques à un serveur existant. Vous pouvez utiliser des répliques filtrées pour réduire si nécessaire la taille de la base de données eDirectory, tant que les objets et les attributs utilisateur nécessaires font partie des répliques filtrées.
Utiliser plusieurs instances du pilote sur plusieurs serveurs, avec le filtrage d'étendue :Si vous ne voulez pas regrouper des utilisateurs sur un seul serveur, vous devrez déterminer l'ensemble de serveurs qui contiendra tous les utilisateurs et configurer une instance du pilote DirXML sur chacun de ces serveurs.
Pour éviter que des instances séparées d'un pilote n'essaient de synchroniser les mêmes utilisateurs, utilisez le filtrage d'étendue pour définir les utilisateurs que chaque instance du pilote synchronisera. Le filtrage d'étendue signifie que vous ajoutez des règles à chaque pilote pour limiter l'étendue de la gestion par le pilote de conteneurs spécifiques. Reportez-vous à la section Gestion des utilisateurs sur différents serveurs avec le filtrage d'étendue .
Les pilotes DirXML ne requièrent pas que vous spécifiez des objets Modèle eDirectory pour la création d'utilisateurs. Toutefois, si vous spécifiez 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 s'exécute.
Par exemple, si vous avez créé un conteneur nommé Utilisateurs inactifs pour contenir des comptes utilisateur désactivés, vous devez disposer d'une réplique principale ou une réplique en lecture/écriture (de préférence une réplique principale) de ce conteneur sur le serveur sur lequel le pilote s'exécute.
Si les autres objets ne doivent être lus que par le pilote et ne doivent pas être modifiés, la réplique pour ces objets sur le serveur peut être une réplique en lecture seule.
Le filtrage d'étendue signifie que vous ajoutez des règles à chaque pilote pour limiter l'étendue des opérations du pilote sur des conteneurs spécifiques. Voici deux situations dans lesquelles vous devrez utiliser le filtrage d'étendue :
Un pilote DirXML par défaut synchronise les objets dans tous les conteneurs répliqués sur le serveur sur lequel il s'exécute. Pour réduire cette étendue, créez des règles de filtrage d'étendue.
Pour synchroniser tous les utilisateurs sans avoir à les répliquer sur un seul serveur, déterminez l'ensemble de serveurs qui contient tous les utilisateurs, puis créez une instance du pilote DirXML sur chacun de ces serveurs. Pour éviter que deux instances du pilote essaient de synchroniser les mêmes utilisateurs, utilisez le filtrage d'étendue pour définir les utilisateurs que chaque instance du pilote synchronisera.
NOTE: utilisez le filtrage d'étendue même si les répliques de votre serveur ne se chevauchent pas. Il est possible que des répliques soient ultérieurement ajoutées à vos serveurs et un chevauchement involontairement créé. Si la fonction de filtrage d'étendue est activée, vos pilotes DirXML n'essaieront pas de synchroniser les mêmes utilisateurs, même si des répliques sont plus tard ajoutées à vos serveurs.
Voici un exemple de l'utilisation du filtrage d'étendue.
L'illustration suivante montre une arborescence avec trois conteneurs qui contiennent des utilisateurs : Marketing, Finance et Développement. Elle montre également un conteneur Identity Manager qui contient les ensembles de pilotes. Chacun de ces conteneurs représente une partition distincte.
Dans cet exemple, l'administrateur eDirectory dispose de deux serveurs eDirectory, le serveur A et le serveur B, représentés dans l'illustration suivante. Aucun serveur ne contient de copie de tous les utilisateurs. Chaque serveur contient deux des trois partitions ; il y a donc un chevauchement dans l'étendue de ce que les serveurs contiennent.
L'administrateur veut que tous les utilisateurs de l'arborescence soient synchronisés par le pilote GroupWise, mais ne veut pas de répliques regroupés d'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 eDirectory.
Le serveur A contient des répliques des conteneurs Marketing et Finance. Le serveur comporte également une réplique du conteneur Gestion des identités, qui contient l'ensemble de pilotes du serveur A et l'objet Pilote GroupWise du serveur A.
Le serveur B contient des répliques des conteneurs Développement et Finance ; le conteneur Gestion des identités contient l'ensemble de pilotes du serveur B et l'objet Pilote GroupWise du serveur B.
Le serveur A et le serveur B contiennent tous deux une réplique du conteneur Finance. Les deux serveurs contiennent donc l'utilisateur JBassad, qui se trouve dans le conteneur Finance. Sans filtrage d'étendue, le pilote GroupWise du serveur A et le pilote GroupWise du serveur B synchroniseraient JBassad.
L'illustration suivante montre que le filtrage d'étendue empêche les deux instances du pilote de gérer le même utilisateur ; en effet, il définit quel pilote synchronise chaque conteneur.
Voici un exemple de la manière de créer une règle pour le filtrage d'étendue. Placez la règle dans la feuille de style Transformation d'événement du canal Abonné.
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:jstring="http://www.novell.com/nxsl/java/java.lang.String"
exclude-result-prefixes="jstring">
<!--
To select different containers for scoping, add/delete/modify the <value>
elements in the body of the variable "in-scope-containers-rtf"
Note that if the container is not in the root of the tree, then the DN
(minus the tree name) of the container must be specified, e.g.,
Corporate\Executives
Note: THESE MUST BE ENTERED IN THE TABLE AS ALL UPPERCASE
-->
<xsl:variable name="in-scope-containers-rtf">
<value>CORPORATE\USERS\ACTIVE</value>
<value>CORPORATE\USERS\INACTIVE</value>
</xsl:variable>
<xsl:variable name="in-scope-containers" select="document('')/xsl:transform/xsl:variable[@name='in-scope-containers-rtf']/value"/>
<!--
"identity" transformation - copies unchanged everything not explicitly
matched by other templates
-->
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- throw away events that are out of scope -->
<xsl:template match="input/*[@src-dn]">
<xsl:variable name="in-scope">
<xsl:call-template name="in-scope"/>
</xsl:variable>
<xsl:choose>
<xsl:when test="$in-scope = '1'">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:when>
<xsl:otherwise>
<xsl:message>
<status level="warning">Operation vetoed by Event Transformation
Rule - out of scope</status>
</xsl:message>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<!--
check to see if an object is in the scope defined by the variable
"in-scope-containers"
-->
<xsl:template name="in-scope">
<!-- validate that the container is in scope -->
<xsl:variable name="src-dn" select="substring-after(substring-after(@src-dn,'\'),'\')"/>
<xsl:variable name="src-dn-i" select="jstring:lastIndexOf($src-dn,'\')"/>
<xsl:if test="$src-dn-i != -1">
<xsl:variable name="src-dn-container" select="jstring:substring($src-dn, 0, $src-dn-i)"/>
<!--
the following test takes advantage of the XPath existential
quantification semantics:
basically, if one node in the node-set has a string value that matches
the string, then the statement is true
-->
<xsl:if test="jstring:toUpperCase($src-dn-container) = $in-scope-containers">
<xsl:value-of select="'1'"/>
</xsl:if>
</xsl:if>
</xsl:template>
</xsl:transform>