LDAP-Benutzerauthentifizierung für Apache 2 und Tomcat

Viele Admins setzen auf LDAP[1], um Benutzerdaten zentral zu speichern. Damit vereinheitlichen sie die Authentifizierung am Linux-System, am E-Mail-Server oder am Samba-Verzeichnis. Weniger bekannt ist, dass auch Webserver die Userdaten von dort beziehen können. Dieser Artikel beschreibt die Vorgehensweise für Apache 2[2] und Tomcat[3]. Die einzelnen Schritte für eine erfolgreiche Authentifizierung gegen einen LDAP-Server sind:

• Ein Anwender greift auf einen geschützten Bereich des
  Webservers zu, dieser fragt Benutzerkennung und Passwort ab.
• Der Webserver stellt eine initiale Verbindung zum LDAP-Server
  her. Dabei tritt er entweder anonym auf oder verwendet eine eigene
  Webserver-Kennung. Der anonyme Zugang ist zwar einfacher, aber
  weniger sicher, da er freien Lesezugriff auf die Benutzerdaten im
  LDAP-Server voraussetzt.
• Mit der initialen Verbindung sucht der Webserver nach dem
  Usereintrag, der zur Benutzerkennung passt. Als Kennung verwendet
  er ein eindeutiges Attribut im LDAP-Server, etwa die User-ID oder
  E-Mail-Adresse.
• Der Webserver startet eine neue Verbindung zum LDAP-Server, in
  der er sich mit den Daten des Benutzers ausweist, also mit dem
  zuvor gefundenen Benutzereintrag und dem vom User eingegebenen
  Passwort.
• Eventuell prüft der Webserver weitere Bedingungen, zum
  Beispiel zusätzliche Attribute oder die Mitgliedschaft in
  einer Gruppe.
• War die zweite Authentifizierung erfolgreich, ist der Benutzer
  gültig und der Webserver liefert die Daten aus.

In Apache und Tomcat sind die Routinen für diesen Ablauf bereits fertig implementiert, der Webmaster muss nur noch die Konfigurationsdateien anpassen. Als Basis für die folgenden Beispiele dient ein typischer LDAP-Server wie er in Abbildung 1 zu sehen ist (dargestellt im sehr empfehlenswerten LDAP-Frontend JXplorer[4]). Unter der Domäne »groygroy.de« enthält er Organisationseinheiten, Personen und Gruppeneinträge.

Apache 2

Um seine Benutzer gegen einen LDAP-Server zu authentifizieren, benötigt Apache 2 die drei Module Mod_auth, Mod_ldap und Mod_auth_ldap. Ein Eintrag in der Konfigurationsdatei »loadmodule .conf« steuert, welche Module der Webserver lädt. Einige Distributionen bringen dafür auch praktische Konfigurationstools mit.

Listing 1 zeigt die relevante Konfiguration des Webservers. Der erste Abschnitt (bis Zeile 14) definiert den öffentlich zugänglichen Webbereich. Die Files dafür liegen im Verzeichnis »/srv/www/htdocs« (Zeile 4), der Server liefert sie an jeden Besucher aus. Der nächste Abschnitt beschreibt einen geschützten Mitgliederbereich unter »/mitglieder« (Zeilen 17 bis 34). Die Dateien liegen im Verzeichnis »/srv/www/mitglieder« (Alias-Eintrag in Zeile 17).

LDAP einbinden

Wegen der »AuthLDAPEnabled«-Direktive in Zeile 21 authentifiziert der Webserver jeden Zugriff gegen den LDAP-Server. Damit er die dazu nötigen Daten im LDAP-Verzeichnis einsehen darf, muss sich Apache zunächst selbst authentifizieren. Zu diesem Zweck enthalten die Zeilen 22 und 23 den DN (Distinguished Name) und das Passwort für die initiale Verbindung.

Das Kernstück für die Konfiguration ist die »AuthLDAPUrl«-Anweisung. Sie hat folgendes Format:

AuthLDAPUrl ldap://Host:Port/BaseDN?
  Attributname?Suchtiefe?Filter

Host und Port bestimmen, wo Apache den LDAP-Server findet. Der Base-DN bezeichnet den LDAP-Eintrag, unter dem der Webserver nach den Benutzereinträgen suchen soll. Das gewünschte Objekt muss die Benutzerkennung in dem gegebenen Attribut enthalten. Meist wird dies wie im Beispiel die »uid« sein (Zeile 24), andere Attribute wie »mail« sind ebenso möglich. Die Treffer müssen entweder direkt unter dem Base-DN zu finden sein (Suchtiefe »one«) oder dürfen sich beliebig tief im LDAP-Baum verstecken (Suchtiefe »sub«). Bei Bedarf kann ein Filter die Suche weiter einschränken, im Beispiel betrachtet »(objectclass=person)« ausschließlich Einträge vom Typ »person«.

Die Require-Direktiven in den Zeilen 27 bis 29 beschränken die Menge der gültigen Personen noch weiter, zum Beispiel auf Benutzer mit einer speziellen ID oder einem bestimmten DN. Der untere Abschnitt der Konfiguration (Zeilen 42 bis 59) nutzt das Verfahren, um die Mitgliederdateien zusätzlich unter der Webadresse »/schreiben« (Alias in Zeile 40) per Webdav auszuliefern, und zwar nur für Mitglieder der Gruppe »cn=schreiben,dc=groygroy.de« (Require in Zeile 53). Diese dürfen schreibend auf den Server zugreifen (»Dav on« in Zeile 43).