LDAP is not running after 10.6.5 update - Help!

Question

Level 1

11 points

LDAP is not running after 10.6.5 update - Help!

After10.6.5 update to LDAP doesen't run. This means the Server is practically dead, because no one can connect to it's services anymore.

Does anyone can help - PLEASE!

+Nov 11 13:44:56 server slapd[68]: @(#) $OpenLDAP: slapd 2.4.11 (Aug 12 2010 17:17:10) $+
+Nov 11 13:44:59 server slapd[68]: daemon: SLAP SOCKINIT: dtblsize=8192+
+Nov 11 13:45:08 server slapd[68]: main: TLS init def ctx failed: -1+
+Nov 11 13:45:08 server slapd[68]: slapd stopped.+
+Nov 11 13:45:08 server slapd[68]: connections_destroy: nothing to destroy.+
+Nov 11 13:45:09 server slapd[194]: @(#) $OpenLDAP: slapd 2.4.11 (Aug 12 2010 17:17:10) $+
+Nov 11 13:45:09 server slapd[194]: daemon: SLAP SOCKINIT: dtblsize=8192+
+Nov 11 13:45:10 server slapd[194]: main: TLS init def ctx failed: -1+
+Nov 11 13:45:10 server slapd[194]: slapd stopped.+

Mac OS X (10.6.3)

Posted on Nov 11, 2010 5:08 AM

Reply

Answer 1

Nov 11, 2010 5:38 AM in response to root 66

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.)

Reply

Answer 2

Nov 11, 2010 11:33 AM in response to root 66

I have the same problem.

It appears several things are going on.

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.

- Rob

Message was edited by: RobFerguson

Reply

Answer 3

root 66 Author

Level 1

11 points

Nov 11, 2010 11:35 AM in response to MrHoffman

Thank you MrHoffman. Based upon your suggestions I was finally able to fix the problem.

For all of you with may encounter a similar problem, here is what I did:

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

Right after the update, when I first realized that there is a problem with LDAP, I looked at the LDAP tab in Server Admin. It showed that SSL is turned on, but no certificate was selected.

I tried to use the default certificate, and a valid mydomain.com certificate. I also created a new self signed certificate for server.mydomain.com. Also switching off SSL altogether doesn't helped.

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

My DNS primary zone is set to mydomain.com. and the nameserver hostname is server.mydomain.com.

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

Enter: +sudo /usr/libexec/slapd -d -1+

The interesting part comes at the bottom, right before the TLS error message:

+TLS: attempting to read `/etc/certificates/www.mydomain.com.key'.+
+/usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/www.mydomain.com.key: Not a private key file managed by Mac OS X Server+
+TLS: could not use key file `/etc/certificates/www.mydomain.com.key'.+
+TLS: error:0D07207B:asn1 encoding routines:ASN1 getobject:header too long /SourceCache/OpenSSL098/OpenSSL098-35/src/crypto/asn1/asn1_lib.c:150+
+main: TLS init def ctx failed: -1+

www.mydomain.com.key belongs to an old outdated certificate, witch has long been deleted, and does not show up in Server Admin anymore.

Also +slapconfig -getldapconfig+ doesn't refer to this old SSL certificate. Instead it shows whatever certificate had been entered at the LDAP tab in Server Admin.

So I dug a bit deeper and fond it here:

/etc/openldap/slapd.d/cn=config.ldif

+olcTLSCertificateFile: /etc/certificates/www.mydomain.com.crt+
+olcTLSCertificateKeyFile: /etc/certificates/www.mydomain.com.key+
+olcTLSCACertificateFile: /etc/certificates/www.mydomain.com.chcrt+
+olcTLSCertificatePassphraseTool: /usr/sbin/certadmin --get-private-key-passphr+
+ase /etc/certificates/www.mydomain.com.key+

After removing these 5 lines and restarting the service (and also the server to be 100% safe) the LDAP problem was fixed.

Reply

Answer 4

Nov 11, 2010 11:43 AM in response to RobFerguson

[Becoming a CSA to sign SSL certs for Open Directory Replicas|http://www.afp548.com/article.php?story=20080624005724638] has the core sequence for this.

Reply

Answer 5

root 66 Author

Level 1

11 points

Nov 11, 2010 12:05 PM in response to RobFerguson

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.

Message was edited by: root 66

Reply

Answer 6

Nov 11, 2010 1:20 PM in response to root 66

That article was (also) discussing Open Directory.
Ignore that section.
Follow the discussion on the certificates.

Reply

Answer 7

Nov 13, 2010 3:49 PM in response to MrHoffman

Everyone in this thread clearly knows way more about this stuff than I do, but I am having the same problem. I turned off SSL, and I still cannot get LDAP to run. Any progress on this?

Reply

Answer 8

yswd

Level 1

0 points

Nov 14, 2010 5:13 AM in response to root 66

I had exactly the same problem.

But the procedure below solved it.
Thank you very much!!

/etc/openldap/slapd.d/cn=config.ldif

olcTLSCertificateFile: /etc/certificates/www.mydomain.com.crt
olcTLSCertificateKeyFile: /etc/certificates/www.mydomain.com.key
olcTLSCACertificateFile: /etc/certificates/www.mydomain.com.chcrt
olcTLSCertificatePassphraseTool: /usr/sbin/certadmin --get-private-key-passphr
ase /etc/certificates/www.mydomain.com.key

After removing these 5 lines and restarting the service (and also the server to be 100% safe) the LDAP problem was fixed.

Reply

Answer 9

Nov 14, 2010 9:36 AM in response to root 66

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!

And now it all seems to work as it should!

Many thank's!

Reply

Answer 10

Nov 14, 2010 11:54 AM in response to root 66

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?

Reply

Answer 11

Nov 16, 2010 7:49 PM in response to root 66

I had the same problem and it affected my mail server because none of the user accounts were accessible. This worked perfectly!!!

etc/openldap/slapd.d/cn=config.ldif

olcTLSCertificateFile: /etc/certificates/www.mydomain.com.crt
olcTLSCertificateKeyFile: /etc/certificates/www.mydomain.com.key
olcTLSCACertificateFile: /etc/certificates/www.mydomain.com.chcrt
olcTLSCertificatePassphraseTool: /usr/sbin/certadmin --get-private-key-passphr
ase /etc/certificates/www.mydomain.com.key

After removing these 5 lines and restarting the service (and also the server to be 100% safe) the LDAP problem was fixed.

Reply

Answer 12

steagl3

Level 1

4 points

Dec 10, 2010 5:55 PM in response to brianysus

Excuse my ignorance, but how do you edit the cn=config file?

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)

Reply

Answer 13

steagl3

Level 1

4 points

Dec 13, 2010 12:00 PM in response to steagl3

Ah I see that it's a directory not a file, but still a little confused. This is what's in the directory:

cn=schema
cn=schema.ldif
olcDatabase={-1}frontend.ldif
olcDatabase={0}config.ldif

I checked the contents of these files and didn't see anything mentioning old TLS certificates, so I'm obviously missing something here... any help appreciated!

Reply

Answer 14

Dec 16, 2010 1:16 PM in response to brianysus

This worked for me too. Thank God I found this. Dammit Apple! 🙂

Reply

Answer 15

gobi876h

Level 1

8 points

Dec 18, 2010 6:01 PM in response to root 66

I suffered from the same issue but was unable to resolve using the above methodology because the cn=config.ldif file was gone. I thought that this was an issue from the 10.6.5 upgrade, but my backups show that this stretches back to at least the 10.6.4 upgrade. For some reason, nothing came of missing the file until 10.6.5 came and the whole house of cards fell in (i'm also missing /usr/libexec/slurpd, but that's a different story). I solved the issue by recreating the cn=config.ldif file using /usr/bin/slaptest -f /etc/openldap/slapd.conf -F slapd.d in the /etc/openldap directory. With the .ldif in place, I could then get SSL turned back on.

Reply