Secure replication in IBM Tivoli Directory Server

The article describes how to easily configure different replication topologies in IBM® Tivoli® Directory Server (TDS) using simple shell scripts. These scripts can be used to configure all known replication topologies (like Peer-peer, Master-Replica-Forwarder, Gateways etc) using simple bind, SSL with certificates or Kerberos authentication mechanism. The information in this article applies to TDS version 5.2 and later.

Gaurav Khanna (gaurav.khanna@in.ibm.com), Systems Software Engineer, IBM

Gaurav KhannaGaurav Khanna is a Software Engineer at IBM Software Labs, India. He is working as a part of the IBM Tivoli Directory Server team.



Sunil Ranahandola (sranahan@in.ibm.com), Staff Software Engineer, IBM

Sunil RanahandolaSunil M Ranahandola is a Staff Software Engineer at IBM Software Labs, India, presently working as an IBM Tivoli Directory Server Developer. He has been a part of the IBM Tivoli Directory Server team since 2001.



Prashant Mohan Baadkar (prashant.baadkar@in.ibm.com), Staff Software Engineer, IBM

Prashant BaadkarPrashant Baadkar is a Software developer with Tivoli Directory Server. He has experience with various Tivoli Security products and has worked as part of Tivoli Identity Manager and Tivoli Directory Server teams prior to this.



30 September 2008

Introduction

Configuring even the simplest replication topology in TDS is considered by many to be a very complex task. The complexity increases when configuring secure replication using SSL or Kerberos. TDS replication configuration is predominantly manual and requires the end user to know a lot about the replication specific internal objectclasses and attributes.

Pre-requisite knowledge : Setting up replication topologies using manual and Graphical User Interface (GUI) tools has already been discussed in a variety of developerWorks® articles. It is expected that the readers of this article are already familiar with the fundamentals of configuring LDAP replication, as presented in these articles:

http://www.ibm.com/developerworks/tivoli/library/t-tdsrepl/index.html

http://www.ibm.com/developerworks/tivoli/library/t-debugrepitds/index.html

Modes of replication

Each server participating in a given replication topology, irrespective of its role, can be configured to communicate with other servers in the topology via the following three modes :

1. Simple Replication: Communication between the Supplier and Consumer takes place over an unencrypted channel and authentication takes place using bind DN and credentials.

2. Replication over SSL: Communication between the Supplier and Consumer takes place over an encrypted channel. Authentication is via bindDN and credentials or SSL certificates.

3. Replication using Kerberos authentication mechanism: Standard Kerberos authentication method is used by the Supplier and Consumer. Only AIX® and Microsoft® Windows® servers can be configured to participate in this form of replication as TDS does not support Kerberos configuration on other platforms.

The SSL and Kerberos modes of replication provide security advantages over simple replication and are recommended for most production environments. This article mainly provides and describes automated scripts to setup secure replication. The scripts can also be used to configure simple normal replication.

Configuring replication over SSL

Consider the simple example of configuring a replication topology consisting of a master and a single replica using SSL. The steps of configuring replication using SSL are similar to setting up replication without SSL until the point of adding a replication agreement as described below. For steps of configuring replication without SSL please refer to the section Building topology 1 (Master-Replica)

On Master/Supplier:

(a) Identify the suffix or subentry to be replicated. Add the ibm-replicationContext auxiliary objectclass to it to make it a replication context.

(b) Add an ibm-replicaGroup entry under it.

(c) Add an ibm-replicationSubEntry entry to the ibm-replicaGroup entry.

(d) The next step is to add an ibm-replicationAgreement under the ibm-replicationSubEntry entry. For replication over SSL, the type of replication agreement entry is shown in Listing 4: Replication agreement entry

Listing 4: Replication agreement entry
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

Note: Each server in the replication topology has a unique identifier called its serverid. This can be found in the configuration file of the corresponding server under "dn: cn=Configuration". For a running server this can also be found 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 server1 is running TDS on port port1, the corresponding rootDSE search will be: idsldapsearch —h <server1> —p <port1> —s base —b "" objectclass=*

Note: In the agreement entry above, the ldap url is of type ldaps:// and not ldap://. This is a requirement for replication over SSL. Also the replication credential entry referred to above via the attribute ibm-replicaCredentialsDN can be of type ibm-replicationCredentialsSimple or ibm-replicationCredentialsExternal depending upon the authentication method to be used.

(e) Add replication credential entry to the Directory Information Tree (DIT). Example of a credential entry for Simple Replication (using bind DN and password) is shown in Listing 5: Example of a credential entry using simple bind DN and password

