Zum Inhalt springen

Apache/09 Zugriff/LDAP-Authentifizierung

Aus Foxwiki

9.5 LDAP-Authentifizierung

Alle bisher gezeigten Authentifizierungsmethoden haben einen gemeinsamen Nachteil: Sie müssen völlig neue Benutzer- und Gruppendefinitionen erzeugen, um sie zu nutzen. In vielen Unternehmen mit Netzwerken existiert aber bereits eine Infrastruktur mit solchen Definitionen, und es ist aufwendig und fehlerträchtig, diese noch einmal für den Website-Zugriff nachzuahmen.

Heutzutage verwenden immer mehr Firmen eine Lösung für ihre unternehmensweite Authentifizierungsverwaltung, die man als Verzeichnisdienst bezeichnet. Dabei handelt es sich um einen Server-Dienst, der die Daten sämtlicher Netzwerke, Rechner, Benutzer und Gruppen des Unternehmens speichert und bei jeder Netzwerkanmeldung überprüft, ob die aktuelle Rechner-Benutzer-Kombination die erforderliche Berechtigung besitzt. Ein Verzeichnisdienst ist praktisch, weil er einmal zentral eingerichtet wird und mehr Leistungsfähigkeit und Sicherheit bietet als ein Gestrüpp aus lokalen Berechtigungen für einzelne Rechner.

Konkrete Verzeichnisdienste gibt es wie Sand am Meer: NIS beziehungsweise NIS(+) von Sun (früher yp oder Yellow Pages genannt), Novell Directory Services (NDS) beziehungsweise eDirectory, OpenLDAP und Microsoft Active Directory sind nur einige von ihnen. Bis auf die Sun-Eigenentwicklung NIS(+) basieren all diese Verzeichnisdienste auf einer abgespeckten, aber TCP/IP-fähigen Variante der X.500-Spezifikation, auf die mithilfe von LDAP (Lightweight Directory Access Protocol) zugegriffen werden kann. Genau hier kommt mod_authnz_ldap ins Spiel: Es überlässt die Überprüfung der Anmeldedaten einem separaten LDAPfähigen Verzeichnisdienstserver. Geschrieben wurde das Modul für die Zusammenarbeit mit OpenLDAP, es arbeitet aber im Grunde mit jedem LDAP-standardkonformen Server zusammen.

9.5.1 LDAP-Grundwissen

LDAP-Verzeichnisse speichern die Daten in einer DNS-ähnlichen, hierarchischen Baumstruktur, die als DIT (Directory Information Tree) bezeichnet wird. Die Speicherung selbst erfolgt binär, aber für den Datenaustausch mit Benutzern oder Programmen unterstützen LDAP-Server ein textbasiertes Format namens LDIF

LDAP-Authentifizierung 9.5

(LDAP Interchange Format). LDIF-Einträge haben stets die Struktur Name=Wert; hinzu kommen fast immer Unterobjekte im selben Format sowie Attribute in der Schreibweise Attributname: Wert.

Die Namen der LDAP-Objekte und -Attribute bilden das standardisierte LDAPSchema. Einträge in diesem Schema besitzen einen Namen und eine eindeutige Nummer; auch die erlaubten Arten der Verschachtelung sind im Schema festgelegt. Auf Ihren eigenen LDAP-Servern können Sie das Schema bei Bedarf erweitern.

Die Wurzel des LDAP-Baums bilden dc-Einträge; dc steht für Domain Component. Diese Einträge stellen die einzelnen Bestandteile des Domain-Namens dar, die normalerweise durch Punkte voneinander getrennt werden. So wäre die Wurzel eines LDAP-Verzeichnisses für die Domain mynet.de beispielsweise dc=mynet, dc=de. Alle dc-Einträge zusammen bilden den DN (Distinguished Name) des Wurzelknotens.

Die erste Unterteilungsstufe unterhalb der Wurzel sind die Organisationseinheiten (LDAP-Name ou für Organizational Units). Bekannte Organisationseinheiten sind etwa ou=devices für Computer und andere Netzwerkgeräte oder ou=people für Personen, insbesondere Benutzer des Netzwerks. Organisationseinheiten können beliebig weiter unterteilt werden. Unterhalb von ou=devices könnte es beispielsweise ou=computers und ou=printers geben; ou=people könnte dagegen zum Beispiel in die Unterorganisationseinheiten ou=sales, ou=marketing und ou=accounting für die entsprechenden Abteilungen unterteilt werden.

Benutzer werden durch cn-Knoten gekennzeichnet; cn steht für Common Name. Der Inhalt des Knotens sind meist Vor- und Nachname der Person, aber im Bedarfsfall (etwa bei Namensgleichheit oder verschiedenen Standorten) können weitere Unterscheidungsmerkmale hinzukommen. Der DN eines Benutzers in der Abteilung Entwicklung (developers) unter der Organisationseinheit people im LDAP-Verzeichnis der Domain mynet.de könnte beispielsweise so aussehen:

cn=Sascha Kersken,ou=developers,ou=people,dc=mynet,dc=de

Im klassischen LDAP-Schema gehören Personendaten zur Objektklasse person. Eine Objektklasse legt die zulässigen und/oder erforderlichen Attribute für jeden LDAP-Eintrag fest. In modernen Netzwerken ist die von person abgeleitete Objektklasse inetOrgPerson besser geeignet, da sie beispielsweise ein Standardattribut für die E-Mail-Adresse enthält.

