11 Replies Latest reply: Sep 13, 2013 6:22 AM by Scot Ohl
Nigel Moore Level 4 (1,955 points)



I recently had a lot of errors on two ML servers actinbg as OD Master/Replica, so decided to reinstall from scratch. One is running OS X 10.8.2, the other 10.8. Both are vanilla installs (going so far as to recreate the RAID), and both have the latest version of server.app installed.


Network users cannot authenticate.


Running slapconfig -ver gives the following errors on both machines:


bubbles:~ administrator$ sudo slapconfig -ver
2012-11-27 20:17:31 +0000 command: /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home
2012-11-27 20:17:31 +0000 Error execing slapcat: 50b51fdb /etc/openldap/slapd_macosxserver.conf: line 303: unknown directive <TLSCertificatePassphrase> inside backend database definition.
          slapcat: bad configuration file!
LDAP Setup Tool (slapconfig), Apple, Inc.,  Version 1.2


Obviously ou=macosxodconfig,cn=config,dc=test249,dc=home is wrong, but I don't know where this setting is held to correct it to ou=macosxodconfig,cn=config,dc=server,dc=domain,dc=tld


Opeining slapd_macosxserver.conf shows the last four lines to be:


TLSCertificateFile      /etc/certificates/server.mydomain.LONGHASH.cert.pem
TLSCACertificateFile    /etc/certificates/server.mydomain.LONGHASH.chain.pem
TLSCertificateKeyFile   /etc/certificates/server.mydomain.LONGHASH.key.pem
TLSCertificatePassphrase        "Mac OS X Server certificate management.LONGHASH"


I can 'fix' the second error by commenting out that last line. But that just results in a new and exciting error:


bubbles:~ administrator$ sudo slapconfig -ver
2012-11-27 20:43:00 +0000 command: /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home
2012-11-27 20:43:00 +0000 Error execing slapcat: slapcat: slap_init no backend for "ou=macosxodconfig,cn=config,dc=test249,dc=home"
LDAP Setup Tool (slapconfig), Apple, Inc.,  Version 1.2