Listing 5: Example of a credential entry using simple bind DN and password
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.

Example of a credential entry using certificates is shown in Listing 6: Example of a credential entry using certificates

Listing 6: Example of a credential entry 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.

The kdb file referred above can be created using Generatekeys.sh

On Replica/Consumer:

If the master (Supplier) needs to contact the replica (Consumer) using simple bindDN and password, the following needs to be added to the replica's configuration file (ibmslapd.conf) as shown in Listing 7: Consumer Configuration entry for SSL using Simple Bind DN and password

Listing 7: Consumer configuration entry for SSL using Simple Bind DN and password
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 using certificates, then the following needs to be added to the replica's configuration file (ibmslapd.conf) as shown in Listing 8: Consumer Configuration entry for SSL using external Certificates

Listing 8: Consumer Configuration entry for SSL using external Certificates
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: <subject_DN_of_cert_in_kdb_file>
objectclass: ibm-slapdReplication

Configuring replication over Kerberos

Consider again the simple example of configuring replication topology consisting of master and a single replica using Kerberos. The steps of configuring replication using Kerberos are similar to setting up replication with SSL till the point of adding a replication agreement as described below :

Note: Note: For setting up replication through Kerberos, both of the servers (i.e., supplier and consumer) should be enabled to accept Kerberos authentication. For more information on setting up Kerberos, please refer to link IBM Network Authentication Service KDC and administration servers discovery using LDAP for AIX

On Master/Supplier:

(a) Identify the suffix or subentry to be replicated. Add the ibm-replicationContext auxiliary objectclass to it to make it a replication context.

(b) Add an ibm-replicaGroup entry under it.

(c) Add an ibm-replicationSubEntry entry to the ibm-replicaGroup entry.

(d) The next step is to add an ibm-replicationAgreement under the ibm-replicationSubEntry entry. For replication over Kerberos, the type of replication agreement entry is shown in Listing 10: Replication agreement entry

Listing 10: Replication agreement entry
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

(e) Add replication credential entry to the DIT. Example of a Kerberos credential entry using bind DN and keytab filef is shown in Listing 11: Replication credential entry

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

The Kerberos-principle referred above needs to be different from the principle being referred by consumer.

On Replica/Consumer:

For the master (Supplier) to contact the replica (Consumer) using Kerberos principle, the following needs to be added to the replica's configuration file (ibmslapd.conf) as shown in Listing 12: Consumer Configuration entry

Listing 12: Consumer configuration entry
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: ibm-kn=<Kerberos-principle>
ibm-slapdMasterPW: <Kerberos principle password>
objectclass: ibm-slapdReplication

Configuring replication using automated scripts

The above mentioned steps for configuring replications can be done easily using the shell scripts provided with this article. These scripts can be used to configure every type of replication from simple to complex topologies.

Let's have a look at the usage of these scripts :

Generatekeys.sh : This shell script can be used to create keys for configuring Secure connection (SSL Configuration) on the directory server instances. The IBM Global Security Kit (GSKit) software must be installed on the system and is required by this script. GSKit is IBM's SSL implementation library, and is listed an optional package during installation. GSKit can be installed post-installation if necessary and more information on this can be found in the TDS installation guide here. Once GSKit is properly installed on the system, then server and client Keypass Database File (kdbs) that contain public/private key pairs used for SSL communication can be generated easily using this script.

Listing 14: Various parameters of GenerateKeys.sh
USAGE:
GenerateKeys.sh <-a server_kdb_file_name> <-b server_kdb_file_password>
<-c server_kdb_key_label> <-d server_kdb_subject_dn>
<-e client_kdb_file_name> <-f client_kdb_file_password>
<-g client_kdb_key_label> [-h client_kdb_subject_dn]

Where:
-a Supplier_kdb_file_name         Name of the kdb file for the Supplier.
-b Supplier_kdb_file_password     Password for Supplier's kdb file.
-c Supplier_kdb_key_label         Key label for Supplier's kdb file.
-d Supplier_kdb_subject_dn        Subject DN of Supplier's kdb file.
-e Consumer_kdb_file_name         Name of the kdb file for the Consumer.
-f Consumer_kdb_file_password     Password for Consumer's kdb file.
-g Consumer_kdb_key_label         Key label for Consumer's kdb file.
-h Consumer_kdb_subject_dn        Subject DN of Consumer's kdb file.

Options in <> are required. Options in [ ] are optional.

