mod_auth_ldap Erlaubt die Speicherung der Datenbank für die HTTP Basic-Authentifizierung in einem LDAP-Verzeichnis. Experimentell mod_auth_ldap.c auth_ldap_module Verfügbar ab Version 2.0.41

mod_auth_ldap bietet folgende Eigenschaften:

 mod_ldap
Inhalte
Ablauf

Der Benutzerzugriff wird in zwei Phasen gewährt. Die erste Phase ist die Authentifizierung, in der mod_auth_ldap die Gültigkeit der Benutzerangaben prüft. Sie kann auch als Such- oder Binde-Phase bezeichnet werden. Die zweite Phase ist die Autorisierung, in der mod_auth_ldap feststellt, ob der zu authentifizierende Benutzer Zugriff auf die fragliche Ressource hat. Sie kann auch als Vergleichsphase bezeichnet werden.

Die Authentifizierungsphase

Während der Authentifizierungsphase sucht das Modul mod_auth_ldap nach einem Eintrag im Verzeichnis, der mit dem vom HTTP-Client übermittelten Benutzernamen übereinstimmt. Wird eine eindeutige Übereinstimmung gefunden, versucht das Modul, mit dem DN (Distinguished Name) und dem Passwort des HTTP-Client eine Bindung an den Verzeichnisserver herzustellen. Weil zuerst gesucht und dann eine Bindung hergestellt wird, kann auch von der Such- und Bindephase gesprochen werden. In der Bindephase werden folgende Schritte durchgeführt:

  1. Durch Kombination der Attribute und Filter der AuthLDAPURL-Direktive mit dem vom HTTP-Client übergebenen Benutzernamen wird ein Suchfilter erzeugt.
  2. Mit dem erzeugten Filter wird im Verzeichnis gesucht. Liefert die Suche keinen übereinstimmenden Eintrag, wird der Zugriff verweigert oder abgelehnt.
  3. Mit dem DN des Suchergebnisses und dem vom HTTP-Client übergebenen DN sowie dem Passwort wird versucht, eine Bindung zum LDAP-Server herzustellen. Kommt die Bindung nicht zustande, wird der Zugriff verweigert oder abgelehnt.

Die folgenden Direktiven werden in dieser Phase benutzt:

AuthLDAPURL Gibt den LDAP-Server, den Ausgangs-DN, das Attribut für die Suche sowie weitere Filter an.
AuthLDAPBindDN Ein optionaler DN für die Bindung während der Suchphase.
AuthLDAPBindPassword Ein optionales Passwort für die Bindung während der Suchphase.
Die Autorisierungsphase

Während der Autorisierungsphase versucht das Modul mod_auth_ldap festzustellen, ob der Benutzer berechtigt ist, auf die Ressource zuzugreifen. Bei vielen dieser Überprüfungen muss das mod_auth_ldap-Modul eine Vergleichsoperation auf dem LDAP-Server durchführen. Deshalb wird diese Phase auch Vergleichsphase bezeichnet. mod_auth_ldap akzeptiert folgende Require-Anweisungen, um festzustellen, ob die Benutzerangaben korrekt sind:

  • Bei einer require valid-user-Anweisung wird Zugriff gewährt.
  • Bei einer require user-Anweisung und Übereinstimmung des Benutzernames aus der Anweisung mit dem vom Client übergebenen Benutzernamen wird Zugriff gewährt.
  • Bei einer require dn-Anweisung und Übereinstimmung des DN aus der Anweisung mit dem DN aus dem LDAP-Verzeichnis wird Zugriff gewährt.
  • Bei einer require group-Anweisung und Vorhandensein des aus dem LDAP-Verzeichnis entnommen DN (oder des vom Client übergebenen Benutzernamens) in der LDAP-Gruppe wird Zugriff gewährt.
  • Andernfalls wird der Zugriff abgelehnt oder verweigert.

In der Vergleichsphase benutzt mod_auth_ldap folgende Anweisungen:

AuthLDAPURL Das in der URL angegebene Attribut wird für Vergleichsoperationen der require user-Operation benutzt.
AuthLDAPCompareDNOnServer Legt das Verhalten der require dn-Direktive fest.
AuthLDAPGroupAttribute Legt das Attribut für Vergleiche der require group-Direktive fest.
AuthLDAPGroupAttributeIsDN Gibt an, ob der Benutzer-DN oder der Benutzername bei Vergleichen für die require group-Anweisung benutzt werden soll.
Die require-Direktiven

