users cannot authenticate

Hi

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

root@springsteen.apple.com:/private/var/tmp/OpenLDAP/OpenLDAP-208.2~2/servers/slapd

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.

Yours

solution:

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

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.

Thanks!

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.

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?

Thanks

Hi

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

Password:

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

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.

I had the exact same problem that Nigel describes `

sudo slapconfig -ver

Error execing slapcat: 50b51fdb /etc/openldap/slapd_macosxserver.conf: line 303: unknown directive <TLSCertificatePassphrase> inside backend database definition.

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

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.

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.

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.

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.