MR.sh : This shell script can be used to configure a Master-Replica setup between two TDS directory servers on the same machine or different machines. This script can be executed on any machine on which the TDS Client is installed. The only requirement is systems with instances configured to be replication servers should be accessible from this system. Once directory server instances are successfully created, configured and started, then any mode of Supplier-Consumer Replication can be configured easily using this script.

Listing 15: Various parameters of MR.sh
USAGE:
./MR.sh <-a suffix>
<-b master_hostname> <-c master_port> [-d master_admin_dn] [-e master_admin_pw]
<-f replica_hostname> <-g replica_port> [-h replica_admin_dn] [-i replica_admin_pw]
[-n <-o kdb_file_path> <-p kdb_password> <-q kdb_cert_name> <-r kdb_cert_subject_DN>]
[-s <-t kerberos_principle_DN> <-u kerberos_principle_PW>]
[-v ipType] [-w no_of_conns] [-z]

Where:
-a suffix                  DN of entry to be configured as a replication context.
                           It should be present on both servers.
-b master_hostname         Hostname of the master server.
-c master_port             Simple Port at which master server is running.
-d master_admin_dn         Admin DN of the master server.
                           If not specified cn=root will be taken.
-e master_admin_pw         Admin password of the master server.
                           If not specified root will be taken.
-f replica_hostname        Hostname of the replica server.
-g replica_port            Simple Port at which replica server is running.
-h replica_admin_dn        Admin DN of the replica server.
                           If not specified cn=root will be taken.
-i replica_admin_pw        Admin password of the replica server.
                           If not specified root will be taken.
-n                         Configure replication over SSL.
-o kdb_file_path           Absolute path of key file to be used for SSL communication.
-p kdb_password            Password for the key file.
-q kdb_cert_name           Certificate name used while generating the key file.
-r kdb_cert_subject_DN     Subject DN used while generating the key file.
-s                         Configure replication over Kerberos.
-t kerberos_principle_DN   Principle DN to be used for Kerberos authentication.
-u kerberos_principle_PW   Password for the Kerberos Principle.
-v                         Use IPv6 to configure replication.
                           With this option, Specify IPV6 address with -b and -f options.
                           By default, IPv4 will be used.
-w no_of_conns             No. of connection to be used in multi-threaded replication.
                           By default, replication will be configured as single-threaded.
-z                         Delete intermediate ldif files.

Options in <> are required. Options in [ ] are optional.

PP.sh : This shell script can be used to configure a Peer-Peer setup between two TDS directory servers on the same machine or different machines. This script can be executed on any machine on which the TDS Client is installed. The only requirement is systems with instances configured to be replication servers should be accessible from this system. Once directory server instances are successfully created, configured and started, then any mode of Peer-Peer Replication can be configured easily using this script.

Listing 16: Various parameters of PP.sh
USAGE:
./PP.sh <-a suffix>
<-b Peer1_hostname> <-c Peer1_port> [-d Peer1_admin_dn] [-e Peer1_admin_pw]
<-f Peer2_hostname> <-g Peer2_port> [-h Peer2_admin_dn] [-i Peer2_admin_pw]
[-n <-o kdb_file_path> <-p kdb_password> <-q kdb_cert_name> <-r kdb_cert_subject_DN>]
[-s <-t kerberos_principle_DN> <-u kerberos_principle_PW>]
[-v ipType] [-w no_of_conns] [-z]

Where:
-a suffix                  DN of entry to be configured as a replication context.
                           It should be present on both servers.
-b Peer1_hostname          Hostname of the Peer1.
-c Peer1_port              Simple Port at which Peer1 server is running.
-d Peer1_admin_dn          Admin DN of the Peer1 server.
                           If not specified cn=root will be taken.
-e Peer1_admin_pw          Admin password of the Peer1 server.
                           If not specified root will be taken.
-f Peer2_hostname          Hostname of the Peer2 server.
-g Peer2_port              Simple Port at which Peer2 server is running.
-h Peer2_admin_dn          Admin DN of the Peer2 server.
                           If not specified cn=root will be taken.
-i Peer2_admin_pw          Admin password of the Peer2 server.
                           If not specified root will be taken.
-n                         Configure replication over SSL.
-o kdb_file_path           Absolute path of the key file to be used for SSL communication.
-p kdb_password            Password for the key file.
-q kdb_cert_name           Certificate name used while generating the key file.
-r kdb_cert_subject_DN     Subject DN used while generating the key file.
-s                         Configure replication over Kerberos.
-t kerberos_principle_DN   Principle DN to be used for Kerberos authentication.
-u kerberos_principle_PW   Password for the kerberos Principle.
-v                         Use IPv6 to configure replication.
                           With this option, Specify IPV6 address with -b and -f options.
                           By default, IPv4 will be used.