Mit den Require-Direktiven wird während der Autorisierungsphase sichergestellt, dass der Benutzer auf eine Ressource zugreifen darf.

require valid-user

Ist die Anweisung vorhanden, gewährt mod_auth_ldap jedem Benutzer Zugriff, der sich in der Bindungsphase erfolgreich authentifiziert hat.

require user

Die require user-Direktive gibt an, welche Benutzernamen auf die Ressource zurgreifen können. Hat mod_auth_ldap einen eindeutigen DN im Verzeichnis gefunden, wird eine LDAP-Vergleichsoperation mit dem von require user angegebenen Benutzernamen durchgeführt, um festzustellen, ob dieser Benutzername Teil des gerade ermittelten LDAP-Eintrags ist. Werden mehrere Benutzernamen getrennt durch Leerzeichen angegeben, kann mehreren Benutzern der Zugriff gewährt werden. Enthält ein Benutzername ein Leerzeichen, dann muss dieser in doppelte Anführungszeichen gesetzt werden. Mehreren Benutzern kann auch Zugriff gewährt werden, wenn mehrere require user-Anweisungen mit einem Benutzer pro Zeile kodiert werden. Mit der AuthLDAPURL-Anweisung für ldap://ldap/o=Airius?cn (d.h., cn wird für die Suche benutzt) können beispielsweise folgende require-Direktiven den Zugriff regeln:

require user "Barbara Jenson"
require user "Fred User"
require user "Joe Manager"

Aufgrund der Art und Weise, in der mod_auth_ldap diese Direktive behandelt, kann Barbara Jenson sich als Barbara Jenson, Babs Jenson oder mit jedem anderen cn aus ihrem LDAP-Eintrag anmelden. Nur diese einzige require user-Zeile ist erforderlich, um alle Werte des Attributs aus dem Benutzereintrag zu ermöglichen.

Würde das Attribut uid an Stelle des Attributs cn in dieser URL verwendet, würden sich die drei oben aufgeführten Zeilen auf

require user bjenson fuser jmanager reduzieren.
require group

Diese Direktive gibt eine LDAP-Gruppe an, deren Mitglieder Zugriff haben. Sie benutzt den DN der LDAP-Gruppe. Angenommen, das LDAP-Verzeichnis enthält folgenden Eintrag:

dn: cn=Administrators, o=Airius
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius

Mit der folgenden Direktive erhalten dann sowohl Fred als auch Barbara Zugriff:

require group "cn=Administrators, o=Airius"

Das Verhalten dieser Direktive kann mit den Direktiven AuthLDAPGroupAttribute und AuthLDAPGroupAttributeIsDN modifiziert werden.

require dn

Mit der require dn-Direktive kann der Administrator Zugriff über die Distinguished Names gewähren. Sie gibt einen DN an, der übereinstimmen muss, damit Zugriff gewährt wird. Stimmt der im Verzeichnisserver gefundene DN mit dem DN in require dn überein, wird der Zugriff gewährt.

Mit der folgenden Anweisung wird einem bestimmten DN Zugriff gewährt:

require dn "cn=Barbara Jenson, o=Airius"

Das Verhalten dieser Direktive wird von der Direktive AuthLDAPCompareDNOnServer modifiziert.

Beispiele
TLS

Mehr zur Verwendung des Protokolls TLS finden Sie unter den mod_ldap-Direktiven LDAPTrustedCA und LDAPTrustedCAType.

SSL

Mehr zur Verwendung des Protokolls SSL finden Sie unter den mod_ldap-Direktiven LDAPTrustedCA und LDAPTrustedCAType.

Ein sicherer LDAP-Server wird in der AuthLDAPURL -Direktive mit ldaps:// und nicht mit ldap:// angegeben.

Microsoft und mod_auth_ldap

Normalerweise verwendet FrontPage (bzw. das mod_auth-Modul) eigene Benutzer- und Gruppendateien für die Authentifizierung. Es reicht leider nicht aus, die korrekten Direktiven hinzuzufügen, um zur LDAP-Authentifizierung zu wechseln, weil das gegen die Permissions-Formulare des FrontPage-Client verstößt, der versucht, die Textdateien für die Authentifizierung zu modifizieren.

Wurde ein FrontPage-Server eingerichtet, kann die LDAP-Authentifizierung nach Einfügen der folgenden Direktiven in alle .htaccess-Dateien verwendet werden:

AuthLDAPURL            "die URL"
AuthLDAPAuthoritative  off
AuthLDAPFrontPageHack  on

AuthLDAPAuthoritative muss auf off gesetzt werden, damit mod_auth_ldap die Gruppenauthentifizierung ablehnt und der Apache auf die Dateiauthentifizierung zur Überprüfung der Gruppenmitgliedschaft zurückfällt. Auf diese Weise können von FrontPage verwaltete Gruppendateien benutzt werden.

Funktionsweise

FrontPage kontrolliert den Web-Zugriff über die zusätzliche require valid-user-Direktive in den .htaccess-Dateien. Wird AuthLDAPFrontPageHack nicht aktiviert, ist die require valid-user-Direktive für jeden Benutzer erfolgreich, der gemäß LDAP zulässig ist. Daraus folgt, dass jeder, der einen Eintrag im LDAP-Verzeichnis besitzt, als zulässiger Benutzer gilt, während FrontPage davon ausgeht, dass nur Benutzer aus der lokalen Benutzerdatei zulässig sind. Der Hack soll den Apache zwingen, die lokale Benutzerdatei (die von FrontPage verwaltet wird) und nicht LDAP zu Rate zu ziehen, wenn die require valid-user-Anweisung ausgeführt wird.

Wurden die Direktiven wie oben beschrieben hinzugefügt, sind FrontPage-Benutzer in der Lage, alle Management-Operationen für den FrontPage-Client durchzuführen.

Einschränkungen
  • Wird die LDAP URL gewählt, dann sollte sich das Attribut für die Authentifizierung auch für eine mod_auth-Benutzerdatei eignen, was beispielsweise für die UID gilt.
  • Werden Benutzer über FrontPage hinzugefügt, sollten die FrontPage-Administratoren aus nahe liegenden Gründe Benutzernamen wählen, die bereits im LDAP-Verzeichnis vorhanden sind. Das vom Adminstrator in das Formular eingegebene Passwort wird ignoriert, da der Apache die Authentifizierung mit dem Passwort aus der LDAP-Datenbank und nicht mit dem Passwort aus der lokalen Benutzerdatei durchführt. Dies kann zu Irritationen beim Web-Administrator führen.
  • Der Apache muss mit dem mod_auth-Modul kompiliert werden, damit FrontPage unterstützt wird. Ursache hierfür ist die Tatsache, dass der Apache weiterhin die mod_auth-Gruppendatei für die Ermittlung der Zugangsberechtigung eines Benutzers für die FrontPage-Website benutzt.
  • Die Direktiven müssen in die .htaccess-Dateien eingefügt werden. Der Versuch, sie in die Direktiven Location oder Directory aufzunehmen, schlägt fehl, weil das Modul mod_auth_ldap auf die AuthUserFile-Anweisung in den .htaccess-Dateien von FrontPage zugreifen muss, um die Liste der gültigen Benutzer finden zu können. Befinden sich die mod_auth_ldap-Anweisungen nicht in der gleichen .htaccess-Datei wie die FrontPage-Direktiven, funktioniert der Hack nicht, weil mod_auth_ldap keine Möglichkeit hat, die .htaccess-Datei zu verarbeiten und die von FrontPage verwaltete Benutzerdatei nicht finden kann.
AuthLDAPAuthoritative Anderen Authentifizierungsmodulen die Benutzerüberprüfung verbieten, wenn diese Direktive fehlschlägt. AuthLDAPAuthoritative on|off AuthLDAPAuthoritative on directory.htaccess AuthConfig

Wird der Wert off gesetzt, können andere Authentifizierungsmodule eine Benutzerauthentifizierung durchführen, falls dieses Modul fehlschlägt. Dies ist nur möglich, wenn kein DN oder keine Regel mit dem vom Client übergebenen Benutzernamen übereinstimmt.

 AuthLDAPBindDN Optionaler DN für die Bindung an den LDAP-Server AuthLDAPBindDN Distinguished-Name directory.htaccess AuthConfig

Ein optionaler DN der bei der Suche nach Einträgen die Bindung an den Server herstellt. Wird er nicht angegeben,verwendet mod_auth_ldap eine anonyme Bindung.

 AuthLDAPBindPassword Ein Passwort, das für den bindenden DN benutzt wird. AuthLDAPBindPassword Passwort directory.htaccess AuthConfig

