Secure replication

Edit online

You can configure different secure replication topologies in Directory Server, such as Peer-Peer, Master-Replica-Forwarder, and Gateways by using simple bind, SSL with certificates or Kerberos authentication mechanism.

A prerequisite for configuring secure replication over SSL or Kerberos is knowledge of replication-specific internal object classes and attributes. You must know how to set up replication topologies by using manual and graphical user interface (GUI) tools and configure LDAP replication.

Modes of replication

You can use the following modes to configure each server that is participating in a specified replication topology to communicate with other servers in the topology, irrespective of its role.

Simple Replication: Communication between the Supplier and Consumer takes place over an unencrypted channel and authentication takes place by using bind DN and credentials.
Replication over SSL: Communication between the Supplier and Consumer takes place over an encrypted channel. Authentication is done through bindDN and credentials or SSL certificates.
Replication by using Kerberos authentication mechanism: Standard Kerberos authentication method is used by the Supplier and Consumer. Only AIX® servers can be configured to participate in this form of replication. Directory Server does not support Kerberos configuration on other operating systems.

The SSL and Kerberos modes of replication provide security advantages for most production environments as compared to simple replication. The following sections describe the method that you can use to set up secure replication.

Replication over SSL

The following example shows how to configure a replication topology with a master and a single replica by using SSL. The steps for configuring replication by using SSL are similar to setting up replication without SSL until the step of adding a replication agreement. For steps to configure replication without SSL, see the previous topics in the section, Administering > Server Administration > Replication in the IBM® Security Directory Suite documentation.

On the Master or Supplier:

Identify the suffix or subentry to be replicated. Add the ibm-replicationContext auxiliary object class to it to make it a replication context.
Add an ibm-replicaGroup entry under ibm-replicationContext.
Add an ibm-replicationSubEntry entry to the ibm-replicaGroup entry.
Add an ibm-replicationAgreement entry under the ibm-replicationSubEntry entry. For replication over SSL, the type of replication agreement entry is shown here:
```
dn: cn=replica1,ibm-replicaServerId=<serverid of master>,ibm-replicaGroup=default,<suffix>
objectclass: top
objectclass: ibm-replicationAgreement
cn: replica1
ibm-replicaConsumerId: <serverid_of_consumer>
ibm-replicaUrl: ldaps://<replica1-IP:secure-port>
ibm-replicaCredentialsDN: <dn_of_credential_entry>
description: Replication agreement from master to replica1
```
Each server in the replication topology has a unique identifier called serverid. This ID is in the configuration file of the corresponding server under dn: cn=Configuration. For a running server, you can find this ID by doing a rootDSE search against the server. A rootDSE search is represented by a search scope of base and search base of "" (empty string). Assuming that server1 is running Directory Server on port port1, the corresponding rootDSE search would be:
```
idsldapsearch —h <server1> —p <port1> —s base —b "" objectclass=*
```
Note: In the agreement entry, a requirement for replication over SSL is that the LDAP URL must be of the type ldaps:// and not ldap://. The replication credential entry for the attribute ibm-replicaCredentialsDN can be of the type ibm-replicationCredentialsSimple or ibm-replicationCredentialsExternal depending on the authentication method to be used.

Add replication credential entry to the Directory Information Tree (DIT). The following example shows a credential entry for Simple Replication that uses bind DN and password.

Note: This DN must be unique and cannot be same as any already existing DN's.

dn: cn=replica1BindCredentials,cn=localhost
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=master
replicaCredentials: master
description: Bind Credentials on master to be used to bind to other servers.

The following example shows a credential entry by using certificates:

dn: cn=replica1BindCredentials, c=localhost
objectclass: ibm-replicationCredentialsExternal
cn: ReplicaBindCredentials
ibm-replicaKeyfile: path_to_the_kdb_file
ibm-replicaKeylabel: Key_Label
ibm-replicaKeypwd: password_of_kdb_file
description: Bind Credentials on master to be used to bind to other servers.

On the Replica or Consumer

If the Master (Supplier) needs to contact the Replica (Consumer) by using simple bindDN and password, add the following entries to the replica's configuration file (ibmslapd.conf):

dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: <bind_dn_in_servers_creds_entry>
ibm-slapdMasterPW: <password_in_servers-creds_entry>
objectclass: ibm-slapdReplication

If the Master needs to contact the Replica by using certificates, then add the following entries to the replica's configuration file (ibmslapd.conf):
```
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: <subject_DN_of_cert_in_kdb_file>
objectclass: ibm-slapdReplication
```

Replication over Kerberos