-w no_of_conns             No. of connection to be used in multi-threaded replication.
                           By default, replication will be configured as single-threaded.
-z                         Delete intermediate ldif files.

Options in <> are required. Options in [ ] are optional.

GG.sh : This shell script can be used to configure a Gateway-Gateway setup between two TDS directory servers on the same machine or different machines. This script can be executed on any machine on which the TDS Client is installed. The only requirement is systems with instances configured to be replication servers should be accessible from this system. Once directory server instances are successfully created, configured and started, then any mode of Gateway-Gateway Replication can be configured easily using this script.

Listing 17: Various parameters of GG.sh
USAGE:
./GG.sh <-a suffix>
<-b Gateway1_hostname> <-c Gateway1_port> [-d Gateway1_admin_dn] [-e Gateway1_admin_pw]
<-f Gateway2_hostname> <-g Gateway2_port> [-h Gateway2_admin_dn] [-i Gateway2_admin_pw]
[-n <-o kdb_file_path> <-p kdb_password> <-q kdb_cert_name> <-r kdb_cert_subject_DN>]
[-s <-t kerberos_principle_DN> <-u kerberos_principle_PW>]
[-v ipType] [-w no_of_conns] [-z]

Where:
-a suffix                  DN of entry to be configured as a replication context.
                           It should be present on both servers.
-b Gateway1_hostname       Hostname of the Gateway1.
-c Gateway1_port           Simple Port at which Gateway1 server is running.
-d Gateway1_admin_dn       Admin DN of the Gateway1 server.
                           If not specified cn=root will be taken.
-e Gateway1_admin_pw       Admin password of the Gateway1 server.
                           If not specified root will be taken.
-f Gateway2_hostname       Hostname of the Gateway2 server.
-g Gateway2_port           Simple Port at which Gateway2 server is running.
-h Gateway2_admin_dn       Admin DN of the Gateway2 server.
                           If not specified cn=root will be taken.
-i Gateway2_admin_pw       Admin password of the Gateway2 server.
                           If not specified root will be taken.
-n                         Configure replication over SSL.
-o kdb_file_path           Absolute path of the key file to be used for SSL communication.
-p kdb_password            Password for the key file.
-q kdb_cert_name           Certificate name used while generating the key file.
-r kdb_cert_subject_DN     Subject DN used while generating the key file.
-s                         Configure replication over Kerberos.
-t kerberos_principle_DN   Principle DN to be used for Kerberos authentication.
-u kerberos_principle_PW   Password for the kerberos Principle.
-v                         Use IPv6 to configure replication.
                           With this option, Specify IPV6 address with -b and -f options.
                           By default, IPv4 will be used.
-w no_of_conns             Number of connection to be used in multi-threaded replication.
                           By default, replication will be configured as single-threaded.
-z                         Delete intermediate ldif files.

Options in <> are required. Options in [ ] are optional.

MFR.sh : This shell script can be used to configure a Master-Forwarder-Replica setup between three TDS directory servers on the same machine or different machines. This script can be executed on any machine on which the TDS Client is installed. The only requirement is systems with instances configured to be replication servers should be accessible from this system. Once directory server instances are successfully created, configured and started, then any mode of Master-Forwarder-Replica Replication can be configured easily using this script.

Listing 18: Various parameters of MFR.sh
USAGE:
./MFR.sh <-a suffix>
<-b master_hostname> <-c master_port> [-d master_admin_dn] [-e master_admin_pw]
<-f fwdr_hostname> <-g fwdr_port> [-h fwdr_admin_dn] [-i fwdr_admin_pw]
<-j replica_hostname> <-k replica_port> [-l replica_admin_dn] [-m replica_admin_pw]
[-n <-o kdb_file_path> <-p kdb_password> <-q kdb_cert_name> <-r kdb_cert_subject_DN>]
[-s <-t kerberos_principle_DN> <-u kerberos_principle_PW>]
[-v ipType] [-w no_of_conns] [-z]

Where:
-a suffix                  DN of entry to be configured as a replication context.
                           It should be present on both servers.
-b master_hostname         Hostname of the Master server.
-c master_port             Simple Port at which Master server is running.
-d master_admin_dn         Admin DN of the Master server.
                           If not specified cn=root will be taken.