LDAP-Verzeichnisse werden sehr häufig zur netzwerkweiten Verwaltung von Benutzerkonten und -logins eingesetzt. Auch für diesen Zweck gibt es unterschiedliche Objektklassen. In UNIX-Netzwerken kommt beispielsweise die Objektklasse posixAccount zum Einsatz, deren Attribute alle Einträge von /etc/

passwd abbilden; entsprechend gibt es noch die Klasse shadowAccount für die /etc/shadow-Felder. Für Logins von Windows-Rechnern aus gibt es schließlich die Objektklasse sambaAccount.

Zur Verwaltung von User-Logins im Netzwerk oder auch in einem geschützten Apache-Verzeichnis liegt es nahe, im DN der Userknoten uid (den Benutzernamen) anstelle von cn zu verwenden. Beispiel:

uid=sascha,ou=developers,ou=people,dc=mynet,dc=de

Jeder Knoten in einem LDAP-Verzeichnisbaum kann übrigens beliebig vielen Objektklassen gleichzeitig anhören. Sie müssen dann allerdings darauf achten, dass die Pflichtattribute aller beteiligten Klassen verwendet werden - diese überschneiden sich mitunter, besonders dann, wenn die Klassen voneinander abgeleitet werden.

Hier sehen Sie ein komplettes Beispiel für einen Usereintrag; er gehört den drei Objektklassen person, inetOrgPerson und posixAccount an:

dn: uid=sascha,ou=developers,ou=people,dc=mynet,dc=de objectClass: person objectClass: inetOrgPerson objectClass: posixAccount cn: Sascha Kersken sn: Kersken givenName: Sascha l: Köln o: MyNet GmbH telephoneNumber: 0221-1234567 facsimileTelephoneNumber: 0221-1234568 mail: sk@lingoworld.de uid: sascha uidNumber: 1001 gidNumber: 100 userPassword: {MD5}WY1MIARhuBUiozKFZcJffA== homeDirectory: /home/sascha loginShell: /bin/bash

Hier die Bedeutung der einzelnen Attribute im Detail:

  • dn (distinguished name): der komplette Pfad des Eintrags im LDAP-Verzeichnisbaum
  • objectClass: Die Kategorie des Eintrags, die festlegt, welche Felder vorgeschrieben beziehungsweise zulässig sind; der Beispieleintrag gehört wie

bereits erwähnt zu drei verschiedenen Klassen.

LDAP-Authentifizierung 9.5

  • cn (common name): Der eindeutige Eigenname des Knotens; bei Personen

werden meist Vor- und Nachname verwendet.

  • sn (surname): Nachname
  • givenName: Vorname
  • l (location): Wohnort
  • o (organization): Firmen- beziehungsweise Institutionsname
  • telephoneNumber: Telefonnummer der Person
  • facsimileTelephoneNumber: Faxnummer der Person
  • mail: E-Mail-Adresse
  • uid: User-ID für die Benutzeranmeldung
  • uidNumber: die numerische User-ID
  • gidNumber: numerische ID der primären Gruppe dieses Benutzers
  • userPassword: Zunächst steht in geschweiften Klammern der verwendete Verschlüsselungsalgorithmus, dahinter das entsprechend verschlüsselte Passwort

selbst.

  • homeDirectory: das Home-Verzeichnis des Users
  • loginShell: die Shell, die dem Benutzer nach der Anmeldung zur Verfügung

steht

Jeder Knoten kann beliebig viele untergeordnete Knoten enthalten. Der DN wird dazu um den cn (oder ein anderes eindeutiges Merkmal) des übergeordneten Objekts ergänzt. Wenn Sie den inetOrgPerson-Eintrag beispielsweise lieber als Unterknoten des User-Accounts speichern möchten, dann lautet dessen DN wie folgt:

dn: cn=Sascha Kersken,uid=sascha,ou=people,dc=mynet,dc=de

9.5.2 OpenLDAP einrichten und verwalten

Die meisten Linux- und UNIX-Versionen enthalten den OpenLDAP-Server bereits ab Werk, zumindest als optionales Paket. Falls er bei Ihnen nicht vorhanden ist, müssen Sie ihn von https://www.openldap.org herunterladen und selbst kompilieren. Für Windows-Systeme ist mittlerweile ein binärer Installer verfügbar. Es handelt sich hierbei zwar um die nicht mehr aktuelle Version 2.2, und der Installer ist als experimentell gekennzeichnet - in meinen Praxistests für dieses Buch und für das IT-Handbuch für Fachinformatiker (Galileo Press, Bonn 2011) machte er jedoch einen recht stabilen Eindruck. Sie können diese Version unter https://download.bergmans.us/openldap/ herunterladen. Wenn Sie den Installer mit Standardeinstellungen ausführen, wird OpenLDAP automatisch als Dienst

eingerichtet. Nach der Installation sollten Sie das OpenLDAP-Verzeichnis zu Ihrem PATH hinzufügen, um von überall auf die LDAP-Kommandozeilen-Tools zugreifen zu können.

Der OpenLDAP-Server-Dienst heißt auf allen Systemen slapd. Seine Hauptkonfigurationsdatei slapd.conf befindet sich auf UNIX-Systemen im Verzeichnis /etc/ openldap; bei Windows liegt diese Datei im Verzeichnis der OpenLDAP-Installation selbst.

Um den Zugriff auf den LDAP-Server zu ermöglichen, müssen Sie die beiden Einträge suffix (die Wurzel des LDAP-Baums) und rootdn (DN des VerwaltungsUsers) anpassen. Üblicherweise erhält der rootdn den Common Name Manager oder ldapadmin; darauf folgen dieselben Domain-Komponenten wie beim suffix. Beispiel:

suffix "dc=mynet,dc=de" rootdn "cn=Manager,dc=mynet,dc=de"

Außerdem muss ein Passwort für den rootdn angegeben werden. Im Auslieferungszustand von OpenLDAP lautet die Zeile:

rootpw secret

Selbstverständlich sollten Sie secret durch ein anderes Passwort ersetzen; für den Produktiveinsatz ist zudem dringend zu empfehlen, das Passwort zu verschlüsseln. Dazu wird der Name des Verschlüsselungsalgorithmus in geschweiften Klammern angegeben, dahinter das Base64-codierte Passwort in der entsprechenden Verschlüsselung. Hier ein Beispiel für das MD5-verschlüsselte Passwort geheim (in der Praxis natürlich ebenso indiskutabel wie secret):

rootpw {MD5}6GNuoBPmgvr2H1bOHLGrXA==

Um solche Passwörter zu erzeugen, können Sie das Konsolen-Tool slappasswd verwenden. Standardmäßig verschlüsselt es Passwörter mit dem Algorithmus, der in der slapd.conf-Direktive password-hash angegeben wird. Alternativ können Sie die Option -h verwenden, gefolgt vom gewünschten Algorithmus in geschweiften Klammern. Nach dem Aufruf müssen Sie zweimal das zu verschlüsselnde Passwort eingeben und erhalten als Ausgabe die {Algorithmus}PasswortKombination, die Sie dann in die Datei slapd.conf einfügen können. Beispiele:

> slappasswd New password: Re-enter new password: {SSHA}0/6NOGhwu2Lk2sl/63wNnIpH7mbmhk9Q > slappasswd -h {MD5} New password:

LDAP-Authentifizierung 9.5

Re-enter new password: {MD5}6GNuoBPmgvr2H1bOHLGrXA==

Gegebenenfalls müssen Sie mithilfe von include-Direktiven zusätzliche SchemaDateien einbinden, beispielsweise nis.schema für die Objektklasse posixAccount.

Nach Änderungen der Konfigurationsdatei müssen Sie den OpenLDAP-Server mit der zu Ihrem Betriebssystem passenden Methode neu starten. OpenLDAPVersionen ab 2.3 werten allerdings auch die Konfigurationsdateien im Verzeichnis /etc/openldap/slapd.d zur Laufzeit aus, was Konfigurationsänderungen ohne Neustart ermöglicht.

Sobald der Server läuft, können Sie Verzeichniseinträge erzeugen und ihn anderweitig nutzen. Am einfachsten ist es, die gewünschten Einträge im LDIF-Format in Textdateien zu schreiben und dann mithilfe der OpenLDAP-KommandozeilenTools einzulesen. Das folgende Beispiel legt die LDAP-Wurzel für mynet.de, die Organisationseinheiten people und developers sowie den Beispiel-User-Account sascha an:

dn: dc=mynet,dc=de dc: mynet objectClass: dcObject objectClass: organizationalUnit ou: lingoworld.de

dn: ou=people,dc=mynet,dc=de ou: people objectClass: organizationalUnit dn: ou=developers,ou=people,dc=mynet,dc=de

ou: developers objectClass: organizationalUnit

dn: uid=sascha,ou=developers,ou=people,dc=mynet,dc=de objectClass: posixAccount objectClass: person uid: sascha cn: Sascha Kersken sn: Kersken uidNumber: 1001 gidNumber: 100 gecos: Sascha Kersken userPassword: {MD5}uRymnwhjHoXhkrCqRfpiUg== homeDirectory: /home/sascha loginShell: /bin/bash

Das noch nicht besprochene Attribut gecos steht für das gleichnamige /etc/ passwd-Feld mit dem ausführlichen Beschreibungstext (in der Regel wird dort der vollständige Name eingetragen).

Angenommen, die Datei heißt data.ldif. Dann können Sie Folgendes eingeben, um sie zu Ihrem LDAP-Verzeichnis hinzuzufügen:

  1. ldapadd -x -f data.ldif \

-D "cn=Manager,dc=mynet,dc=de" -W

Die Option -x steht für Klartext-Authentifizierung; Sie können sie weglassen, wenn Sie das rootdn-Passwort gemäß der obigen Empfehlung verschlüsselt haben. Mit -f Dateiname geben Sie die Datei an, aus der ldapadd lesen soll. -D gibt den rootdn an, und -W sorgt dafür, dass in der nächsten Zeile das Passwort angefordert wird.

Weitere interessante LDAP-Kommandozeilen-Tools, die Sie sich ansehen sollten, sind ldapmodify zur Änderung eines existierenden Eintrags (ldapadd ist in Wirklichkeit ein ldapmodify-Aufruf mit der Option -a für add) sowie ldapsearch, das im LDAP-Verzeichnis nach Einträgen sucht.

Geben Sie beispielsweise Folgendes ein, wenn Sie alle Einträge Ihres Verzeichnisses lesen möchten:

  1. ldapsearch -x -D "cn=Manager,dc=mynet,dc=de" \

-b "dc=mynet,dc=de" "(objectclass=*)" -W Enter LDAP Password:

  1. extended LDIF
  3. LDAPv3
  4. base <dc=mynet,dc=de> with scope sub
  5. filter: (objectClass=*)
  6. requesting: ALL
  1. mynet.de

dn: dc=mynet,dc=de dc: mynet objectClass: dcObject objectClass: organizationalUnit ou: mynet.de [...]

