Skip navigation

LDAP is not running after 10.6.5 update - Help!

14839 Views 28 Replies Latest reply: Jan 14, 2014 4:02 PM by jhdore RSS
1 2 Previous Next
root 66 Level 1 Level 1 (10 points)
Currently Being Moderated
Nov 11, 2010 5:08 AM
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: SLAPSOCKINIT: 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: SLAPSOCKINIT: 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)
  • MrHoffman Level 6 Level 6 (11,710 points)
    Currently Being Moderated
    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.)
  • RobFerguson Calculating status...
    Currently Being Moderated
    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
    MacMini Server, Mac OS X (10.6.5)
  • MrHoffman Level 6 Level 6 (11,710 points)
    Currently Being Moderated
    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.
  • MrHoffman Level 6 Level 6 (11,710 points)
    Currently Being Moderated
    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.
  • Jason Browdy Level 1 Level 1 (25 points)
    Currently Being Moderated
    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?
  • yswd Calculating status...
    Currently Being Moderated
    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.
    iMac, Mac OS X (10.6.5), Mac Mini
  • Tobias Ahl Calculating status...
    Currently Being Moderated
    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!
    MacBook Pro 13" late 2009, Mac OS X (10.6.5), Mixed Win/Mac server environment
  • Rob in Katy, TX Calculating status...
    Currently Being Moderated
    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?
    MacBook Pro, Mac OS X (10.6.5)
  • brianysus Calculating status...
    Currently Being Moderated
    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.
    Mac Mini, Mac OS X (10.6.5)
  • steagl3 Calculating status...
    Currently Being Moderated
    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)
    XServe 3,1, Mac OS X (10.6.5)
  • steagl3 Level 1 Level 1 (0 points)
    Currently Being Moderated
    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!
    XServe 3,1, Mac OS X (10.6.5)
  • B. Kennedy Level 3 Level 3 (635 points)
    Currently Being Moderated
    Dec 16, 2010 1:16 PM (in response to brianysus)
    This worked for me too. Thank God I found this. Dammit Apple!
    24" iMac Aluminum 2.4ghz, Mac OS X (10.5.3), 4GB RAM
1 2 Previous Next

Actions

More Like This

  • Retrieving data ...

Bookmarked By (3)

Legend

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