Herausforderungen beim Umstieg von OpenLDAP auf 389 DS

Alleine durch den hohen Verbreitungsgrad von Active Directory (AD) und dessen integrierte LDAP-­Schnittstelle ist das seit den 1990er-Jahren entwickelte Protokoll heute praktisch allgegenwärtig. Zwar deckt AD viele Anforderungen rund um die Verwaltung von Benutzern bereits ab, doch damit sind die Einsatzmöglichkeiten von Verzeichnisdiensten wie LDAP längst nicht erschöpft. Benötigt eine Anwendung strikte Konformität zu LDAP-Standards, stößt AD mitunter an seine Grenzen. Auch hauseigene Objektklassen und Attribute spielen Administratoren erfahrungsgemäß nur widerwillig ins AD ein, denn solche Schemaerweiterungen sind dort nicht mehr rückgängig zu machen. Die bessere Alternative sind deshalb oft eigenständige, standardkonforme LDAP-Verzeichnisdienste mit applikations- und sitespezifischen Schemaerweiterungen.

Unter Linux heißt der Platzhirsch in diesem Bereich seit jeher OpenLDAP. Als Nutzer einer Distribution mit kommerziellem Support wie Red Hat Enterprise Linux (RHEL) oder SUSE Linux Enterprise Server (SLES) hatte man Zugriff auf OpenLDAP-Server-Pakete inklusive Bug- und Security-Fixes und konnte bei Pro­blemen den Linux-Distributor in die Pflicht nehmen. Dies hat sich mit den jüngsten Major Releases dieser beiden Distri­­butionen geändert: RHEL 8 liefert von OpenLDAP lediglich die Clientkommandos und Bibliotheken mit. Der OpenLDAP-­Server slapd bleibt außen vor. Auch SUSE schlägt einen ähnlichen Weg ein: SLES 15 verbannt den Open­LDAP-slapd ins primär für Migrationszwecke gedachte Legacy-­Modul und kündigt an, ihn nicht mehr über den kompletten Lebenszyklus von SLES 15 zu unterstützen. Stattdessen setzen beide Distributionen nun ganz auf den 389 Directory Server, kurz 389 DS – benannt nach dem TCP/IP-Standard-Port für LDAP.