Die Optionen -x, -D und -W wurden bereits erläutert. Die Option -b gibt den DN der Basis an, unter der gesucht werden soll. "(objectclass=*)" ist ein LDAP-Filter. Da jeder LDAP-Eintrag ein objectClass-Attribut besitzen muss, trifft dieser

LDAP-Authentifizierung 9.5

Filter auf jeden Knoten des Verzeichnisses zu. Näheres über LDAP-Filter erfahren Sie weiter unten bei der Definition der mod_authnz_ldap-Direktiven.

Mehr Komfort als diese Konsolenkommandos bieten grafische LDAP-Clients. Einer der empfehlenswertesten ist phpLDAPadmin, der unter https://phpldapadmin.sourceforge.net zum Download bereitsteht. Er wird als PHP-Anwendung auf einem Webserver installiert. Nachdem PHP auf Ihrem Apache läuft (siehe dazu Kapitel 15, Technologien zur Webprogrammierung), müssen Sie das Paket in ein Verzeichnis außerhalb Ihrer DocumentRoot kopieren, das betreffende Verzeichnis mithilfe einer Alias-Direktive und eines Containers für die nötigen Rechte einbinden, die Konfigurationsdatei conf/config.php anpassen (beispielsweise die URL Ihres LDAP-Servers eintragen) und können dann die betreffende URL im Browser öffnen.

9.5.3 LDAP-Authentifizierungs-Direktiven

Nachdem Sie jetzt in Grundzügen erfahren haben, wie LDAP funktioniert und wie man einen OpenLDAP-Server einrichtet, kommen nun die verschiedenen Direktiven von mod_authnz_ldap zur Sprache, die verwendet werden, um das Verzeichnis als Provider für die Anmeldeverwaltung einzusetzen.

Require-Erweiterungen mod_authnz_ldap nimmt Ergänzungen an den zulässigen Angaben für die Core-Direktive Require vor: Neben Require user, Require group und Require valid-user können Sie mit Require angeben, dass die Anmeldedaten bestimmte LDAP-Kriterien erfüllen müssen:

  • Require ldap-user

Ein Benutzer mit einem angegebenen Benutzernamen erhält Zugriff auf den geschützten Bereich. Wenn ein Benutzername Leerzeichen enthält, muss er in Anführungszeichen stehen (das gilt auch für die Werte der meisten anderen Require ldap-*-Varianten). Welches LDAP-Attribut als Username betrachtet wird (beispielsweise cn oder uid), regelt die weiter unten besprochene Direktive AuthLDAPUrl. Beispiele: Require ldap-user peter Require ldap-user "Peter Schmitz"

  • Require ldap-group

Gewährt einer bestimmten Gruppe Zugriff auf die geschützte Ressource. Der DN der Gruppe darf dabei nicht in Anführungszeichen stehen. Beispiel: Require ldap-group cn=Users, o=MyNet

  • Require ldap-dn

Der Zugriff wird Benutzern mit einem bestimmten DN gewährt. Beispiel: Require ldap-dn \ "cn=Peter Schmitz,ou=Sales,o=MyNet"

  • Require ldap-attribute

Der Zugriff wird all denjenigen Usern gestattet, für die ein Attribut einen bestimmten Wert besitzt; wenn Sie mehrere Attribute angeben, werden diese mit einem Oder verknüpft, sodass jeweils eine Übereinstimmung genügt. Beispiel: Require ldap-attribute city=Köln ou=developers

  • Require ldap-filter

Diese Variante ermöglicht die Angabe eines komplexen Ausdrucks (Näheres siehe unter AuthLDAPUrl), mit dem die potenziellen Zugriffskandidaten verglichen werden. Das folgende Beispiel erlaubt allen Benutzern den Zugriff, bei denen das Attribut city den Wert Köln hat und die eine Telefaxnummer besitzen: Require ldap-filter \ &(city=Köln)(facsimileTelephoneNumber=*)

AuthLDAPUrl URL, die die LDAP-Suchparameter angibt

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPUrl URL [NONE|SSL|TLS|STARTTLS] Standardwert nicht gesetzt

Dies ist die wichtigste Direktive für die LDAP-Authentifizierung: Sie gibt die RFC2255-konforme URL des LDAP-Servers an, der befragt werden soll, und kann zahlreiche Präzisierungen bezüglich des Teilbaums enthalten, der durchsucht werden soll. Die grundlegende Syntax der URL sieht so aus:

ldap://Host:Port/Basis-DN?Attribut?Suchtiefe?Filter

Die einzelnen Bestandteile bedeuten Folgendes:

  • Schema: Das Schema ist entweder ldap (wie in der Übersicht) oder ldaps, falls

Sie über eine SSL-Verbindung auf LDAP zugreifen. Letzteres funktioniert nur, wenn Sie Apache beim Kompilieren gegen eine LDAP-Bibliothek gelinkt haben, die SSL unterstützt. Dies ist beispielsweise bei neueren OpenLDAP-Versionen der Fall.

  • Host:Port: Dieser URL-Bestandteil dürfte sich von selbst erklären: Es handelt

sich um den Hostnamen und die Portnummer des LDAP-Servers, der die Anmeldung bestätigen soll. Sie können die Angabe ganz weglassen, wenn der LDAP-Server auf localhost läuft. Falls Sie keinen Port angeben, wird die Standardeinstellung 389 für ldap beziehungsweise 636 für ldaps verwendet.

  • Sie können durch Leerzeichen getrennt mehrere Hosts angeben; mod_authnz_

ldap verwendet den ersten, zu dem erfolgreich eine Verbindung aufgebaut