Mac mini, OS X Mountain Lion (10.8.2), server
  • tesme33 Level 1 (10 points)


    i have the same issue here.


    acmini:~ admin$ sudo vi /etc/openldap/slapd_macosxserver.conf

    macmini:~ admin$ sudo slapconfig -ver

    2013-05-11 18:01:34 +0000 command: /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home

    2013-05-11 18:01:34 +0000 Error execing slapcat: 518e877e /etc/openldap/slapd_macosxserver.conf: line 302: unknown directive <TLSCertificatePassphrase> inside backend database definition.

              slapcat: bad configuration file!

    LDAP Setup Tool (slapconfig), Apple, Inc.,  Version 1.2


    intersting is that it came up once i started the server after the installation of the thunderbold firmware update.


    If i comment the line out i get the following. (as expected)


    macmini:~ admin$ sudo /usr/libexec/slapd -f /tmp/slapd.conf -d 2

    518e86e1 @(#) $OpenLDAP: slapd 2.4.28 (Nov 25 2012 15:38:05) $


    518e86e1 daemon: SLAP_SOCK_INIT: dtblsize=256

    TLS: attempting to read `/etc/certificates/macmini.D54ED3099CACE5609C2944EA9FDDFC024.key.pem'.

    TLS: could not use key file `/etc/certificates/macmini.D54ED3099CACE5609C2944EA9FDDFC024.key.pem'.

    TLS: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long /SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/asn1/asn1_lib.c:150

    518e86e1 main: TLS init def ctx failed: -1

    518e86e1 slapd stopped.

    518e86e1 connections_destroy: nothing to destroy.


    Now the question how this line should look like. Do we have an example ?


    I tried to change to no certificate usage via server.app but this doenst work.


    Tried to change the certificate for all services to another one but also didnt work.



  • tesme33 Level 1 (10 points)



    http://apple.stackexchange.com/questions/79141/how-to-fix-failing-open-directory -database-cn-authdata-cannot-be-opened-err


    $ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
    $ sudo db_recover -h /var/db/openldap/authdata/


    $ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist



    Puuh no new install :-)

  • Steven Bytnar Level 1 (0 points)

    I rebooted my server, after 9 days of uptime and found Open Directory not operational.

    I used the 3 commands above and it  started working again.



    Apple: Hey! Why is Open Directory (Apple Password Server) so darn flaky! It seems like every time I install updates and reboot the server, the Open Directory server needs to be repaired or restored from a backup.

  • OoO_Bailey_OoO Level 1 (0 points)

    I'm getting this error and the steps above aren't resolving it (with or without restart).


    sudo slaptest -f /private/etc/openldap/slapd.conf -v

    520528ec /etc/openldap/slapd_macosxserver.conf: line 303: unknown directive <TLSCertificatePassphrase> inside backend database definition.

    slaptest: bad configuration file!


    Any idea what can be done?



  • tesme33 Level 1 (10 points)


    i get the same error but authentication still works.

    Are you sure that the recovery of your password worked ?


    In case I have this issue i can only authenticate as a local user, not as an opeddir user.

    This user must have admin rights to make sudo, afaik.


    But it is interesting that my error comes on line 302 and yours on line 303.


    Below i have attache the auth part from my /etc/openldap/slapd_macosxserver.conf

    Check for any difference.



    macmini:~] user% sudo slaptest -f /private/etc/openldap/slapd.conf -v


    52054639 /etc/openldap/slapd_macosxserver.conf: line 302: unknown directive <TLSCertificatePassphrase> inside backend database definition.

    slaptest: bad configuration file!




    # authdata database definitions


    database        bdb

    suffix          "cn=authdata"

    rootdn          "uid=root,cn=users,dc=macmini,dc=domain,dc=TL"

    directory       "/var/db/openldap/authdata"

    checkpoint      128 1

    index           default eq

    index           objectClass eq

    index           authGUID eq

    index           entryUUID eq

    index           entryCSN eq

    index           draft-krbPrincipalAliases eq

    index           draft-krbPrincipalName eq

    timelimit 60

    idletimeout 300

    cachesize       20000

    idlcachesize    10000

    sizelimit size.pr=11000 size.prtotal=unlimited

    #limits          set="computer/cn & [cn=com.apple.opendirectory.group,cn=computer_groups,dc=macmini,dc=domain,dc=TL ]/memberUid" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

    access to *

                    by dn.exact="uid=_ldap_replicator,cn=users,dc=macmini,dc=domain,dc=TL" write

                    by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write


    TLSCertificateFile      /etc/certificates/macmini.D5473ED3099C09ACE59C2944EA9FDDFC024DC07.cert.pem

    TLSCertificateKeyFile   /etc/certificates/macmini.D5473ED3099C09ACE59C2944EA9FDDFC024DC07.key.pem

    TLSCertificatePassphrase        "Mac OS X Server certificate management.D5473ED3099C09ACE59C2944EA9FDDFC024DC07"

    TLSCACertificateFile    /etc/certificates/macmini.D5473ED3099C09ACE59C2944EA9FDDFC024DC07.chain.pem

  • OoO_Bailey_OoO Level 1 (0 points)

    So I messed around with OD backups and restores for a bit. The restore logs would show numerous errors and turning the services on afterward would point out errors in the OD so I ended up creating a new OD from scratch, then adding the exported users, groups, and passwords back via Workgroup Manager. Re-issued SSL certificates and fixed the settings too.


    Now everything is clean and set properly however the slapconfig -ver still gives the same error. The line numbers aren't too important. As far as I can tell, the order of the TLS entries can happen any which way. For instance, now mine reads TLSCertificatePassphrase line first at line 300 instead of 303.


    TLSCertificatePassphrase isn't even in the man page for openldap as far as I can see. The only place I see it mentioned is for an IBM product, Tivoli. So maybe that's the problem for everyone but we're the only ones noticing it?


    Anyway, I'd like to get this issue resolved plus a slapd -Tt error "5205716a bdb_monitor_db_open: monitoring disabled; configure monitor database to enable". If it's an error even. One post suggested it was just a "tip of the day" via command line.

  • makkintosshu Level 1 (0 points)

    I had the exact same problem that Nigel describes `sudo slapconfig -ver` was resulting in the "Error execing slapcat: 50b51fdb /etc/openldap/slapd_macosxserver.conf: line 303: unknown directive <TLSCertificatePassphrase> inside backend database definition." I had persused this and other threads related to being unable to perform an authenticated bind or create a replica between 10.8.4 Servers (the master was upgraded from 10.6.8, but the replica issues occurred on both other servers that were upgraded from 10.6.8 to 10.8.4 and clean installs of 10.8.4), esp. https://discussions.apple.com/thread/4356139?start=15&tstart=0.


    I found that while we had a valid signed cert installed (a wildcard for our organization), there was also a self-signed cert. I removed the self-signed cert, commented out the "TLSCertificatePassphrase" line in /etc/openldap/slapd_macosxserver.conf, stopped & slarted slapd (`sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist` followed by `sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist`), and `sudo slapconfig -ver` now prints the version info without error. This also means I'm now able to perform authenticated binds & configure new replicas, so clearly is what was causing authenticated binding & replica creation to fail since it never spit back a version number.

  • OoO_Bailey_OoO Level 1 (0 points)

    I'm not sure why, but when I follow the exact same steps as you, I end up with this error still:


    server:~ mserver$ sudo slapconfig -ver

    2013-08-31 03:23:37 +0000 command: /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home

    2013-08-31 03:23:37 +0000 Error execing slapcat: slapcat: slap_init no backend for "ou=macosxodconfig,cn=config,dc=test249,dc=home"

    LDAP Setup Tool (slapconfig), Apple, Inc.,  Version 1.2


    I didn't have a self-signed cert in addition to my valid signed one.

  • Scot Ohl Level 1 (0 points)

    I took a look inside slapconfig (version 1.2 Mountain Lion) and found that ou=macosxodconfig,cn=config,dc=test249,dc=home is hard coded into the file. It doesn't seem to be there on the Snow Leopard version (which, incidentally is also version 1.2). I'm having a look around the system now to see if I can find any other instances of this string.


    Something of note: if you

    run /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home

    while changing the dc= to your domain the test seems to work although I cannot decipher the output.

  • Simon Slavin Level 4 (1,400 points)

    The dc value is set when you create the Open Directory database in the first place.  No matter which machines are hosting that database, that value for dc remains the same.


    I once created an OD database and over the next few years gradually replaced both the Master and two Replicas we had.  So the clients were now pointed at entirely new IP addresses but they were still looking up records which referred to old computer names.

  • Scot Ohl Level 1 (0 points)

    What I'm saying is that the line ou=macosxodconfig,cn=config,dc=test249,dc=home is embedded in the slapconfig command and that it is not actually parsing that information from your OD setup...no matter what machine you are on. It would be an odd coincidence if we all configured a test249.home as our domain when we first set up our servers.


    Try this: sudo nano /usr/sbin/slapconfig and then do a search (ctrl w) for test249 so long as you are on mountain lion (client or server it doesn't seem to matter) your should see that string. To me it looks like there is no way that this test would only pass if you really did have your server setup with that domain.