Das Passwort, das für den bindenden DN benutzt wird. Da es sich bei diesem Passwort um vertrauliche Daten handeln kann, sollte es gut geschützt sein. Die Direktiven AuthLDAPBindDN und AuthLDAPBindPassword sollten nur verwendet werden, wenn sie für die Suche im Verzeichnis unbedingt erforderlich sind.

 AuthLDAPCharsetConfig Datei mit Zuweisungen von Zeichensätzen zu Sprachcodes AuthLDAPCharsetConfig Dateipfad server config

Die AuthLDAPCharsetConfig-Direktive gibt den Standort der Datei mit den Zuweisungen von Zeichensätzen zu Sprachcodes an. Der Dateipfad wird relativ zu ServerRoot angegeben. Diese Datei enthält eine Liste mit Zeichensatzdefinitionen. Meist reicht die mitgelieferte Datei charset.conv mit den üblichen Zuordnungen für Zeichensätze zu Sprachcodes aus.

Diese Datei enthält Zeilen im Format:

Sprachcode Zeichensatz [Sprache] ...

Beim Sprachcode werden Groß- und Kleinbuchstaben nicht unterschieden. Leere Zeilen sowie Zeilen, die mit einem Hash (#) beginnen, werden ignoriert.

 AuthLDAPCompareDNOnServer Vergleiche zwischen DNs erfolgen auf dem LDAP-Server. AuthLDAPCompareDNOnServer on|off AuthLDAPCompareDNOnServer on directory.htaccess AuthConfig

Wird dieses Attribut auf on gesetzt, benutzt das mod_auth_ldap-Modul den LDAP-Server für Vergleiche zwischen DNs. Dies ist die einzige sichere Vergleichsmethode. Das Modul sucht in dem mit der Direktive require dn angegebenen Verzeichnis nach dem DN und vergleicht diesen mit dem DN aus dem Benutzereintrag. Wird die Voreinstellung zurückgesetzt, führt das Modul mod_auth_ldap einen einfachen String-Vergleich durch. Dieses Verfahren kann zu falschen Ergebnissen führen, es ist aber wesentlich schneller. Der mod_ldap-Cache kann den DN-Vergleich in den meisten Situationen beschleunigen.

 AuthLDAPDereferenceAliases Zeitpunkt der Dereferenzierung von Aliasen AuthLDAPDereferenceAliases never|searching|finding|always AuthLDAPDereferenceAliases Always directory.htaccess AuthConfig

Über diese Direktive wird definiert, wann das Modul mod_auth_ldap bei der Bearbeitung von LDAP-Operationen Aliase dereferenziert. Bei der Voreinstellunng always geschieht dies immer umgehend.

 AuthLDAPEnabled Deaktivierung der LDAP-Authentifizierung in einem Unterverzeichnis AuthLDAPEnabled on|off AuthLDAPEnabled on directory.htaccess AuthConfig

Wird diese Direktive auf off gesetzt, ist das Modul mod_auth_ldap in bestimmten Verzeichnis deaktiviert. Das kann sinnvoll sein, wenn mod_auth_ldap im oberen Bereich des Verzeichnisbaumes aktiviert ist, aber für bestimmte Bereiche vollständig deaktiviert werden soll.

 AuthLDAPFrontPageHack LDAP-Authentifizierung in Verbindung mit MS FrontPage AuthLDAPFrontPageHack on|off AuthLDAPFrontPageHack off directory.htaccess AuthConfig

Weitere Informationen finden Sie unter Microsoft FrontPage und mod_auth_ldap.

 AuthLDAPGroupAttribute LDAP-Attribute zur Überprüfung der Gruppenmitgliedschaft AuthLDAPGroupAttribute Attribut directory.htaccess AuthConfig

Diese Anweisung gibt an, welche LDAP-Attribute für die Überprüfung der Gruppenmitgliedschaft benutzt werden. Mit mehreren Anweisungen kann das Attribut mehrfach gesetzt werden. Wird es nicht angegeben, verwendet das Modul mod_auth_ldap die Attribute member und uniquemember.

 AuthLDAPGroupAttributeIsDN Verwendung des Client-DN für die Überprüfung der Gruppenmitgliedschaft AuthLDAPGroupAttributeIsDN on|off AuthLDAPGroupAttributeIsDN on directory.htaccess AuthConfig

Wenn on gesetzt wird, verlangt diese Direktive die Verwendung des DN des Client-Benutzernamens für die Überprüfung der Gruppenmitgliedschaft. Andernfalls wird der Benutzername benutzt. Hat der Client beispielsweise den Benutzernamen bjenson gesendet, der dem LDAP-DN cn=Babs Jenson, o=Airius entspricht, dann überprüft das Modul mod_auth_ldap, ob cn=Babs Jenson, o=Airius Gruppenmitglied ist. Wird diese Direktive nicht angegeben, überprüft das Modul mod_auth_ldap, ob bjenson Gruppenmitglied ist.

 AuthLDAPRemoteUserIsDN Die Umgebungsvariable REMOTE_USER erhält den DN des Client-Benutzernamens als Wert. AuthLDAPRemoteUserIsDN on|off AuthLDAPRemoteUserIsDN off directory.htaccess AuthConfig

Wird diese Direktive auf on gesetzt, entspricht die Umgebungsvariable REMOTE_USER dem vollständigen DN des authentifizierten Benutzers und nicht nur dem vom Client übergebenen Benutzernamen. Standardmäßig ist off vorgegeben.

 AuthLDAPUrl Die URL mit den LDAP-Suchparametern AuthLDAPUrl url directory.htaccess AuthConfig

Eine URL nach RFC 2255, die die LDAP-Suchparameter angibt. Die Syntax lautet:

ldap://Host:Port/BasisDN?Attribut?Bereich?Filter
ldap
Für reguläres LDAP wird die Zeichenfolge ldap angegeben, für gesichertes LDAP ldaps. Gesichertes LDAP steht nur zur Verfügung, wenn der Apache mit einer LDAP-Bibliothek mit SSL-Unterstützung gebunden wurde.
Host:Port

Name/Port des LDAP-Servers (Voreinstellung: localhost:389 für ldap und localhost:636 für ldaps). Um mehrere redundante LDAP-Server anzugeben, werden alle Server getrennt durch Leerzeichen angegeben. Das Modul mod_auth_ldap versucht der Reihe nach eine Verbindung zu jedem Server herzustellen, bis eine Verbindung zustandekommt.

Konnte eine Serververbindung eingerichtet werden, bleibt diese für die Lebensdauer des httpd-Prozesses oder so lange gültig, bis der LDAP-Server heruntergefahren wird.

Wird der LDAP-Server heruntergefahren oder eine bestehende Verbindung unterbrochen, versucht das Modul mod_auth_ldap die Verbindung wiederherzustellen, wofür der primäre Server gestartet und ein Verbindungsaufbau zu jedem redundanten Server versucht wird, was sich von einem echten Rundruf unterscheidet.

BasisDN
Der DN des Verzeichniszweiges, in welchem alle Suchen beginnen sollen. Im äußersten Fall muss dies die Spitze des Verzeichnisbaumes sein, es kann aber auch ein Unterzweig angegeben werden.
Attribut
Das zu suchende Attribut. Das RFC 2255 erlaubt zwar eine durch Komata getrennte Attributliste, es wird aber nur das erste Attribut benutzt, unabhängig davon, wie viele angegeben werden. Werden keine Attribute angegeben, wird standardmäßig uid verwendet. Es ist sinnvoll, ein Attribut zu wählen, das für alle Einträge im Unterzweig eindeutig ist.
Bereich
Der Suchbereich. Angegeben werden kann one oder sub. Gemäß RFC 2255 wird zwar auch der Bereich base unterstützt, was jedoch nicht für dieses Modul gilt. Wird kein Bereich oder der Bereich base angegeben, gilt die Voreinstellung sub.
Filter
Ein zulässiger LDAP-Suchfilter. Ohne Angabe gilt die Voreinstellung (objectClass=*), bei der nach allen Objekten gesucht wird. Die Länge der gesamten Filterangabe darf 8192 Zeichen nicht überschreiten (gemäß der MAX_STRING_LEN-Definition im Apache-Quellcode), was generell ausreichen sollte.

Bei der Durchführung von Suchanfragen werden das Suchattribut, die Filterangabe und der vom HTTP-Client übermittelte Benutzername kombiniert und ein Suchfilter der folgenden Form erzeugt: (&(Filter)(Attribut=Benutzername)).

Versucht bespielsweise ein Client für die URL ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*) eine Verbindung mit dem Benutzernamen Babs Jenson herzustellen, dann ergibt sich folgende Filterangabe: (&(posixid=*)(cn=Babs Jenson)).

Beispiele zu AuthLDAPURL-URLs finden Sie weiter oben.