LDAP-Authentifizierung 9.5

werden kann. Diese Verbindung bleibt bestehen, bis Apache oder der LDAPServer-Dienst beendet wird.

  • Basis-DN: Über diesen Parameter können Sie den DN (Distinguished Name)

der Wurzel des Bereichs angeben, in dem auf dem LDAP-Server nach der Anmeldebestätigung gesucht werden soll.

  • Attribut: Dies ist das Attribut, mit dem die Nutzerdaten auf dem LDAP-Server

verglichen werden sollen - es bildet auch den Benutzernamen für Require ldap-user. Der Standardwert ist uid; häufig wird auch cn angegeben.

  • Suchtiefe: Der Wert one beschränkt die Suche auf eine Ebene, während sub

auch in untergeordneten Bereichen sucht. Der dritte in RFC 2255 definierte Wert, base, wird von mod_authnz_ldap nicht unterstützt.

  • Filter: Dies ist ein LDAP-Suchfilter mit maximal 8.192 Zeichen1 Länge, der auf

den durchsuchten Bereich angewendet wird. Filter haben Formen wie Attribut=Wert oder auch Attribut=*, um zu verlangen, dass das entsprechende Attribut vorhanden ist (beispielsweise beschränkt facsimileTelephoneNumber=* die Suche auf User, die eine Faxnummer besitzen). Der Standardwert ist objectClass=* - es werden sämtliche Datensätze durchsucht.

Hier einige Beispiele:

  • AuthLDAPUrl "ldap://ldap.mynet.de/ou=Sales, o=MyNet?cn"

Diese LDAP-URL durchsucht den vom LDAP-Server ldap.mynet.de bereitgestellten Bereich ou=Sales, o=MyNet nach Usernamen (cn). Dies lässt sich beispielsweise sinnvoll mit Require: valid-user kombinieren - alle Mitarbeiter der Verkaufsabteilung dürften auf den entsprechenden Bereich zugreifen.

  • AuthLDAPUrl "ldap://ldap.mynet.de ldap-emerg.mynet.de /o=MyNet?cn"

Dies spricht den Server ldap.mynet.de oder notfalls den Ersatzserver ldapemerg.mynet.de an und durchsucht die gesamte MyNet-Domain nach Usernamen.

  • AuthLDAPUrl \

"ldap://ldap.mynet.de/ o=MyNet?uid?sub?(&(facsimileTelephoneNumber=*)(cn=Admins))" Die URL verwendet einen Filter: (&(facsimileTelephoneNumber=*)(cn=Admins))

Diese mit Und verknüpften Bedingungen bedeuten: User, die eine Faxnummer haben und zur Gruppe Admins gehören. Gruppe kann in einem LDAP

1 Das ist der Wert der symbolischen Konstanten MAX_STRING_LEN in der Datei includes/ httpd.h im Apache-Quellcode.

Verzeichnis mehr als eine Bedeutung haben. Beispielsweise könnte die Gruppe Admins auf dem LDAP-Server folgendermaßen definiert sein:

dn: cn=Admins, ou=Sales, o=MyNet objectClass: groupOfUniqueNames uniqueName: cn=Peter Schmitz, ou=Sales, o=MyNet uniqueName: cn=Heinz Mueller, ou=Sales, o=MyNet

Der optionale zweite Parameter von AuthLDAPUrl kann verwendet werden, um das in der eigentlichen URL angegebene URL-Schema durch eine bestimmte Verbindungsart zu überschreiben. Die möglichen Werte bedeuten Folgendes:

  • NONE (Standard): ungesicherte Verbindung über den Standard-ldap-Port (389)
  • SSL: gesicherte Verbindung über den Standard-ldaps-Port (636)
  • TLS oder STARTTLS: Startet zunächst eine ungesicherte Verbindung auf Port

389 und initiiert danach eine gesicherte Verbindung auf demselben Port.

Damit Sie sich vorstellen können, wie die LDAP-Authentifizierung in der Praxis funktioniert, sehen Sie hier noch ein kleines Komplettbeispiel:

<Location /ldap-secured> AuthType Basic AuthBasicProvider ldap AuthName "Sales dpt. only" AuthLDAPUrl "ldap://ldap.mynet.de/ou=Sales, o=MyNet?cn" Require ldap-user "Peter Schmitz" </Location>

AuthLDAPBindDN Optionaler DN für die LDAP-Server-Bindung

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPBindDN Distinguished-Name Standardwert nicht gesetzt

Optional können Sie mit dieser Direktive einen DN (Anmeldenamen) angeben, der bei der Bindung an den LDAP-Server übergeben werden soll. Normalerweise wird eine anonyme Bindung verwendet, was zu bevorzugen ist, weil dann insbesondere das zugehörige Passwort (AuthLDAPBindPassword) nicht offen an den LDAP-Server übertragen werden muss.

Beim Einsatz von Microsoft Active Directory als LDAP-Server scheint es ohne dieses Verfahren nicht zu funktionieren.

LDAP-Authentifizierung 9.5

AuthLDAPBindPassword Passwort für den DN der LDAP-Server-Bindung

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPBindPassword Passwort Standardwert nicht gesetzt

Wenn Sie mit AuthLDAPBindDN den DN eines berechtigten Benutzers für den LDAP-Server angeben, wird mit dieser Direktive das entsprechende Passwort übertragen. Wie bereits erwähnt, sollte beides unter normalen Umständen unterbleiben.

AuthLDAPCharsetConfig Name der Datei für die Sprachkürzel-Zeichensatz-Zuordnung

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext Server Syntax AuthLDAPCharsetConfig Dateipfad Standardwert nicht gesetzt

