LDAP Replication Errors

Question

Level 1

40 points

LDAP Replication Errors

I have an OD Master and an OD Replica that are showing errors in the slapd log. I get the following on both machines:

Aug 22 09:48:17 server slapd[936]: slap_client_connect: URI=ldap://server.example.com:389 ldap_sasl_interactive_bind_s failed (-2)
Aug 22 09:48:17 server slapd[936]: do_syncrepl1: client_connect failed (-1)

To test that everything should work I used the following command:

ldapsearch -H ldap://server.example.com:389 -Y CRAM-MD5 -I -b "dc=server,dc=example,dc=com"

That works on both boxes using an account that has admin powers for the directory.

It used to be that there was a syncrepl section in /etc/openldap/slapd.conf where you would specify the user, credentials, and SASL mechanism for replication. This section doesn't exist in my slapd.conf so I figure the configuration for replication must live in the directory itself. Using Directory Utility.app and the new Directory Editor, I don't much in the way of configuration for replication. Looking at base:

cn=config,dc=server,dc=example,dc=com

There is a replicas entry but all it does is list the master and replicas. It doesn't include anything about a replica user, SASL mechanism, or password.

Looking at base:

cn=config

I see the sync overlays, but again I don't see anything that specifies a sync user, a SASL mechanism and user credentials.

Am I missing something, is there some other place that Apple uses to configure ldap replication?

Posted on Aug 22, 2011 1:40 PM

Reply

Answer 1

Dec 29, 2011 5:52 PM in response to Mr Beardsley

Hi Mr Beardsley,

did you have any luck in resolving this problem?

I have just had huge problems established a set of Lion OD Replicas and have now managed to get two replica's up, however they replication across then is now getting the same error you logged:

On the OD Relica:

Dec 30 12:27:24 mouse slapd[80]: slap_client_connect: URI=ldap://master.in.frog.com:389 ldap_sasl_interactive_bind_s failed (-2)

Dec 30 12:27:24 mouse slapd[80]: do_syncrepl1: client_connect failed (-1)

Dec 30 12:27:24 mouse slapd[80]: do_syncrepl: rid=001 rc -1 retrying

</OD Replica Log>

On the OD Master

Dec 30 12:31:44 master slapd[56]: slap_client_connect: URI=ldap://mouse.frog.com:389 ldap_sasl_interactive_bind_s failed (-2)

Dec 30 12:31:44 master slapd[56]: do_syncrepl1: client_connect failed (-1)

Dec 30 12:31:44 master slapd[56]: do_syncrepl: rid=002 rc -1 retrying

</OD Master Log>

I also noticed that I am getting the following in the password server logs:

Dec 30 2011 12:35:39 71943us GETPOLICY: user {0xff176a3231f611e1aac2000c2923cc02, _ldap_replicator}.

</Password Server Log>

As there is no indication of authentication failure I am assuming that all is ok, the message from Kerberos log does however have an error in it..

2011-12-30T12:46:51 TGS-REQ _ldap_replicator@MASTER.IN.FROG.COM from 127.0.0.1:52368 for ldap/192.168.99.139@MASTER.IN.FROG.COM [canonicalize]

2011-12-30T12:46:51 Searching referral for 192.168.99.139

2011-12-30T12:46:51 Server not found in database: krbtgt/168.99.139@MASTER.IN.FROG.COM: no such entry found in hdb

2011-12-30T12:46:51 Failed building TGS-REP to 127.0.0.1:52368

2011-12-30T12:46:51 TGS-REQ _ldap_replicator@MASTER.IN.FROG.COM from 127.0.0.1:57911 for ldap/192.168.99.139@MASTER.IN.FROG.COM

2011-12-30T12:46:51 Server not found in database: ldap/192.168.99.139@MASTER.IN.FROG.COM: no such entry found in hdb

2011-12-30T12:46:51 Failed building TGS-REP to 127.0.0.1:57911

...

2011-12-30T12:40:45 AS-REQ _ldap_replicator@MASTER.IN.FROG.COM from 127.0.0.1:61919 for krbtgt/MASTER.IN.FROG.COM@MASTER.IN.FROG.COM

2011-12-30T12:40:45 Client sent patypes: encrypted-timestamp

2011-12-30T12:40:45 Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96

2011-12-30T12:40:45 Requested flags: forwardable

</Kerveros Log>

So again there does not appear to be clear indication of authentication failure.... as I assume this indicates that a Kerberos Ticket was created successfully...

I am thinking that have Kerberos just complicates things and I will remove it and then see what happens.

Cheers,

Zebity.

Reply