The following example shows how to configure a replication topology that consists of a master and a single replica by using Kerberos. The steps to configure replication by using Kerberos are similar to setting up replication with SSL until the step of adding a replication agreement. For steps to configure replication without SSL, see the previous topics in the section, Administering > Server Administration > Replication in the IBM Security Directory Suite documentation.

For setting up replication through Kerberos, both of the servers, supplier and consumer, must be enabled to accept Kerberos authentication.

On Master or Supplier:

Identify the suffix or subentry to be replicated. Add the ibm-replicationContext auxiliary object class to it to make it a replication context.
Add an ibm-replicaGroup entry under ibm-replicationContext.
Add an ibm-replicationSubEntry entry to the ibm-replicaGroup entry.

Add an ibm-replicationAgreement under the ibm-replicationSubEntry entry. For replication over Kerberos, the type of replication agreement entry is shown here:

dn: cn=replica1,ibm-replicaServerId=<serverid of master>,ibm-replicaGroup=default,<suffix>
objectclass: top
objectclass: ibm-replicationAgreement
cn: replica1
ibm-replicaConsumerId: <server_id_of_consumer>
ibm-replicaUrl: ldap://<replica1-IP:simple-port>
ibm-replicaCredentialsDN: <dn_of_credential_entry>
description: Replication agreement from master to replica1

Add replication credential entry to the DIT. The following example shows a Kerberos credential entry by using bind DN and keytab file.

Note: This DN must be unique and cannot be same as any already existing DN's.

dn: cn=replica1BindCredentials, cn=localhost
objectclass: ibm-replicationCredentialsKerberos
cn: ReplicaBindCredentials
replicaBindDN: <ibm-kn=Kerberos-principal>
replicaCredentials: <Keytab-path>
description: Bind Credentials on master to be used to bind to other servers.

The Kerberos-principal that is referred here must be different from the principal that is referred by the consumer.

On Replica/Consumer:

For the Master (Supplier) to contact the Replica (Consumer) by using the Kerberos principal, you must add the following entries to the replica's configuration file (ibmslapd.conf):

dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: ibm-kn=<Kerberos-principal>
ibm-slapdMasterPW: <Kerberos principal password>
objectclass: ibm-slapdReplication

Replication setup over SSL

To setup replication between two instances, Instance1 and Instance2 for suffix O=IBM,C=US over SSL, both the instances must be configured and started in Secure mode.

Note: Before proceeding, ensure that GSKit is installed properly.

To configure and start instances in secure mode, complete the following steps:

Start the Supplier and Consumer Servers on Simple port.
Export JAVA_HOME=LDAP_HOME_DIR/java. This step is required for generating kdb files with GSKit command line or graphical user interface.

Create the key database (kdb) file for Master and Replica server. For this example, the following sample values are used:

Supplier Key Name       : supplier
Supplier Key Password   : supplier
Supplierkdb key label   : LDAP_Server
Supplierkdb Subject DN  : CN=LDAP_Server,O=IBM,C=US
Consumer Key Name       : consumer
Consumer Key Password   : consumer
Consumerkdb key label   : LDAP
Consumerkdb Subject DN  : CN=LDAP,O=IBM,C=US

Ensure that you generate kdb files that are compatible for serverClientAuth authentication mode.

Modify the Supplier Configuration file by using idsldapmodify:

dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSslAuth
ibm-slapdSslAuth: serverClientAuth
-
replace: ibm-slapdSslCertificate
ibm-slapdSslCertificate:LDAP_Server			//Supplierkdb key label
-
replace: ibm-slapdSecurity
ibm-slapdSecurity: SSL
-
replace: ibm-slapdSSLKeyDatabase
ibm-slapdSSLKeyDatabase: <Absolute Path to supplierc.kdb>
-
replace: ibm-slapdSSLKeyDatabasePW
ibm-slapdSSLKeyDatabasePW: supplier			//Supplier Key Password

Modify the Consumer Configuration file by using idsldapmodify:

dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSslAuth
ibm-slapdSslAuth: serverClientAuth
-
replace: ibm-slapdSslCertificate
ibm-slapdSslCertificate:LDAP			//Consumerkdb key label
-
replace: ibm-slapdSecurity
ibm-slapdSecurity: SSL
-
replace: ibm-slapdSSLKeyDatabase
ibm-slapdSSLKeyDatabase: Absolute Path to consumerc.kdb
-
replace: ibm-slapdSSLKeyDatabasePW
ibm-slapdSSLKeyDatabasePW: consumer			//Consumer Key Password

Restart both Supplier and Consumer Server.
Now you can set up any type of replication topology between Supplier and Consumer server over SSL by using the kdb files generated in step 3 and 4 above.

For more information, see the following articles: