Skip navigation

10.8 Server: Problems Updating an Open Directory Replica

6795 Views 28 Replies Latest reply: Sep 11, 2013 7:43 AM by Tearjerker RSS
1 2 Previous Next
wimpog Level 1 Level 1 (0 points)
Currently Being Moderated
Feb 1, 2013 10:08 AM

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)
  • ryanhoye Level 1 Level 1 (0 points)

    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.

  • ryanhoye Level 1 Level 1 (0 points)

    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.

  • ryanhoye Level 1 Level 1 (0 points)

    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 (0 points)

    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.

  • ryanhoye Level 1 Level 1 (0 points)

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

  • ryanhoye Level 1 Level 1 (0 points)

    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.

  • ryanhoye Level 1 Level 1 (0 points)

    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.

  • ryanhoye Level 1 Level 1 (0 points)



    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?

1 2 Previous Next


More Like This

  • Retrieving data ...

Bookmarked By (4)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.