Previous 1 2 Next 28 Replies Latest reply: Sep 11, 2013 7:43 AM by Tearjerker
wimpog Level 1 Level 1

Dear community


I have two new 10.8.2 servers – one is an OD master, and the other – an OD replica.

Initial replica creation goes well, but for some reason the master can't update it after that. So, for example, a password change does not propagate to the replica. I have to delete and re-create the replica, in order to get the changes.

Here are the LDAP log entries that repeat every minute:


Feb  1 12:43:03 slapd[102]: slap_client_connect: URI=ldap:// ldap_sasl_interactive_bind_s failed (-2)
Feb  1 12:43:03 slapd[102]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata)
Feb  1 12:43:03 slapd[102]: slap_client_connect: URI=ldap:// ldap_sasl_interactive_bind_s failed (-2)
Feb  1 12:43:03 slapd[102]: do_syncrep1: client_connect failed (-1) - searchbase(dc=odmaster,dc=example,dc=com)
Feb  1 12:43:03 slapd[102]: do_syncrepl: rid=004 rc -1 retrying
Feb  1 12:43:33: --- last message repeated 1 time ---
Feb  1 12:43:38 slapd[102]: SASL [conn=5714] Failure: no secret in database
Feb  1 12:43:38 slapd[102]: int slap_sasl_bind(Operation *, SlapReply *): Error to increment failed login count for uid=updater637333537,cn=users,dc=odmaster,dc=example,dc=com


A similar if not the same issue has been reported here, with no solution:


Note sure what to try.

Thank you for your help.

Mac mini, OS X Mountain Lion (10.8.2)
Solved by Tearjerker on Sep 11, 2013 7:43 AM Solved

Thanks ! Your Post and Joe Swenson´s fixed my problem!


No everthing is replicating!


What I have done:


First of all check your DNS!!!! Forward & Reverse Lookup has to work!

(nslookup in terminal)


!!!-only the replica server-!!!

1. destroyed replica-server with terminal command (command was mentioned before)

2. deleted etc/krb5.keytab (sudo rm)

3. deleted /var/db/openldap/replication (complete folder ; sudo rm -r <path-to-folder>)

4. created new replica OD




Sep 11 15:02:49 <MYREPLICADNSNAME> slapd[395]:

do_syncrep1: CONNECTED(0x7fe502c00040) searchbase(cn=authdata) URI(ldap://<MYREPLICADNSNAME>:389)


Sep 11 15:02:49 <MYREPLICADNSNAME> slapd[395]:

do_syncrep1: CONNECTED(0x7fe5029045e0) searchbase(dc=XXX,dc=XXX,dc=XXX,dc=XX) URI(ldap://<MYREPLICADNSNAME>389)


Created some accounts on my master and sync is working now on my replica.



I have NOT unbound my replica from AD (we are running the magic triangle)



If you try to connect a client to the replica server, client says, that
<MYREPLICADNSNAME> is a replica of <MYMASTERDNSNAME> and thats why it is not necessary!


Failover works like a charm!


Great! Thanks guys!

  • ryanhoye Level 1 Level 1

    I'm having nearly the same problem, though I think your logs have the two lines at the bottom which may be specific to your issue.


    Before I go any further, you do have SSL certificates configured properly on both the Master and the Replica correct?


    If this is the case, and you are using the SSL certificates that were created for you by slapconfig in the server app, then we have exactly the same issue.


    I have three machines running server.  The Master, replicates without issue to replica1, replica1 isn't running any critical services.  Replica2 is running some services of importance and cannot establish replication properly without this issue.  All three servers are using the correct configured SSL certificates.  If I configure replica2 to connect to replica1 instead of connecting directly to the master, the same issue persists.  I tried today to reformat and reconfigure replica2 from scratch, and the same error persisted.


    My next option is to wipe all of them and start over.  I'm tempted to think that this is a Kerberos authentication error for _ldap_replicator, but I can't re-kerberize the master, as apple has convieniently removed that tool.


    I'm becoming increasingly frustrated with this issue, and I really hope that the community can help.

  • wimpog Level 1 Level 1


    Thank you for your reply.


    I do have SSL certificates – one wildcard certificate that was purchased and used on both servers, and the OD master and replica have their self-generated ones. I tried using the wildcard certificate, the self-generated certificates, and using no certificate at all – none of that helped, same errors.


    I also think this has something to do with Kerberos, but I don't know how to re-kerberize that either. Since you have one replica working, do you think it is the master that's causing the problem? What kind of errors do you get in your LDAP log?


    Here is an article that explains how to set a replica up manually: -in-os-x-mountain-lion-server/

    I tried that, but it didn't work. The error I was getting:

    unable to determine the master's software version

    Very frustrating, especially, considering that the two servers I have are brand new installs.

  • ryanhoye Level 1 Level 1

    I tried doing the setup manually as well, with the same error.  I think this is an issue with apple's version of server.


    The errors I get in the LDAP are only the SASL authentication errors like yours.  My only deductive reasoning is that there is something wrong with the Master, but the Master replicates fine to another server.  Just not the one I want.


    Feb  3 20:04:49 slapd[2012]: slap_client_connect: URI=ldap:// ldap_sasl_interactive_bind_s failed (-2)

    Feb  3 20:04:49 slapd[2012]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata)

    Feb  3 20:04:49 slapd[2012]: do_syncrepl: rid=008 rc -1 retrying



    I've tried re-installing I've tried wiping the machine and installing from scratch on replica2, and to no avail.


    I've seen other answers saying that this is just a password issue for _ldap_replicator and I've matched the passwords previously and that's not it either.  At the time of writing I have a successful replication from Mater to Replica1, but Replica2 won't co-operate.


    Other posts have also mentioned something about computer records on the master not being removed and having to clean those out in order for the replication to happen.  I've seen this happen, where I've destroyed the replica and the computer replica records for that replica remain in the directory for the master.  Cleaning those out still doesn't work. 


    I'm at a loss as to why this replication is so troublesome.  Especially when you're dealing with a fresh install.  It's as if the replication tools weren't completed, or tested to completion.

  • wimpog Level 1 Level 1

    When you set your master up, did you create all user accounts from scratch, or did you import your LDAP database from an older OSX server?

    By the way, not related to this issue, but you may also want to check, and correct, if needed, this:

    Do you know if we can get some help from Apple? Seems like it is their problem, since you and I tried fresh installs and it ain't working.

  • ryanhoye Level 1 Level 1

    I had created all of my users from scratch initially, and have since exported and re-imported them a few times in order to test functionality, and the lack of replication.


    I have not yet looked into that one, but it could prove to be part of the issue.  If that hash is incorrect on _ldap_replicator then it may be part of the issue, I may have to test it at some point.


    We may be able to get some help from apple if you have applecare, they supposedly have extended support of server app functions in applecare now.  Though I think they might tell you to start over.  Which I don't think is realistic.

  • ryanhoye Level 1 Level 1

    In addition to this information: 1) the _ldap_replicator errors persist after verifying that the users have the same kerberos hash.


    2) apple releases Server 2.2.1: with a line that says "fix of setup failiures due to an SSL error.


    Will update and test.

  • wimpog Level 1 Level 1

    I applied the update to no avail.

    How did you change the kerberos hashes?

    In the error messages (yours and mine) you can see it tries to communicate on port 389, but that's insecure LDAP port, whereas the secure one is 636. I wonder if it is trying to communicate securely over an insecure port and hence the failure?

    Not sure what's going on.

  • ryanhoye Level 1 Level 1

    If that's the case, why is it doing so, and where is the configuration file that would allow us to change that.

  • wimpog Level 1 Level 1

    In > Certificates you can change that, but for some reason it didn't have any effect.

  • ryanhoye Level 1 Level 1

    You can set the certificate files there, but I can't find an actual replication settings file.  Something I can edit in terminal that can force some of these settings.


    I also can't find any successful replication logs from master to replica2.


    P.S. Use directory editor to find the kerberos hashes.

  • wimpog Level 1 Level 1

    I thought, if you set choose to use SSL certificates for certain services, they become secure, otherwise what's the point of the certificates.

    I keep getting errors, and don't know what to do now. I can't find successful replication logs either. The only way to push changes for me, is to delete and re-create the replica.

    Did you compare the Kerberos hashes on the master and the replica that's not working, and found them to be the same?

    What is going on with this? Don't know what else to do...

  • ryanhoye Level 1 Level 1

    Double check that you have the matching SSL certificates setup for the LDAP by checking the slapconfig -getldapconfig terminal commands.


    I compared Kerberos hashes on the master and on the replica and they do match.  I even checked the information in the authdata files inside /var/db/openldap and found exactly the same infomation for _ldap_replicator on both, including the correct Kerberos domain information.


    I did find extra .ldif files for previous replications, but I don't think this is the issue if your system hasn't been replicated before.

  • wimpog Level 1 Level 1

    I just checked the SSL certificates using the command you provided, and they match.

    What is the name of the hashes attribute in Directory Utility? Is it AuthenticationAuthority? I want to check that as well.


    I also ran sudo changeip -checkhostname on both, and that's fine as well.

  • ryanhoye Level 1 Level 1



    The Authentication authority is the password server it should be authenticating against, it should be related to the master's guid.


    Another question, what is the DNS setup in your situation?

Previous 1 2 Next