-e master_admin_pw         Admin password of the Master server.
                           If not specified root will be taken.
-f fwdr_hostname           Hostname of the Forwarder server.
-g fwdr_port               Simple Port at which Forwarder server is running.
-h fwdr_admin_dn           Admin DN of the Forwarder server.
                           If not specified cn=root will be taken.
-i fwdr_admin_pw           Admin password of the Forwarder server.
                           If not specified root will be taken.
-j replica_hostname        Hostname of the Replica server.
-k replica_port            Simple Port at which Replica server is running.
-l replica_admin_dn        Admin DN of the Replica server.
                           If not specified cn=root will be taken.
-m replica_admin_pw        Admin password of the Replica server.
                           If not specified root will be taken.
-n                         Configure replication over SSL.
-o kdb_file_path           Absolute path of the key file to be used for SSL communication.
-p kdb_password            Password for the key file.
-q kdb_cert_name           Certificate name used while generating the key file.
-r kdb_cert_subject_DN     Subject DN used while generating the key file.
-s                         Configure replication over Kerberos.
-t kerberos_principle_DN   Principle DN to be used for Kerberos authentication.
-u kerberos_principle_PW   Password for the kerberos Principle.
-v                         Use IPv6 to configure replication.
                           With this option,Specify IPV6 address with -b,-f and -j option.
                           By default, IPv4 will be used.
-w no_of_conns             Number of connection to be used in multi-threaded replication.
                           By default, replication will be configured as single-threaded.
-z                         Delete intermediate ldif files.

Options in <> are required. Options in [ ] are optional.

Examples--configuring replication using automated scripts

Let's have a look at some examples of using the automated scripts to configure every type of replication from simple to complex topologies.

Let's assume that the following TDS instances are configured and running :

Instance1 Hostname : testmac1.ibm.com

Instance1 Simple Port : 389

Instance1 Admin DN : cn=root

Instance1 Admin DN Password : root

Instance2 Hostname : testmac2.ibm.com

Instance2 Simple Port : 1389

Instance2 Admin DN : cn=root

Instance2 Admin DN Password : root

Simple Replication Setup:

To setup Replication between above mentioned two instances- Instance1 and Instance2 for suffix O=IBM,C=US

Listing 20: Simple Master-Replica setup with Instance1 as Master and Instance2 as replica
./MR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
Listing 21: Simple Peer-Peer Setup with Instance1 as Peer1 and Instance2 as Peer2
./PP.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root -n -o
Listing 22: Simple Gateway-Gateway Setup with Instance1 as Gateway1 and Instance2 as Gateway2
./GG.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root

Replication setup over SSL:

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

To start the servers in Secure mode, key database files(kdb files) are needed. To generate kdb files, script GenerateKeys.sh can be used.

Note Before proceeding further, Make sure that gskit is installed properly.

To Configure and Start Instances in Secure Mode
1. Start the Supplier and Consumer Servers on Simple port.

2. Export JAVA_HOME=<LDAP_HOME_DIR>/java

3. To create the server and client keys for Master server with following details :
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

Execute
./GenerateKeys.sh -a supplier -b supplier -c LDAP_Server -d CN=LDAP_Server,O=IBM,C=US
-e consumer -f consumer -g LDAP -h CN=LDAP,O=IBM,C=US

Note Keyname, password, Label and Subject DN mentioned above are sample values.
User can change these values on choice.

The above execution will create following four files :
supplier.kdb  : This kdb is used to configure Supplier server in Serverauth mode.
supplierc.kdb : This kdb is used to configure Supplier server in ServerClientAuth mode.
consumer.kdb  : This kdb is used to configure Consumer server in Serverauth mode.
consumerc.kdb : This kdb is used to configure Consumer server in ServerClientAuth mode.
Note Replication over SSL requires ServerClientAuth Secure mode.

4. Modify the Supplier Configuration file using idsldapmodify as:
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

5. Modify the Consumer Configuration file using idsldapmodify as:
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

6. Restart both Supplier and Consumer Server.

7. Now any type of replication topology can be setup between Supplier and consumer server
over SSL using any of the kdb file i.e supplierc.kdb or consumerc.kdb

To setup replication between two instances - Instance1 and Instance2 for suffix O=IBM,C=US over SSL.

Listing 24: Master-Replica setup over SSL with Instance1 as Master and Instance2 as replica
./MR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o supplierc.kdb -p supplier -q LDAP_Server -r cn=LDAP_Server,o=ibm,c=us

 OR

