Replicating the Objects that Identity Manager Needs on the Server

As part of your planning, you need to make sure that certain eDirectory objects are replicated on servers where you want to run DirXML drivers.

You can use filtered replicas, as long as all of the objects and attributes that the driver needs to read or synchronize are included in the filtered replica.

Keep in mind that you must give the DirXML Driver object sufficient eDirectory rights to any objects it is to synchronize, either by explicitly granting it rights or by making the Driver object security equivalent to an object that has the desired rights.

An eDirectory server that is running a DirXML driver (or that the driver refers to, if you are using Remote Loader) must hold a master or read-write replica of the following:

• The Driver Set object for that server.

  You should have one Driver Set object for each server that is running Identity Manager. Unless you have specific needs, don't associate more than one server with the same Driver Set object.

  NOTE:  When creating a Driver Set object, the default setting is to create a separate partition, but this is not required.

• The Server object for that server.

  The Server object is necessary because it allows the driver to generate key pairs for objects. It also is important for remote loader authentication.

• The objects that you want this instance of the driver to synchronize.

  The driver can't synchronize objects unless a replica of those objects is on the same server as the driver. In fact, a DirXML driver will synchronize the objects in all the containers that are replicated on the server unless you create rules to specify otherwise (rules for "scope filtering").

  If you want a driver to synchronize all user objects, for example, the simplest way is to use one instance of the driver on a server that holds a master or read/write replica of all your users.

  However, many environments don't have a single server that contains a replica of all the users. Instead, the complete set of users is spread across multiple servers. In this case, you have two choices:

  • Aggregate users onto a single server. You can create a single server that holds all users by adding replicas to an existing server. Filtered replicas can be used to reduce the size of the eDirectory database if desired, as long as the necessary user objects and attributes are part of the filtered replica.

  • Use multiple instances of the driver on multiple servers, with scope filtering. If you don't want to aggregate users onto a single server, you will need to determine which set of servers holds all the users, and set up one instance of the DirXML driver on each of those servers.

    To prevent separate instances of a driver from trying to synchronize the same users, you will need to use "scope filtering" to define which users each instance of the driver should synchronize. Scope filtering means that you add rules to each driver to limit the scope of the driver's management to specific containers. See Managing Users on Different Servers Using Scope Filtering .

• The Template objects you want the driver to use when creating users, if you choose to use templates.

  DirXML drivers do not require you to specify eDirectory Template objects for creating users. But if you specify that a driver should use a template when creating users in eDirectory, the Template object must be replicated on the server where the driver is running.

• Any containers you want the DirXML driver to use for managing users.

  For example, if you have created a container named Inactive Users to hold user accounts that have been disabled, you must have a master or read/write replica (preferably master replica) of that container on the server where the driver is running.

• Any other objects that the driver needs to refer to (for example, work order objects for the Avaya PBX driver).

  If the other objects are only to be read by the driver, not changed, the replica for those objects on the server can be a read-only replica.

Managing Users on Different Servers Using Scope Filtering

Scope filtering means adding rules to each driver to limit the scope of the driver's actions to specific containers. The following are two situations in which you would need to use scope filtering:

• You want the driver to synchronize only users that are in a particular container.

  A DirXML driver by default will synchronize objects in all the containers that are replicated on the server where it is running. To narrow that scope, you must create scope filtering rules.

• You want a DirXML driver to synchronize all users, but you don't want all users to be replicated on the same server.

  To synchronize all users without having them replicated on one single server, you need to determine which set of servers holds all the users, and then create an instance of the DirXML driver on each of those servers. To prevent two instances of the driver from trying to synchronize the same users, you will need to use scope filtering to define which users each instance of the driver should synchronize.

  NOTE:  You should use scope filtering even if your server's replicas don't currently overlap. In the future, replicas could be added to your servers and an overlap could be created unintentionally. If you have scope filtering in place, your DirXML drivers will not try to synchronize the same users, even if replicas are added to your servers in the future.

Here's an example of how scope filtering is used.

The following illustration shows a tree with three containers that hold users: Marketing, Finance, and Development. It also shows an Identity Manager container that holds the driver sets. Each of these containers is a separate partition.

In this example, the eDirectory administrator has two eDirectory servers, Server A and Server B, shown in the next illustration. Neither server contains a copy of all the users. Each server contains two of the three partitions, so the scope of what the servers hold is overlapping.

The administrator wants all the users in the tree to be synchronized by the GroupWise driver, but does not want to aggregate replicas of the users onto a single server. He chooses instead to use two instances of the GroupWise driver, one on each server. He installs Identity Manager and sets up the GroupWise driver on each eDirectory server.

Server A holds replicas of the Marketing and Finance containers. Also on the server is a replica of the Identity Management container, which holds the Driver Set for Server A and the GroupWise Driver object for Server A.

Server B holds replicas of the Development and Finance containers, and the Identity Management container holding the Driver Set for Server B and the GroupWise Driver object for Server B.

Because Server A and Server B both hold a replica of the Finance container, both servers hold the user JBassad, who is in the Finance container. Without scope filtering, both GroupWise Driver A and GroupWise Driver B would synchronize JBassad.

The next illustration shows that scope filtering prevents the two instances of the driver from managing the same user, because it defines which drivers synchronize each container.

Here is a sample of how you would create a rule for scope filtering. You would place the rule in the Subscriber Event Transformation style sheet.

<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>