The trigger can be a bad or expired certificate; see the logs for slapd.

Can also be a DNS-level configuration error; a bogus or mismatched FQDN.

Try starting slapd from the shell, via +slapd -d -1+ and see if anything interesting shows.

Google should find a few other options and possibilities here, too.

Alternatively, roll in your backup and drop back to 10.6.4 until this gets sorted. (For production configurations, it's often best to defer for a while, and then to test these upgrades before rolling them out, and to have a restoration path to allow an upgrade to be backed out for any production server. Voice of experience: being on the bleeding edge sans backups can be painful.)

First, /etc/openldap/slapd_macosxserver.conf was referencing an old certificate which I had previously deleted, even though the LDAP UI in ServerAdmin was showing the correct/current one.

(Instead of removing the old cert files, the Certificate Manager appears to truncated them to 0-length, thereby rendering them invalid.)

Second, modifying the aforementioned configuration file doesn't actually solve the problem by itself, as the slapd configuration information was cached in /etc/openldap/slapd.d, and was not correctly updated, even when I followed the man page advice of specifying -F and -f on the same command line. Removing and recreating slapd.d fixed that problem.

Finally, at least some self-signed certificates generated by the Certificate Manager appear to be corrupted. They do not validate when passed through "openssl ans1parse -inform PEM -in <filename>", giving an error about "header too long".

(This is particularly interesting as the self-same certificate was being used for a variety of other system services without complaint.)

I haven't figured out what magic incantation will allow a valid self-signed certificate to be generated using the Certificate Manager. In the interim, I have turned off SSL for LDAP; while obviously not a long term solution, it is allowing me to limp along.

I just have switched SSL for LDAP on again. I'm currently using a self signed certificate for server.mydomain.com (LDAP: dc=server,dc=mydomain,dc=com) created with Server Admin using all the default values.

I don't know if it matters, but my LDAP is configured as a Directory-Master and not as a Directory-Replica like MrHoffman is referring to.

I just want to send flowers to everyone in this thread and especially to you root 66!

Before applying the change to the file as you proposed, VPN didn't work, LDAP was down and I could not edit the records in my Open Directory database. All after the mentioned upgrade - in my case from 10.6.3 to 10.6.5. My company would have been strapped to the ground tomorrow unless I would have found this!

The appear to have also busted the client side. since the 10.6.5 update my client ldap to work isn't working. the upgrade changed my default port from 389 to 3268 and changing it back seems to be ignored. LDAP was working 30 minutes ago, not not so much, can't do lookups to the work ldap server.Has anyone seen this from the client side yet, or just me?

On the same note, I checked out my certificate folder and instead of the normal "mydomain.crt" and "mydomain.key" files, I have "mydomain.323524976529376230975230.key" and so forth. Is this normal behavior of 10.6? I am migrating from a 10.4.11 server environment, and not sure if this naming scheme is OK or is the root of my LDAP problems too. (error 14002)

More Like This

Retrieving data ...

This site contains user submitted content, comments and opinions and is for informational purposes only.
Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums.
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.