I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 vm1t -h2 vm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Happy to see you fixed this yourself - I was away on vacation and did not have the chance to chime in - this has been subject of many articles in the past - alas - when IBM abandoned our Lotus based communities we lost a lot of those articles and they now only live in private archives like mine :-(

Of course a support case is always a possibility in these cases - but it is always good to find the root cause and fix it yourself as this gives insight into how the thing is working... 

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Just one question - why not version 10 ?

Happy to see you fixed this yourself - I was away on vacation and did not have the chance to chime in - this has been subject of many articles in the past - alas - when IBM abandoned our Lotus based communities we lost a lot of those articles and they now only live in private archives like mine :-(

Of course a support case is always a possibility in these cases - but it is always good to find the root cause and fix it yourself as this gives insight into how the thing is working... 

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Great question. Various client-specific requirements and policies made it such that V6.4 was the best choice.

Just one question - why not version 10 ?

Happy to see you fixed this yourself - I was away on vacation and did not have the chance to chime in - this has been subject of many articles in the past - alas - when IBM abandoned our Lotus based communities we lost a lot of those articles and they now only live in private archives like mine :-(

Of course a support case is always a possibility in these cases - but it is always good to find the root cause and fix it yourself as this gives insight into how the thing is working... 

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

It is going out of extended support at the end of September.

At least, by my experience, in-place upgrade V6.4 to current (10.0.4) is quite straightforward.

Mita

Great question. Various client-specific requirements and policies made it such that V6.4 was the best choice.

Just one question - why not version 10 ?

Happy to see you fixed this yourself - I was away on vacation and did not have the chance to chime in - this has been subject of many articles in the past - alas - when IBM abandoned our Lotus based communities we lost a lot of those articles and they now only live in private archives like mine :-(

Of course a support case is always a possibility in these cases - but it is always good to find the root cause and fix it yourself as this gives insight into how the thing is working... 

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Thanks for that information, Mita. I will look into doing an in-place upgrade once the current tasks are complete.

It is going out of extended support at the end of September.

At least, by my experience, in-place upgrade V6.4 to current (10.0.4) is quite straightforward.

Mita

Great question. Various client-specific requirements and policies made it such that V6.4 was the best choice.

Just one question - why not version 10 ?

Happy to see you fixed this yourself - I was away on vacation and did not have the chance to chime in - this has been subject of many articles in the past - alas - when IBM abandoned our Lotus based communities we lost a lot of those articles and they now only live in private archives like mine :-(

Of course a support case is always a possibility in these cases - but it is always good to find the root cause and fix it yourself as this gives insight into how the thing is working... 

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

The idsldapreplcfg CLI helps abstracting some of the steps you otherwise have to execute through shaping of LDIF files, but with the advantage that you immediately see what is happening in one of the steps (replicaSubentry, replicationAgreement, replicationbindcredentials ...).

The web administration tool can definitely help with configuring LDAP replication.  Some of the tutorials on LDAP replication in IBM DeveloperWorks were not copied to the newer IBM Developer.

We can ask the IBM Support team to publish (after updating for the recent versions) some of the materials

There are two methods to add a consumer side credential

Method 1

Add this entry to the ibmslapd.conf file for the peer  servers.

ibm-slapdMasterPW: {AES256}OHH+x7d0nTafiSIrq0EmHQ==    This is the AES (256 bit) encrypted value of the LDAP bind described in 2.1.

Method 2

You must configure the servers to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1, server2, server3 and server4. On server1, server2, server3 and server4 issue the following command:

idsldapadd -D <adminDN> -w<adminPW> -i<filename> where <filename> contains:

dn: cn=MasterServer, cn=configuration

cn: MasterServer

ibm-slapdMasterDN: cn=replusr

ibm-slapdMasterPW: {AES256}OHH+x7d0nTafiSIrq0EmHQ==

objectclass: ibm-slapdReplication

objectclass: ibm-slapdConfigEntry

objectclass: top

Note: It is critical that these entries be exactly the same on all servers 

Restart the peer servers.

On installing the Web administration tool in a WebSphere application server environment:  you can definitely install it on an existing environment (.eg .IVIG/ISIM environment)  . There is no need to install a standalone WAS instance

if needed some of the Developerworks materials; you can DM and I can share those materials

Kind regards

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Thanks for the reply, Serge. If you have any documents on installing IDSWebApp.war into an existing WebSphere ND instance, that would be great. I'll DM you. I tried the instructions in the documentation to deploy the WAR file (documentation: https://www.ibm.com/docs/en/sdsu/8.0.1?topic=mdwat-deploying-web-administration-tool-in-websphere-application-server ), and while it deployed and started, I could not successfully authenticate to the application.

The idsldapreplcfg CLI helps abstracting some of the steps you otherwise have to execute through shaping of LDIF files, but with the advantage that you immediately see what is happening in one of the steps (replicaSubentry, replicationAgreement, replicationbindcredentials ...).

The web administration tool can definitely help with configuring LDAP replication.  Some of the tutorials on LDAP replication in IBM DeveloperWorks were not copied to the newer IBM Developer.

We can ask the IBM Support team to publish (after updating for the recent versions) some of the materials

There are two methods to add a consumer side credential

Method 1

Add this entry to the ibmslapd.conf file for the peer  servers.

ibm-slapdMasterPW: {AES256}OHH+x7d0nTafiSIrq0EmHQ==    This is the AES (256 bit) encrypted value of the LDAP bind described in 2.1.

Method 2

You must configure the servers to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1, server2, server3 and server4. On server1, server2, server3 and server4 issue the following command:

idsldapadd -D <adminDN> -w<adminPW> -i<filename> where <filename> contains:

dn: cn=MasterServer, cn=configuration

cn: MasterServer

ibm-slapdMasterDN: cn=replusr

ibm-slapdMasterPW: {AES256}OHH+x7d0nTafiSIrq0EmHQ==

objectclass: ibm-slapdReplication

objectclass: ibm-slapdConfigEntry

objectclass: top

Note: It is critical that these entries be exactly the same on all servers 

Restart the peer servers.

On installing the Web administration tool in a WebSphere application server environment:  you can definitely install it on an existing environment (.eg .IVIG/ISIM environment)  . There is no need to install a standalone WAS instance

if needed some of the Developerworks materials; you can DM and I can share those materials

Kind regards

OK. Happily, I found another part of the documentation that gives the rest of the information needed: https://www.ibm.com/docs/en/sdse/6.4.0?topic=replication-using-command-line .

The problem was definitetly the credentials, but the "fix"I tried earlier wasn't the actual fix. The actual fix is at the above link:

1. You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:

   idsldapadd -D <adminDN> -w <adminPW> -i<filename>
   where <filename> contains:

   dn: cn=Master Server, cn=configurationobjectclass: ibm-slapdReplicationcn: Master Serveribm-slapdMasterDN: cn=anyibm-slapdMasterPW: secret123
   Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.

So as you can see in the note, THIS is the credential that must exist on both servers and be referenced in the ibm-replicationCredentials entry in the DIT. Whew!

Another hint to anyone who is attempting this: You really HAVE to install the IDS Web Administration Tool to get even marginal debugging help. And to do that, you really need to install it on its own WebSphere environment. Specifically, you CANNOT install it in the same WebSphere environment where you've installed ISVIG/ISIM (unless you're a whole lot better at installing WebSphere applications than I am). I installed a completely new WebSphere environment based on this technote: https://www.ibm.com/support/pages/how-use-deployidswebapp-tool-deploy-directory-server-web-admin-tool-stand-alone-websphere-application-server . Once I got through that, I could use the Web Admin Tool to at least see the errors I was encountering and at least see the transactions in the replication queue. It also let me skip any blocking transactions, suspend replication, and attempt to force replication. All VERY handy capabilities.

I am trying to configure Peer-to-Peer replication for IBM Directory Server V6.4 on RHEL 9.5 from the command line, and as far as I can tell, the documentation is missing some information. I'm using the ldapreplcfg command (https://www.ibm.com/docs/en/sdse/6.4.0?topic=SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_repl_topology_config_tool.htm), and it creates some entries, but replication doesn't work. Details:

I have two LDAP servers: fplvm1t and fplvm1p (fpl=Frank's Personal Lab). Here's the command I'm using to try to configure replication:

/opt/IBM/ldap/V6.4/bin/ldapreplcfg -s dc=gulfsoft,dc=com -topo PP -h1 fplvm1t -h2 fplvm1p -p1 389 -p2 389 -D1 cn=root -D2 cn=root -w1 passw0rd1 -w2 passw0rd1

That command successfully creates the following entries under dc=gulfsoft,dc=com in the DIT on both servers:

cn=creds1193316171

ibm-replicaGroup=default

• cn=fplvm1p:389
  • cn=fplvm1t:389
• cn-fplvm1t:389
  • cn=fplvm1p:389

That all seems good, except the cn=creds1193316171 entry has these values:

replicaBindDN: cn=fplvm1t
replicaCredentials: fplvm1t

Looking in ibmslapd.log on fplvm1p (similar on fplvm1t), I see this error:

2025-07-17T08:44:40.189027-4:00  GLPRPL036E Error 'simple bind: Invalid credentials' occurred for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM': bind failed using masterDn 'cn=fplvm1t'.

Seeing this, I changed the replicaBundDN to cn=root and set the replicaCredentials to passw0rd1 (the admin userid and password). Now I see this message in ibmslapd.log on fplvm1p (similar on fplvm1t), which I thought was a good thing:

2025-07-17T08:58:01.002221-4:00 GLPRPL029I Established connection for replica 'CN=FPLVM1T:389,CN=FPLVM1P:389,IBM-REPLICAGROUP=DEFAULT,DC=GULFSOFT,DC=COM' on host 'fplvm1t' port 389.

However, no replication is actually performed. Also, following these docs, I ran this command:

/opt/IBM/ldap/V6.4/bin/idsldapsearch -h localhost -p 389 -b "dc=gulfsoft,dc=com" -s "sub" "objectclass=ibm-replicationAgreement" ibm-replicationState

And it shows me that the ibm-replicationState=binding, when I would think it should show "Ready".

So that's where I am. Any pointers?

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------