Currently Being ModeratedFeb 3, 2013 8:34 PM (in response to wimpog)
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.
Currently Being ModeratedFeb 4, 2013 6:28 AM (in response to ryanhoye)
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:
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.
Currently Being ModeratedFeb 4, 2013 8:39 PM (in response to wimpog)
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 master.example.com slapd: slap_client_connect: URI=ldap://replica2.example.com:389 ldap_sasl_interactive_bind_s failed (-2)
Feb 3 20:04:49 master.example.com slapd: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata)
Feb 3 20:04:49 master.example.com slapd: do_syncrepl: rid=008 rc -1 retrying
I've tried re-installing server.app 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.
Currently Being ModeratedFeb 5, 2013 8:46 AM (in response to ryanhoye)
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.
Currently Being ModeratedFeb 5, 2013 9:12 AM (in response to wimpog)
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.
Currently Being ModeratedFeb 5, 2013 1:02 PM (in response to ryanhoye)
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.
Currently Being ModeratedFeb 5, 2013 1:36 PM (in response to ryanhoye)
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.
Currently Being ModeratedFeb 5, 2013 1:55 PM (in response to wimpog)
If that's the case, why is it doing so, and where is the configuration file that would allow us to change that.
Currently Being ModeratedFeb 5, 2013 1:59 PM (in response to ryanhoye)
In Server.app > Certificates you can change that, but for some reason it didn't have any effect.
Currently Being ModeratedFeb 5, 2013 6:31 PM (in response to wimpog)
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.
Currently Being ModeratedFeb 6, 2013 7:40 AM (in response to ryanhoye)
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...
Currently Being ModeratedFeb 6, 2013 10:49 AM (in response to wimpog)
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.
Currently Being ModeratedFeb 6, 2013 12:34 PM (in response to ryanhoye)
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.
Currently Being ModeratedFeb 6, 2013 12:35 PM (in response to wimpog)
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?