Mithilfe dieser Direktive können Sie den Pfad einer Datei angeben, die Sprachkürzel (die als Dateiendungen fungieren) den passenden Zeichensätzen zuordnet. Wie üblich kann der Pfad relativ zur ServerRoot oder absolut angegeben werden.

Die angegebene Datei ist eine einfache Textdatei, die Einträge im folgenden Format enthält:

Sprachkürzel Zeichensatz [Beschreibung]

Beispiel:

de iso-8859-1 Deutsch tr iso-8859-9 Türkisch

Sowohl die Sprachkürzel als auch die Zeichensätze finden Sie in den Tabellen in Anhang E.

Mit mod_authnz_ldap wird eine Datei namens charset.conv geliefert, die für die meisten Zwecke ausreichend sein sollte.

AuthLDAPCompareDNOnServer LDAP-Server für den Vergleich der DN verwenden

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPCompareDNOnServer On|Off Standardwert On

Wenn diese Direktive auf On gesetzt wird - was standardmäßig der Fall ist -, findet der Vergleich eines mittels Require ldap-dn angegebenen DN auf dem LDAPServer statt. Bei Off führt mod_authnz_ldap dagegen selbst einen einfachen Stringvergleich durch - dies ist schneller, kann aber korrekte Angaben irrtümlich ausschließen. Wenn Sie die Performance verbessern möchten, sollten Sie deshalb zunächst den Einsatz von mod_ldap in Betracht ziehen; dieses im nächsten Abschnitt beschriebene Modul stellt unter anderem einen Cache bereit, der LDAP-Zugriffe beschleunigen kann.

AuthLDAPDereferenceAliases Bestimmt, wann LDAP-Aliase aufgelöst werden.

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPDereferenceAliases newer | searching | finding | always Standardwert always

Diese Direktive legt fest, wann mod_auth_ldap Aliase auflöst, das heißt, wann überprüft wird, ob es Alternativeinträge im LDAP-Verzeichnis gibt, die einen gegebenen Wert gültig machen. Es gibt vier mögliche Werte:

  • always - Aliase werden immer sofort aufgelöst. Dies ist der Standardfall, der

in den meisten Fällen keine Probleme bereitet.

  • searching - Die Aliase werden beim Durchsuchen des LDAP-Verzeichnisses

aufgelöst.

  • finding - Es wird erst dann versucht, Aliase aufzulösen, wenn der angegebene

Eintrag nicht gefunden wird.

  • never - Aliase werden nie aufgelöst; nur der tatsächlich angegebene Eintrag

gilt.

AuthLDAPGroupAttribute LDAP-Attribute, die zur Prüfung der Gruppenmitgliedschaft verwendet werden

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig)

LDAP-Authentifizierung 9.5

Syntax AuthLDAPGroupAttribute Attribut Standardwert nicht gesetzt

Diese Direktive gibt die LDAP-Attribute an, nach denen zur Überprüfung der Gruppenmitgliedschaft gesucht werden soll. Wenn Sie keine Angaben machen, werden member und uniquemember verwendet. Um mehrere Attribute festzulegen, können Sie die Direktive mehrfach untereinanderschreiben. Beispiel:

AuthLDAPGroupAttribute member

AuthLDAPGroupAttributeIsDN DN des Client-Benutzernamens zur Prüfung der Gruppenmitgliedschaft verwenden

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPGroupAttributeIsDN On|Off Standardwert On

AuthLDAPGroupAttributeIsDN ist standardmäßig eingeschaltet und sorgt dafür, dass der Distinguished Name (DN) des Benutzernamens zur Überprüfung der Gruppenmitgliedschaft verwendet wird. Standardmäßig wird also nach einer Information wie cn=Peter Schmitz, ou=Sales, o=MyNet gesucht; wenn Sie die Direktive auf Off setzen, wird stattdessen nur der einfache Username (beispielsweise pschmitz) verwendet.

AuthLDAPRemoteUserIsDN DN des Client-Benutzernamens als REMOTE_USER setzen

Modul mod_authnz_ldap (bis 2.0.x: mod_auth_ldap) Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPRemoteUserIsDN On|Off Standardwert Off

Normalerweise enthält die Umgebungsvariable REMOTE_USER den einfachen Benutzernamen, der bei der Client-Anfrage übertragen wurde, beispielsweise hmueller. Wenn Sie in der Variablen stattdessen den vollständigen DN haben möchten, damit Sie ihn beispielsweise für CGI-Skripte oder Rewrite-Aktivitäten auswerten können, müssen Sie die Direktive explizit auf On setzen:

AuthLDAPRemoteUserIsDN On

AuthLDAPRemoteUserAttribute Das angegebene LDAP-Attribut als REMOTE_USER setzen

Seit Version 2.2 Modul mod_authnz_ldap Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPRemoteUserIsDN Attribut Standardwert Nicht gesetzt

Mithilfe dieser Direktive können Sie ein beliebiges LDAP-Attribut festlegen, das als Wert für die Umgebungsvariable REMOTE_USER gesetzt wird - beispielsweise uid oder cn. Wenn diese Direktive gesetzt ist, hat sie Vorrang vor AuthLDAPRemoteUserIsDN. Wichtig ist allerdings, dass das angegebene Attribut in AuthLDAPUrl enthalten ist, sonst hat diese Direktive gar keine Wirkung.

AuthzLDAPAuthoritative Bestimmt, ob Nicht-LDAP-Authentifizierungsdaten an andere Module weitergereicht werden.

