Novell Migration: Kritische Legacy-Applikationen mit OpenLDAP-Proxy umstellen

In diesem Artikel möchte ich den LDAP-Proxy als Möglichkeit zur Umstellung für “unmigrierbare” Applikationen vorstellen.

Dieses Thema ist besonders für kritische Legacy-Applikationen interessant, die im Rahmen einer Novell Migration umgestellt werden müssen.

Ein Schritt-für-Schritt Tutorial für OpenLDAP-Proxy
 

Novell eDirectory nach Active Directory migrieren

In der letzten Jahren werden Migration von Novell eDirectory nach Microsoft Active Directory immer häufiger.
Das Ziel einer solchen Migration ist meist die vollständige Abschaltung des alten Verzeichnisdienstes und die Übernahme aller Funktionen durch den neuen Verzeichnisdienst.

Leider gibt es manchmal aber produktionskritische Legacy-Applikationen, die speziell für den Zugriff auf das eDirectory zugeschnitten sind. Wenn Sie Applikationen im Einsatz haben, welche nicht ohne Weiteres gegen das Active Directory umgestellt werden können, möchte ich Ihnen heute eine Alternative vorstellen, an die nicht oft gedacht wird: Ein LDAP-Proxy.
 

Ausgangssituation

Bei einem Kunden waren wir neulich in der Situation innerhalb kürzester Zeit einige hundert Legacy-Anwendungen, welche eine Authentifizierung gegen das eDirectory durchführen gegen das Active Directory umzustellen. Die Anpassung der Anwendungen selbst war aus Zeitgründen keine Option. Wir wussten aber, dass die Anwendungen für den Zugriff auf das eDirectory alle denselben DNS-Record ansprechen.
 

DNS-Record umstellen nicht möglich

Die erste Idee war es zu testen, ob wir diesen DNS-Record einfach direkt gegen das Active Directory umstellen können. Dies hat aus verschiedenen Gründen nicht funktioniert.

Die Gründe waren u.a.:

• Anonymer Zugriff: Die Anwendungen führen beim Login zunächst einen Anonymous Bind durch, um den DistinguishedName des Users zu finden. Anschließend führen die Anwendungen einen Simple Bind mit dem DistinguishedName und dem eingegebenen Passwort durch. Der Kunde wollte keinen öffentlichen anonymen Zugriff auf das AD zulassen.
   
• Keine Searchbase: Beim eDirectory ist es möglich einen LDAP-Query auch ohne die Angabe einer Searchbase durchzuführen. Die Anwendungen haben daher einfach einen leeren String übergeben.
   

Lösung über OpenLDAP-Proxy

Der OpenLDAP-Proxy löst beide Probleme. OpenLDAP lässt standardmäßig einen Anonymous Bind zu, allerdings ist hierfür keine Veränderung im Active Directory nötig. Obwohl der Zugriff auf den Proxy anonym funktioniert, wird der eigentliche Bind gegen das Active Directory über einen Service-Account durchgeführt. Dadurch ist es leichter zu kontrollieren wer “anonym” auf das Active Directory zugreift.

Weiterhin ist es bei OpenLDAP möglich eine “Default Searchbase” zu hinterlegen, welche automatisch genutzt wird, wenn keine Searchbase übertragen wird.
 

Vorbereiten von OpenLDAP

OpenLDAP ist eine Open Source LDAP-Lösung und frei verfügbar. Die Einrichtung als Proxy ist einfach und schnell. Wir benötigen für die Installation folgendes:

• Linux-Server
• openldap Packet für Linux
• Active Directory
• Service-Account im Active Directory (keine besonderen Rechte nötig, wenn nur gelesen werden soll)

Beschreibung Testumgebung

Die IP 192.168.1.11 gehört dem ersten Domain Controller meiner Test-Domäne “Sanctuary”. Der DC läuft für die Testumgebung auf meinem Notebook (in einer Virtuellen Maschine) und befindet sich in meinem lokalen Netzwerk.

Mein Linux-Server hat die IP 192.168.1.1 und ist gleichzeitig mein Gateway und DNS-Server (siehe oben):

Installation

Für meine Test-Umgebung werde ich ArchLinux verwenden, da ich bereits einen Server auf meinem Raspberry Pi zuhause habe. Die Installation sollte auf den meisten Linux-Distributionen ziemlich analog laufen.
 

[root@piserv1 ~]# pacman -Sy openldap

Für die Konfiguration als LDAP-Proxy müssen wir die Datei “slapd.conf” bearbeiten. Zunächst werden wir aber die Default-Version der Datei sichern:

[root@piserv1 ~]# mv /etc/openldap/slapd.conf /etc/openldap/slapd.conf.backup

Anschließend werden wir einen neue “slapd.conf” mit folgendem Inhalt erstellen:

[root@piserv1 ~]# nano /etc/openldap/slapd.conf

Nachdem wir die Datei gespeichert haben müssen wir zunächst alles in dem Verzeichnis /etc/openldap/slapd.d/ löschen:

[root@piserv1 ~]# rm -r /etc/openldap/slapd.d/*

Warnung: Dies bewirkt, dass alle eventuell vorhandenen Verzeichnisse und Datenbanken auf dem OpenLDAP-Server gelöscht werden!

Anschließend erstellen wir eine aktuelle Konfiguration mit dem Befehl “slaptest”:

[root@piserv1 ~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/

Da wir den letzten Befehl als root ausgeführt haben, müssen wir noch den User “ldap” als Besitzer für alle Dateien im Verzeichnis “/etc/openldap/slapd.d” eintragen:

[root@piserv1 ~]# chown -R ldap: /etc/openldap/slapd.d/

Um den Proxy zu aktivieren, starten wir nun den “slapd” Service neu:

[root@piserv1 ~]# systemctl restart slapd

Das war’s! Nun ist unser Proxy einsatzbereit.
 

Test

Als Test können wir z.B. das Tool “ldp.exe” verwenden. Um eine Verbindung zu einem LDAP-Verzeichnis herzustellen clicken wir auf “Connection” und “Connect…”

Anschließend geben wir die IP-Adresse unseres Proxys ein:

Wie wir sehen sind wir zu einem OpenLDAP-Verzeichnis verbunden:

Nun können wir einen Bind ausführen indem wir wieder auf “Connection” und anschließend auf “Bind…” klicken.
Als Authentifzierungsmethode wählen wir Simple Bind:

Wichtig: Bei einem Simple Bind muss immer der DistinguishedName des Users angegeben werden!

Die Authentifizierung funktioniert:

Um das Verzeichnis nun zu browsen klicken wir auf “View” und dann auf “Tree”:

Wir müssen dann den DistinguishedName der Domäne eingeben:

Und wir können Browsen:

Natürlich funktioniert der Zugriff mit jedem beliebigen LDAP-Browser, wie z.B. auch dem Softerra LDAP Browser:

Um zu zeigen, dass der anonyme Zugriff auch funktioniert, werden wir mit Softerra diese Option wählen:

Schlusswort

Dies ist nur ein sehr kurzer Einblick in die Möglichkeiten eines LDAP-Proxys. Viele weitere Dinge sind möglich, aber würden den Umfang eines Blog-Artikels sprengen.

Dieser Artikel versucht den LDAP-Proxy als Möglichkeit für “unmigrierbare” Applikationen darzustellen. Ich hoffe ich habe einigen Lesern auf der Suche nach einer Lösung für ihre Legacy-Applikationen bei einer AD-Migration einen Hoffnungschimmer gezeigt.