./MR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o consumerc.kdb -p consumer -q LDAP -r cn=LDAP,o=ibm,c=us
Listing 25: Peer-Peer Setup over SSL with Instance1 as Peer1 and Instance2 as Peer2
./PP.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o supplierc.kdb -p supplier -q LDAP_Server -r cn=LDAP_Server,o=ibm,c=us

 OR

./PP.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o consumerc.kdb -p consumer -q LDAP -r cn=LDAP,o=ibm,c=us
Listing 26: Gateway-Gateway Setup over SSL with Instance1 as Gateway1 and Instance2 as Gateway2
./GG.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o supplierc.kdb -p supplier -q LDAP_Server -r cn=LDAP_Server,o=ibm,c=us

 OR

./GG.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -n -o consumerc.kdb -p consumer -q LDAP -r cn=LDAP,o=ibm,c=us

Note: After executing any of the scripts to configure replication over SSL, the directory administrator can set the "ibm-slapdSecurity" to "SSLOnly" so that no communication is allowed over non-secure ports. However, doing this before running the scripts will result in failure of the scripts to contact the servers.

Replication setup over Kerberos:

To setup replication between above mentioned two instances- Instance1 and Instance2 for suffix O=IBM,C=US over kerberos, both the instances are required to configure and start in Kerberos mode.

For more info on how to configure Kerberos, refer IBM Network Authentication Service KDC and administration servers discovery using LDAP for AIX

Listing 27: Master-Replica setup over Kerberos with Instance1 as Master and Instance2 as replica
./MR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -s -t ibm-kn=(principle@realm) -u (kdb-password)
Listing 28: Peer-Peer setup over Kerberos with Instance1 as Peer1 and Instance2 as Peer2
./PP.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -s -t ibm-kn=(principle@realm) -u (kdb-password)
Listing 29: Gateway-Gateway Setup over Kerberos with Instance1 as Gateway1 and Instance2 as Gateway2
./GG.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -s -t ibm-kn=(principle@realm) -u (kdb-password)

Replication Setup including Master-Forwarder-Replica:

To setup Master-Forwarder-Replica topology, three instances are required. Apart from above mentioned two instances, Let's assume third sample TDS instance with following details :

Instance3 Hostname : testmac3.ibm.com

Instance3 Simple Port : 2389

Instance3 Admin DN : cn=root

Instance3 Admin DN Password : root

To setup Master-Forwarder-Replica topology between three instances - Instance1, Instance2 and Instance3 for suffix O=IBM,C=US.

Listing 30: Simple Master-Forwarder-Replica Setup with Instance1 as Master, Instance2 as Forwarder and Instance3 as Replica
./MFR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -j testmac3.in.ibm.com -k 2389 -l cn=root -m root

To setup Master-Forwarder-Replica topology between three instances - Instance1, Instance2 and Instance3 for suffix O=IBM,C=US over SSL.

Listing 31: Master-Forwarder-Replica Setup over SSL with Instance1 as Master, Instance2 as Forwarder and Instance3 as Replica
./MFR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -j testmac3.in.ibm.com -k 2389 -l cn=root -m root
 -n -o supplierc.kdb -p supplier -q LDAP_Server -r cn=LDAP_Server,o=ibm,c=us

To setup Master-Forwarder-Replica topology between three instances - Instance1, Instance2 and Instance3 for suffix O=IBM,C=US over kerberos.

Listing 32: Master-Forwarder-Replica Setup over kerberos with Instance1 as Master, Instance2 as Forwarder and Instance3 as Replica
./MFR.sh -a o=ibm,c=us -b testmac1.ibm.com -c 389 -d cn=root -e root
 -f testmac2.in.ibm.com -g 1389 -h cn=root -i root
 -j testmac3.in.ibm.com -k 2389 -l cn=root -m root
 -s -t ibm-kn=(principle@realm) -u (kdb-password)

Conclusion

This article provides Unix® shell scripts which can be used to configured different replication topologies between various TDS instances on Unix or Windows. These scripts also allow replication to be configured over SSL and Kerberos authentication mechanisms. These scripts can be used without any prior knowledge of TDS replication details and hence serve as a rapid means of replication configuration.

References

For TDS information

For more information about Replication topology fundamentals

For more information about How to setup Kerberos


Download

DescriptionNameSize
TDS-Replication ScriptsTDS-Replication-scripts.zip22KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Tivoli, Security
ArticleID=338119
ArticleTitle=Secure replication in IBM Tivoli Directory Server
publish-date=09302008