Seit Version 2.1-beta Modul mod_authnz_ldap Kontext <Directory>, <Location>, <Files>, .htaccess (AuthConfig) Syntax AuthLDAPAuthoritative On|Off Standardwert On

Wie alle Auth*Authoritative-Direktiven ermöglicht es AuthzLDAP Authoritative, die Anmeldedaten gegebenenfalls an weitere Authentifizierungsmechanismen durchzureichen. Für die Kompatibilität mit Microsoft FrontPage müssen Sie Authz-LDAPAuthoritative auf Off setzen.

9.5.4 LDAP-Performance-Verbesserung mit mod_ldap

Wenn Ihre Website zu großen Teilen von der LDAP-basierten Authentifizierung abhängt oder wenn Sie andere Module einsetzen, die mit einem LDAP-Server zusammenarbeiten, sollten Sie das Modul mod_ldap aktivieren; je nach konkretem LDAP-Server kann es sogar erforderlich sein, das Modul grundsätzlich zu aktivieren. Es ergänzt die grundlegende LDAP-Funktionalität um zwei wichtige Faktoren:

LDAP-Authentifizierung 9.5

  • Connection-Pooling

Eine Verbindung zum LDAP-Server wird nach einmaligem Gebrauch nicht wieder abgebaut, sondern aufrechterhalten. Dies bringt einen ähnlichen Performance-Gewinn wie persistente HTTP-Verbindungen.

  • LDAP-Cache

mod_ldap richtet in einem allgemein zugänglichen Shared-Memory-Segment einen Cache ein.2 Der Cache erledigt zwei verschiedene Teilaufgaben: Der Search/Bind-Cache speichert Suchergebnisse, die zu einer erfolgreichen Bindung an das LDAP-Verzeichnis geführt haben, während der Operations-Cache Vergleichsoperationen und ihre Ergebnisse zwischenspeichert.

Nachdem Sie mod_ldap aktiviert haben, brauchen Sie nichts Besonderes mehr zu veranlassen, damit mod_auth_ldap und andere LDAP-basierte Module von dessen Fähigkeiten Gebrauch machen; die mod_ldap-Direktiven dienen lediglich der genauen Steuerung des Cache-Verhaltens und ermöglichen zusätzlich die Konfiguration von SSL-Verbindungen zum LDAP-Server.

Der Handler ldap-status Das Modul mod_ldap definiert einen eigenen Handler, der Statusinformationen über den Cache anzeigen kann. Er heißt ldap-status und funktioniert genau wie die in Kapitel 7, Header und MIME-Einstellungen, vorgestellten Handler server-info und server-status. Die folgende Beispielkonfiguration ermöglicht den Zugriff auf den LDAP-Status über eine URL nach dem Muster https:// www.mynet.de/ldap-status:

<Location /ldap-status> SetHandler ldap-status </Location>

Selbstverständlich sollten Sie diese URL mit Authentifizierungsdirektiven versehen, damit die Öffentlichkeit nicht auf diese Informationen zugreifen kann.

LDAPCacheEntries Maximale Anzahl von Einträgen im LDAP-Cache

Seit Version 2.0.41 Modul mod_ldap Kontext Server

2 Auf Plattformen, die kein Shared Memory unterstützen, wird für jeden Child-Prozess ein eigener LPAP-Cache eingerichtet. In der Regel verbessert aber auch das noch die Performance.

Syntax LDAPCacheEntries Anzahl Standardwert 1024

Diese Direktive bestimmt die Höchstzahl der Einträge im Search/Bind-Cache. Der Vorgabewert 1.024 sollte normalerweise ausreichen; über eine Erhöhung brauchen Sie nur nachzudenken, wenn Sie im ErrorLog eine entsprechende Fehlermeldung finden sollten. Wenn Sie den Wert 0 verwenden, wird der Search/BindCache deaktiviert.

LDAPCacheTTL Gültigkeitsdauer für Elemente im LDAP-Cache

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPCacheTTL Sekunden Standardwert 600

Mit dieser Direktive wird die Gültigkeitsdauer für Elemente im Search/BindCache festgelegt. Wenn sich in Ihrem LDAP-Verzeichnis nur selten Änderungen ergeben, könnten Sie in Erwägung ziehen, den Wert von 600 Sekunden (zehn Minuten) zu erhöhen. Andererseits gibt es Situationen, in denen Zugriffsrechte sehr schnell geändert werden müssen - beispielsweise, wenn ein ehemaliger Mitarbeiter bei der bedeutendsten Konkurrenzfirma angefangen hat. Insofern ist eine wesentliche Steigerung ein gewisses Sicherheitsrisiko.

LDAPConnectionTimeout Maximale Dauer eines LDAP-Verbindungsversuchs

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPConnectionTimeout Sekunden Standardwert 10

Diese Direktive legt fest, wie lange Apache versuchen soll, eine Verbindung zu einem LDAP-Server herzustellen. Die Standardwartezeit beträgt zehn Sekunden.

LDAPOpCacheEntries Anzahl der LDAP-Vergleichsoperationen im LDAP-Cache

LDAP-Authentifizierung 9.5

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPOpCacheEntries Anzahl Standardwert 1024

Dies ist die maximale Menge von Einträgen im Operations-Cache. Der Wert 0 deaktiviert diesen Teil des Caches ganz; die Vorgabe 1.024 reicht normalerweise aus.

LDAPOpCacheTTL Gültigkeitsdauer für Elemente im Operations-Cache

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPOpCacheTTL Sekunden Standardwert 600

