Replication agreements

Edit online

You can use the information provided here to know more replication agreements

A replication agreement is an entry in the directory with the object class ibm-replicationAgreement created beneath a replica subentry to define replication from the server represented by the subentry to another server. These objects are similar to the replicaObject entries used by earlier versions of IBM® Security Verify Directory. The replication agreement consists of the following items:
  • A user friendly name, used as the naming attribute for the agreement.
  • An LDAP URL specifying the server, port number, and whether SSL should be used.
  • The consumer server ID, if known -- 'unknown' for a server whose server ID is not known.
  • The DN of an object containing the credentials used by the supplier to bind to the consumer.
  • An optional DN pointer to an object containing the schedule information for replication.If the attribute is not present, changes are replicated immediately.
  • Replication method (single threaded or multi-threaded).
  • Number of consumer: For a replication agreement using the single-threaded replication method, the number of consumer connections is always one, the attribute value is ignored. For an agreement using multi-threaded replication, the number of connections can be configured from 1 to 32. If no value is specified on the agreement, the number of consumer connections is set to one.
    Note: For the cn=ibmpolicies subtree, all replication agreements will use the single-threaded replication method and one consumer connection, ignoring the attribute values.
The user friendly name might be the consumer server name or some other descriptive string.

To aid in enforcing the accuracy of the data, when the supplier binds to the consumer, it retrieves the server ID from the root DSE and compares it to the value in the agreement.A warning is logged if the server IDs do not match.

The consumer server ID is used by the Web Administration Tool to traverse the topology.Given the consumer's server ID, the Web Administration Tool can find the corresponding subentry and its agreements.

Because the replication agreement can be replicated, a DN to a credentials object is used.This allows the credentials to be stored in a nonreplicated area of the directory.Replicating the credentials objects (from which 'clear text' credentials must be obtainable) represents a potential security exposure.The cn=localhost suffix is an appropriate default location for creating credentials objects.Use of a separate object also makes it easier to support various authentication methods; new object classes can be created rather thantrying to make sense of numerous optional attributes.

Object classes are defined for each of the supported authentication methods:
  • Simple bind
  • SASL EXTERNAL mechanism with SSL
  • Kerberos authentication

You can designate that part of a replicated subtree not be replicated by adding the ibm-replicationContext auxiliary class to the root of the subtree, without defining any replica subentries.