El Capitan security update 2017-005 kills LDAP?

Jeffrey,

don't know if you've seen this Announcement of Apple?

It seems, that Apple is going to kill the Server, besides you are using it only for MDM.

I think it doesn't matter how the new MacPro will be, with this Announcement you will not want to use it only for a little Device Management – it will be just too expensive for this. So we can hope, that maybe it will be a good workstation again.

If you need local sever services, Apple now said it indirectly themselves, go and get a machine with Linux and / or Windows Server on it.

How disappointing 😠

All the best,

Darko

Thank you for your reply.

I think I've tried almost everything you can find on the Internet. Got more than 50 sites open right now only with LDAP troubleshooting 😕

Destroying and restoring the OD was the second thing after checking the DNS settings. Didn't help.

Right now we're having the System running with the state before the update and our iChat ist working without any problems.

Only our two QNAP NAS don't show any Users or Groups, but they show our LDAP Server as "online" and no errors in the logs.

But the Server is filling his slapd.log with:

server1 slapd[46338]: odusers_krb_auth: Error obtaining credentials for username_we_set_in_NAS: -1765328228

This is weird, because we're not using Kerberos.

Even when I unload the /System/Library/LaunchDaemons/com.apple.Kerberos.kdc.plist the entries in the logs still keep comming.

Just tried the db_recover again and it dindn't help too.

Thank you again Jeffrey,

sudo db_recover -h /var/db/openldap/open-ldap-data/ gave no error.

I did the ODmaster reset yesterday the same way you do. But I can repeat it only when the guys are gone here and no one is working. I'll try it again asap.

All our machines are using the same ntp-server and have the same time.

I just tried the disconnect - reboot - reconnect with the small NAS (only for backups and testing) … still the same. Server "online" but no users and groups and still getting the messages in the slapd.log

Hi and sorry for my late reply … had some other stuff to do, so I had to pause this problem.

The NAS models are QNAP TVS-EC 880 and a TS-453 Pro. There is not much you can change on the NAS and it's hard to find good information about the possibilities of the command line of QNAP.

Your link is about getting OD connected to AD with kerberos, and we don't have an AD-Server.

But I've tried rekerberizing our OD a bunch of times the Apple way (touch /var/db/openldap/migration/.rekerberize …) and as far I can say nothing happened. Maybe because we don't use kerberos or maybe I just don't know where I could find any changes or see that something happened.

I was also able to try the LDAP desroying and restoring and now I can say, that there must be something fundamental wrong with our OD and I just can't find any clou what happened there.

When I restore a fresh backup of the OD, almost everything will work. Only the QNAP machines don't get any informations of the Users and Groups in the OD, like described before.

I tried to restore a old Backup (Nov. 2016) from the OD and than the QNAPs instantly showed all Users and Groups like it was before this problem started.

But after a restart of the server the OD was always off and I wasn't able to start it again.

I tried than:

server1:~ admin$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
Password:
/System/Library/LaunchDaemons/org.openldap.slapd.plist: Could not find specified service
server1:~ admin$ sudo /usr/libexec/slapd -Tt
5a5c9b9f bdb(dc=xxxx,dc=xxxx,dc=xxxx): file id2entry.bdb has LSN 1/2120018, past end of log at 1/42237
5a5c9b9f bdb(dc=xxxx,dc=xxxx,dc=xxxx): Commonly caused by moving a database from one database environment
5a5c9b9f bdb(dc=xxxx,dc=xxxx,dc=xxxx): to another without clearing the database LSNs, or by removing all of
5a5c9b9f bdb(dc=xxxx,dc=xxxx,dc=xxxx): the log files from a database environment
5a5c9b9f bdb(dc=xxxx,dc=xxxx,dc=xxxx): /var/db/openldap/openldap-data/id2entry.bdb: unexpected file type or format
5a5c9b9f bdb_db_open: database "dc=xxxx,dc=xxxx,dc=xxxx": db_open(/var/db/openldap/openldap-data/id2entry.bdb) failed: Invalid argument (22).
5a5c9b9f backend_startup_one (type=bdb, suffix="dc=xxxx,dc=xxxx,dc=xxxx"): bi_db_open failed! (22)
slap_startup failed (test would succeed using the -u switch)

A recovery with:

sudo db_recover -cv -h /var/db/openldap/authdata/

wasn't possible.

I also tried to make a dump of the OD in a LDIF and restore it like described here.

Sadly no luck either.

Right now I'm thinking of copying as much as possible out of the OD to a text file and recreating it manually. Then I'll search for a solution to use Linux as a server for Filesharing and User management with OS X Clients.

Or do you have any other ideas I should try?

I miss our Snow Leopard Server 😢 – the last realy stable and real Server System of Apple.

Wasn't perfect, but much better than this.

DB_yousign wrote:

But I've tried rekerberizing our OD a bunch of times the Apple way (touch /var/db/openldap/migration/.rekerberize …) and as far I can say nothing happened. Maybe because we don't use kerberos or maybe I just don't know where I could find any changes or see that something happened.

Just found the mistake, I used "killall PasswordService" instead of "slapconfig -firstboot" 😊

Now the rekerberizing worked, but still no change at the NAS.

Hi again,

we still did not manage to get rid of the problem, so we decided to set up an Linux VM with Samba 4 and AD DC. We found a good solution for this in the Univention Corporate Server (UCS).

Right now the UCS is working and we can bind our Clients an NAS boxes to it and it seems to work quite well.

I'll do now some intensive testing with it and if everything is ok, we will start to move as much services as possible away from the OS X Server.

It seems, that this is the begining of the end of OS X Server in our company. Maybe it's the best, because Apple has showed in the last years, that they're obviously not interested any more in professional business customers, besides they are only using iOS devices, in love with glossy displays and ok with OSs which are still beta.