Diese Direktive bestimmt die maximale Gültigkeitsdauer von Objekten im Operations-Cache. Auch hier sind Sie mit dem Standardwert 600 in der Regel gut beraten (Näheres siehe unter LDAPCacheTTL).

LDAPSharedCacheFile Pfad und Dateiname des Shared-Memory-Bereichs für den LDAP-Cache

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPSharedCacheFile Verzeichnispfad/Dateiname Standardwert nicht gesetzt

Mit dieser Direktive werden der Pfad und der Dateiname für den SharedMemory-Bereich festgelegt, in dem der LDAP-Cache platziert wird. Wenn Sie die Direktive weglassen, verwendet jeder Child-Prozess seinen eigenen Cache. Selbstverständlich darf die Datei aus Sicherheitsgründen nicht innerhalb der DocumentRoot oder in einem mittels Alias eingebundenen Verzeichnis liegen. Beispiel:

LDAPSharedCacheFile /usr/local/apache2/ldap_cache

LDAPSharedCacheSize Größe des Shared-Memory-Bereichs für den LDAP-Cache

Seit Version 2.0.41 Modul mod_ldap Kontext Server Syntax LDAPSharedCacheSize Bytes Standardwert 102400

Dies ist die maximale Größe des Shared-Memory-Bereichs für den Cache. Der Vorgabewert ist 100 Kilobyte, was in der Regel ausreicht. Der Wert 0 deaktiviert den Shared-Memory-Cache.

LDAPTrustedClientCert Dateiname oder Nickname eines LDAP-Client-Zertifikats

Seit Version 2.2 Modul mod_ldap Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (All) Syntax LDAPTrustedClientCert Typ Pfad|Dateiname|Nickname [Passwort] Standardwert nicht gesetzt

Diese Direktive ermöglicht die Angabe von Pfad, Dateiname oder Nickname eines Zertifikats, das bei der jeweiligen Verbindung zum LDAP-Server eingesetzt wird, um die Identität des Clients (in diesem Fall also des Webservers) zu verifizieren. Ob Ihr spezifischer LDAP-Server Client-Zertifikate unterstützt - und, falls ja, welchen Typ -, entnehmen Sie bitte seiner Dokumentation. Novell-Verzeichnisdienstserver unterstützen beispielsweise keine Zertifikate für einzelne Verbindungen; hier können Sie nur die anschließend beschriebene Direktive LDAPTrustedGlobal Cert verwenden.

Die unterstützten Typen sind:

  • CERT_DER - binäres Client-Zertifikat in DER-Codierung
  • CERT_BASE64 - PEM-codiertes Client-Zertifikat
  • CERT_NICKNAME - Client-Zertifikat-Nickname (Netscape SDK)
  • KEY_DER - binärer Private Key in DER-Codierung
  • KEY_BASE64 - PEM-codierter Private Key

LDAP-Authentifizierung 9.5

LDAPTrustedGlobalCert Datei oder Datenbank mit Informationen über vertrauenswürdige Zertifizierungsstellen oder globale Client-Zertifikate

Seit Version 2.2 Modul mod_ldap Kontext Server Syntax LDAPTrustedGlobalCert Typ Pfad|Dateiname [Passwort] Standardwert nicht gesetzt

Mithilfe dieser Direktive können Sie eine Datei oder eine Datenbank angeben, in der sich globale, also systemweit gültige, Client-Zertifikate befinden, die beim Aufbau von LDAP-Verbindungen verwendet werden sollen. Auch Dateien mit den Zertifikaten vertrauenswürdiger Zertifizierungsstellen (Certificate Authority oder CA) können hier angegeben werden. Die unterstützten Zertifikats- und Dateitypen hängen auch hier vom konkreten LDAP-Server ab. Grundsätzlich werden folgende Typen unterstützt:

  • CA_DER - binäres CA-Zertifikat in DER-Codierung
  • CA_BASE64 - PEM-codiertes CA-Zertifikat
  • CA_CERT7_DB - Netscape-CA-Zertifikat-Datenbankdatei cert7.db
  • CA_SECMOD - Netscape-secmod-Datenbankdatei
  • CERT_DER - binäres Client-Zertifikat in DER-Codierung
  • CERT_BASE64 - PEM-codiertes Client-Zertifikat
  • CERT_KEY3_DB - Netscape-Client-Zertifikat-Datenbankdatei key3.db
  • CERT_NICKNAME - Client-Zertifikat-Nickname (Netscape SDK)
  • CERT_PFX - PKCS#12-codiertes Client-Zertifikat (Novell SDK)
  • KEY_DER - binärer Private Key in DER-Codierung
  • KEY_BASE64 - PEM-codierter Private Key
  • KEY_PFX - PKCS#12-codierter Private Key (Novell SDK)

LDAPTrustedMode Voreinstellung für die Art der LDAP-Server-Verbindungen

Seit Version 2.2 Modul mod_ldap Kontext Server, <VirtualHost>

Syntax LDAPTrustedMode NONE|SSL|TLS|STARTTLS Standardwert nicht gesetzt

Die möglichen Werte für diese Direktive und ihre Bedeutung wurden bereits für AuthLDAPUrl beschrieben. Diese Direktive stellt die globale Voreinstellung für den Server beziehungsweise für den jeweiligen virtuellen Host bereit. Wenn Sie in LDAP-URLs das Schema ldaps:// verwenden, wird sie überschrieben.

Abgerufen von „https://wiki.foxtom.de/index.php?title=Apache/09_Zugriff/LDAP-Authentifizierung&oldid=141781“