If your Identity Manager environment calls for multiple servers in order to run multiple Identity Manager drivers, your plan should make sure that certain eDirectory objects are replicated on servers where you want to run these Identity Manager 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 Identity Manager 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 an Identity Manager driver (or that the driver refers to, if you are using the 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 you create a Driver Set object, the default setting is to create a separate partition. NetIQ recommends creating a separate partition on the Driver Set object. For Identity Manager to function, the server is required to hold a full replica of the Driver Set object. If the server has a full replica of the location where the Driver Set object is installed, the partition 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 is also 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, an Identity Manager driver synchronizes the objects in all the containers that are replicated on the server unless you create rules for scope filtering to specify otherwise.
For example, if you want a driver to synchronize all user objects, 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 three 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 need to determine which set of servers holds all the users, and set up one instance of the Identity Manager driver on each of those servers.
To prevent separate instances of a driver from trying to synchronize the same users, you 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 Using Scope Filtering to Manage Users on Different Servers.
Use multiple instances of the driver on multiple servers, without scope filtering. If you want to have multiple instances of a driver running on different servers without using filtered replicas, you need to define policies on the different driver instances that enable the driver to process different sets of objects within the same Identity Vault.
The Template objects you want the driver to use when creating users, if you choose to use templates.
Identity Manager drivers do not require you to specify eDirectory Template objects for creating users. However, 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 Identity Manager 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 a 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 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.