No LDAP replication taking place

[Steve MacDougall]

I've set up two machines in cluster mode with RCDevs DS running locally on each machine. My users are configured in dc=xxxxxxxx,dc=com,dc=Domains,dc=WebADM. I've tried a number of configurations, the lates of which is the following:

serverID 1
syncrepl rid=001
         provider=ldap://10.10.1.5
         bindmethod=simple
         searchbase="dc=xxxxxxxx,dc=com,dc=Domains,dc=WebADM"
         binddn="cn=admin,o=Root"
         credentials="xxxxxxxxx"
         starttls=yes
         tls_reqcert=never
         searchbase=""
         schemachecking=on
         type=refreshAndPersist
         retry="60 +"
mirrormode on

serverID 2
syncrepl rid=001
         provider=ldap://10.10.1.2
         bindmethod=simple
         searchbase="dc=caledoncard,dc=com,dc=Domains,dc=WebADM"
         binddn="cn=admin,o=Root"
         credentials="xxxxxxxxx"
         starttls=yes
         tls_reqcert=never
         searchbase=""
         schemachecking=on
         type=refreshAndPersist
         retry="60 +"
mirrormode on

So far I have not been able to get my users to replicate to the second server.

[Administrators]

This config is good.

Confirm that server with serverID 1 has the IP 10.10.1.2 

and that server with serverID 2 has the IP 10.10.1.5

And check you have firewall rules allowing cross-server LDAP traffic between the two servers.

If it's our VM, you must add lines to /etc/sysconfig/iptables as documented in the WebADM HA Manual.

[Steve MacDougall]

IPTables is not configured with any rules on either server and the IP addresses are correct.

--
You received this message because you are subscribed to the Google Groups "RCDevs Security Solutions - Technical" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rcdevs-technic...@googlegroups.com.
To post to this group, send email to rcdevs-t...@googlegroups.com.
Visit this group at http://groups.google.com/group/rcdevs-technical.
For more options, visit https://groups.google.com/groups/opt_out.

-- 

Steve MacDougall
Sr. Network/Systems Administrator
Caledon Card Services
647-258-3713 (o)
289-924-1806

[Administrators]

Ok I know where is the problem : It's the search base. It must be the root to replicate. In your case you use our RCDevs Dir. which has no tree root so it's: 

searchbase=""

[Steve MacDougall]

That wasn't it. I adjusted the search base, but I still get the same issue. I think it may be more of an access isseu. For example if I run ldapsearch on the localhost I get an output from the database, however if I run the same search on the from one system to another i get:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


I also see this in the syslog every minute:

Dec  9 09:48:51 janus rcdevs-slapd[3757]: do_syncrepl: rid=001 rc -1 retrying
Dec  9 09:49:51 janus rcdevs-slapd[3757]: slap_client_connect: URI=ldap://10.10.1.5 Warning, ldap_start_tls failed (-1)


I've verified that iptables is not blocking anything on either system:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination     

The service is listening on both systems:


tcp        0      0 localhost:ldap          *:*                     LISTEN

There aren't any other firewalls in between and I can see the connection attempts using TCPDUMP so I know they're not blocked.

Is there anything else that would be blocking access?

[Administrators]

We just tested the same setup with RCDevs Dir. Server - it works perfect. Replication is effective in both directions.

ldap_start_tls failed has something to do with the certificates. But you have 

         starttls=yes
         tls_reqcert=never

and this should always work.

Can you try without TLS (with  starttls=no) just to see it works?

[Steve MacDougall]

I figured out what the issue was. Since I was unable to query the ldap database from anywhere but localhost I figured the issue was some sort of access restriction. After checking iptables, selinux, and slapd.conf, I finally found that the slapd start script was starting ldap to listen only on the localhost:

 rcdevs-slapd -u $USER -h "ldap://127.0.0.1:389 ldaps://127.0.0.1:1636"

I changed it to this:

rcdevs-slapd -u $USER -h "ldap:/// ldaps://0.0.0.0:1636"

and now all is well.