© Michael Schulze, Fotolia
Statt die Authentifizierung und Rechtezuordnung für die Nutzer von Webanwendungen aufwändig mittels Tabellen in Datenbanken zu managen, lässt sich diese Aufgabe als Admin auch bequem und sicher über ein vorhandenes LDAP erledigen.
Warum LDAP für das Benutzer-Backend einsetzen? In vielen Unternehmen und kleinen Organisationen ist ein LDAP bereits vorhanden. Mitarbeiter und andere Benutzer verfügen dann schon über ein Benutzerkonto mit einem zugehören Passwort sowie einigen anderen relevanten Daten, zum Beispiel der E-Mail-Adresse und der Zugehörigkeit zu bestimmten Benutzergruppen.
Diese vorhandenen Informationen lassen sich für nahezu beliebige Webanwendungen wiederverwenden. Vorteil für Administratoren: Durch das zentrale LDAP müssen sie Benutzer und deren Daten nur an einer Stelle pflegen.
Der Benutzer der Webanwendung, die damit verbunden ist, authentifiziert sich dann direkt gegen den Verzeichnisdienst. LDAP seinerseits kann ohne weitere Schwierigkeiten und bei Bedarf auch mit einer verschlüsselten Verbindung auf einem anderen System laufen. Eine mögliche Chaos-Ursache weniger ist das erfreuliche Ergebnis.
Variationen
Für die gängigen Webanwendungen gibt es zwei mögliche Varianten der Umsetzung für die LDAP-Anbindung. Zum einen lässt sich der Apache-Webserver seit Version 2.1 mit Hilfe des Moduls »mod_authnz_ldap« [1] für die Authentifizierung nutzen, alternativ bieten diverse Webanwendungen eine eigene Schnittstelle für die Integration mit einem LDAP an.
In diesem Fall findet die Kommunikation zwischen Webapplikation und dem LDAP-Server statt. Für einige Webanwendungen muss das LDAP-Schema auch um anwendungseigene Objektklassen und Attribute erweitert werden.
Zum Beispiel Trac
Die Teamsoftware Trac [2] lässt sich in allen genannten Varianten betreiben, weshalb sich die folgenden Beispiele auf die Umsetzung der genannten Varianten mit Trac beziehen. Open LDAP ist in dem Beispiel die Gegenstelle.
Wer sich für die beiden Möglichkeiten ohne Schema-Anpassung entscheidet, sollte bedenken, dass diese von Haus aus nur Funktionalität für die Authentifizierung der Benutzer bieten. Um auf Basis von LDAP-Gruppen Berechtigungen zu verteilen, ist die Installation des LDAP-Plugins [3] erforderlich.
Einfache Methode
Die für den Admin schneller zu erledigende Variante ist eindeutig die Integration in den Apache-Webserver. Für Trac fügt er dafür lediglich ein »LocationMatch« , wie in Listing 1 zu sehen ist, in die Apache-Konfiguration ein. Bereits durch diese kleine Anpassung – und in der Regel ohne weitere Konfigurationsänderung in der Teamsoftware – stellt Trac dann auf LDAP-Authentifizierung um. Die Zeilen zu »Require ldap-group« begrenzen hier übrigens nur den grundsätzlichen Zugriff, Berechtigungen innerhalb der Teamsoftware lassen sich damit nicht festlegen.
Listing 1
LocationMatc
01 <LocationMatch /trac/login> 02 AuthType Basic 03 AuthName "Test Trac" 04 05 AuthBasicProvider ldap 06 AuthLDAPUrl "ldap://192.168.122.10/dc=test,dc=local" 07 # Nur bestimmte Gruppen erlauben 08 AuthLDAPGroupAttributeIsDN off 09 AuthLDAPGroupAttribute memberUid 10 Require ldap-group cn=Entwickler,ou=Gruppen,dc=test,dc=local 11 Require ldap-group cn=Test,ou=Gruppen,dc=test,dc=local 12 Require ldap-group cn=NochEine,ou=Gruppen,dc=test,dc=local 13 </LocationMatch>
Erweiterte Funktionalität
Die weitaus komplexere Variante bringt eine Open-LDAP-Schema-Erweiterung und die Installation von drei Trac-Plugins mit sich. Die Plugins »LdapPlugin« [3], »LdapAuthStore« [4] und »AccountManagerPlugin« [5] installiert der Admin am besten mit Hilfe von »pip« [6]. Das Plugin »LdapAuthStore« muss er direkt über die Projektseite manuell herunterladen und die Zip-Datei entpacken. Er erhält eine Ordnerstruktur wie in Abbildung 1.
Abbildung 1: Ordnerstruktur des »LdapAuthStore«-Plugins.
Nun ist noch eine Änderung im Pfad »ldapauthstoreplugin/0.11/setup.py« notwendig. Er erreicht ihn über »setup.py« . Den Eintrag
install_requires = [ 'TracAccountManager',
'LdapPlugin', ],
ändert er so ab, dass dieser anschließend so aussieht:
install_requires = [ 'TracAccountManager',
'TracLdapPlugin', ],
Dann installiert er, wie in Listing 2 zu sehen, die einzelnen Plugins.
Listing 2
Installation der Plugins
01 # auf Debian basierende Systeme 02 apt-get install python-pip 03 # CentOS / RHEL 04 yum install python-pip 05 06 pip install TracLdapPlugin 07 pip install TracAccountManager 08 pip install ldapauthstoreplugin/0.11/
Um die Schema-Erweiterung für Trac in Open LDAP einzuspielen, muss der Admin zuvor sicherstellen, dass die Schemata »cosine« und »nis« bereits Bestandteil von Open LDAP sind. Die Suche und das Hinzufügen beschreibt Listing 3.
Listing 3
Schema-Erweiterung
01 ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config cn=\{*\}nis
02 ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config cn=\{*\}cosine
03
04 # Hinzufügen wenn nicht vorhanden
05 # auf Debian basierende Systeme
06 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
07 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
08 # CentOS / RHEL
09 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
10 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
Sobald sichergestellt ist, dass »cosine« und »nis« enthalten sind, lässt sich das eigentliche Trac-Schema (Abbildung 2) hinzufügen. Das Schema ist im Netz schwer zu finden und liegt deshalb den Listings zum Artikel bei. Der Admin fügt es mit »ldapadd -Y EXTERNAL -H ldapi:/// -f trac.ldif« hinzu.
Abbildung 2: Der Inhalt des Schemas »Trac.ldif«.
Nachdem die Vorkehrungen für die LDAP-Integration getroffen sind, ist noch die Trac-Konfiguration anzupassen, damit die Applikation LDAP für die Benutzer-Authentifizierung und die Rechte-Zuordnung nutzt. Relevante Änderungen und Erweiterungen sind in Listing 4 dargestellt. Wer weitere Konfigurationsparameter sucht, findet auf Trackhacks.org [7] eine ganze Reihe davon.
Listing 4
Trac-Konfiguration anpassen
01 [trac] 02 permission_store = LdapPermissionStore 03 04 [account-manager] 05 password_store = LdapAuthStore 06 07 [components] 08 acct_mgr.admin.accountmanageradminpage = enabled 09 acct_mgr.api.accountmanager = enabled 10 acct_mgr.web_ui.accountmodule = enabled 11 acct_mgr.web_ui.loginmodule = enabled 12 trac.web.auth.loginmodule = disabled 13 ldapplugin.* = enabled 14 ldapauthstore.* = enabled 15 16 [ldap] 17 enable = true 18 basedn = dc=example,dc=org 19 user_rdn = ou=people 20 group_rdn = ou=groups 21 store_bind = true 22 bind_user = cn=tracadmin,dc=example,dc=org 23 bind_passwd = mypasswd
Sind diese Änderungen gespeichert, können sich alle LDAP-Benutzer im Trac anmelden. Sollen nur Nutzer mit bestimmten Objektklassen oder anderen über LDAP-Filter abbildbaren Voraussetzungen Zugriff haben, lässt sich mit dem Konfigurations-Parameter »basedn_filter« in der Sektion »[ldap]« der Zugriff einschränken. Abbildung 3 zeigt die Verwaltungsseite für Rechte und Gruppen.
Abbildung 3: Darstellung der Berechtigungen und Gruppen in Trac.
Ab sofort lassen sich nun Berechtigungen über die Verwaltungsseite mit Hilfe von »trac-admin« oder direkt im LDAP anpassen und hinzufügen. Die einzelnen Rechte werden dabei – mit dem durch das neue Schema hinzugefügten Attribut und den neuen Objektklassen – direkt an die LDAP-Benutzer- und Gruppen-Objekte angehängt. Damit bei mehreren Trac-Instanzen keine Rechte-Überschneidungen entstehen, enthält jedes »tracperm« vor der eigentlichen Berechtigung noch den Trac-Projektnamen. Listing 5 zeigt als Beispiel den Eintrag des Administrators.
Listing 5
tracperm
01 uid=AdminGuy,ou=Users,dc=example,dc=org 02 uid: AdminGuy 03 sn: Guy 04 givenName: Admin 05 gecos: Admin 'AdminGuy' Guy 06 cn: Admin 'AdminGuy' Guy 07 objectClass: inetOrgPerson 08 objectClass: tracuser 09 tracperm: project-example:TRAC_ADMIN 10 mail: adminguy@example.org
Abschlussprüfung
In den hier aufgeführten Beispielen kommt Open LDAP zum Einsatz, einige Schritte können bei anderen LDAP-Servern anders ablaufen oder funktionieren für das Trac-Beispiel nicht. Die beiden Schemata »cosine« und »nis« sind zwingende Voraussetzungen für das Trac-Schema, ohne sie gibt es Fehlermeldungen, beispielsweise »olcObjectClasses: AttributeType not found: “gecos”« . LDAP-Filter und Bind-Optionen sollten Admins immer zweimal kontrollieren und durchdenken. Die Gefahr, ungewollt Rechte für Benutzer freizuschalten, sollte niemand unterschätzen. (uba)
LDAP und Datenbanken
Nur in seltenen Fällen wird es nötig sein, dass sich viele verschiedene Benutzer gegenüber einer Datenbank ausweisen, denn in der Regel authentifizieren sich die Benutzer gegenüber einer Applikation, die ihrerseits für alle ihre Datenbankoperationen einen speziellen Account verwendet. Möglich ist eine Authentifikation via LDAP aber dennoch.
MySQL
Ein MySQL-Admin kann LDAP nicht direkt als Authentifizierungsmethode angeben, stattdessen muss er das PAM-Authentication-Plugin verwenden, das allerdings nur ein Bestandteil der kommerziellen MySQL Enterprise Edition ist. Dagegen hat die kompatible Maria DB auch ein Open-Source-PAM-Modul.
Erstens muss der Admin in der zentralen Konfigurationsdatei »my.cnf« angeben, dass MySQL das Modul laden soll:
[mysqld] plugin-load=auth_pam.so
Zweitens muss er das Plugin auf LDAP einstellen, das geschieht in der Datei »/etc/pam.d/mysql« :
#%PAM-1.0 auth required pam_ldap.so account required pam_ldap.so
Drittens muss er den URI des LDAP-Servers in einer Datei »/etc/ldap_mysql.conf« hinterlegen:
uri ldaps:ldap.xxx ldaps:ldap2.xxx ssl on scope sub
Viertens ist beim Anlegen der Benutzer vorzugeben, dass diese das PAM-Modul für die Authentifizierung verwenden sollen:
CREATE USER 'antonio'@'localhost' IDENTIFIED WITH authentication_pam [...]
Die Einrichtung bei MySQL und Maria DB ist damit etwas komplexer und wohl auch anfälliger als die Konfiguration bei PostgreSQL.
PostgreSQL
In der maßgeblichen Konfigurationsdatei »pg_ hba.conf« gibt es eine Tabelle, die regelt, wie sich die Benutzer auszuweisen haben. Für lokale und entfernte Verbindungen kann man für alle oder einzelne Benutzer und Datenbanken angeben, welche Methode sie für die Authentifizierung verwenden sollen.
Steht in der Spalte »METHOD« beispielsweise der Ausdruck »trust« , wird der Benutzer ohne Passwort durchgewinkt, steht dort »reject« wird er immer abgewiesen, bei »peer« wird der gleichnamige Betriebssystem-Account verwendet, steht dort »ident« , braucht es einen Ident-Server und so weiter.
Genau an dieser Stelle darf nun auch »ldap« stehen. Dahinter sind als Parameter lediglich noch der LDAP-Server anzugeben sowie die Namensbestandteile, die voranzustellen oder anzuhängen sind, um aus dem Benutzernamen den LDAP-typischen Distinguished Name zu bilden, nach dem sich der Baum durchsuchen lässt. Das könnte so aussehen:
host all all 172.20.0.0/16 ldap ldapserver=ldap.example.net ldapprefix= "cn=" ldapsuffix=", dc=example, dc=net"
Infos
- Apache-Module Mod_authnz_ldap:http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html
- Trac: https://www.linux-magazin.de/Ausgaben/2006/04/Guter-Teamgeist/
- LDAP-Gruppenberechtigungen für Trac: https://trac-hacks.org/wiki/LdapPlugin
- »LdapAuthStore« : https://trac-hacks.org/wiki/LdapAuthStorePlugin
- Accountmanager-Plugin für Trac: https://trac-hacks.org/wiki/AccountManagerPlugin
- Pip: https://pip.pypa.io/en/stable/quickstart.html
- Trackhack.org: https://trac-hacks.org/wiki/LdapAuthStorePlugin#Configuration
