!!!LDAP-Server unter Linux

LDAP bietet Zugriff auf verschiedene Verzeichnisse. Praktische Anwendungen sind wohl vor allem Benutzerverzeichnisse zur Authentifizierung sowie Adressverzeichnisse z.B. für Mailclients.

Wer LDAP zur Benutzer-Authentifizierung benutzen möchte, kommt wohl auch früher oder später an Kerberos nicht vorbei: http://de.wikipedia.org/wiki/Kerberos_%28Informatik%29

Eine sehr gute deutsche Anleitung gibt es unter http://debian-handbook.info/browse/de-DE/stable/sect.ldap-directory.html


!! Vorgehensweise zur Installation

Ich selber habe folgende Pakete installiert:

 aptitude install slapd ldap-client
 aptitude install phpldapadmin libapache2-mod-php5 apache2-mpm-prefork
 aptitude install ldap-account-manager

(In Debian 10 Buster sind die WEboberflächen nicht mehr enthalten, aber ich konnte das LAM-Paket von https://sourceforge.net/projects/lam/ installieren, nachdem ich "aptitude install apache2 php" gemacht hatte.)

Man kann nun unter http://llocalhost/phpldapadmin und http://localhost/lam auf die beiden Programme zugreifen. Es handelt sich um Weboberflächen, mit denen komplett der LDAP-Server verwaltet werden kann. der LAM hat eine hübschere Oberfläche insbesondere um einige Standarddinge wie Benutzer, Gruppen und Hosts zu verwalten. Der phpldapadmin ist eher was für "echte Administratoren" und erlaubt die Bearbeitung beliebiger LDAP-Einträge. Der Witz ist, das im LAM der phpldapadmin integriert ist. Das sieht zwar nach einer älteren Version aus und ist nicht in voller strahlender Schönheit integriert wie LAM sonst aussieht, aber es geht. Mir persönlich hat es geholfen, den phpldapadmin dennoch als erstes gekannt zu haben. Natürlich kommt man auch um die Kommandozeilentools wie '''ldapsearch''' und '''ldapmodify''' nicht herum, die mit dem Paket ldap-client installiert werden.

Wer eine Weboberfläche wie phpldapadmin benutzt, sollte diese definitiv per ssl/tls absichern. Außerdem war mein phpldapadmin von selbst nicht richtig konfiguriert (der Baum links zeigt example.com und nicht meine eigene Domain). Wie man das behebt, steht [hier|http://stackoverflow.com/questions/13921030/phpldapadmin-does-not-work-for-an-unknown-reason]. ''(Eine Vermutung ist, das das mit einer redseligeren dpg-reconfigure-Einstellung besser gewesen wäre.)''

Eine ordentliche Einführung in die ersten Schritte gibt es z.B. hier: http://techpubs.spinlocksolutions.com/dklar/ldap.html


!! Was kommt den nun rein in so ein Verzeichnis?

Ein Verzeichnis ist immer ein hierarchisch organisierter Baum. Als allererstes erzeugt man in diesem Baum eine Art Hauptverzeichnis, den dem man dann arbeitet. Das geschieht bereits bei der Installation des Debian-Paketes (sonst dpkg-reconfigure ausführen). Dieses Hauptverzeichnis hat wie jedes Objekt im Verzeichnis einen Pfad, der bei LDAP '''"DN"''' (Distinguished Name) heisst. Dieser DN wird in einer LDAP-spezifischen Syntax angegeben, die etwas gewöhnungsbedürftig ist, an die man sich aber gewöhnen muss. Anstatt jetzt z.B. meine Haupt-DN "bayen.de" zu nennen, heisst die nämlich "dc=bayen,dc=de". "dc=" heisst dabei, das es sich bei den Komponenten im Baum um sogenannte "Domain Component"s handelt.

Unterhalb dieses Eintrags hat der Debian-Installationsprozess einen Benutzer angelegt, der als Administrator dient. Ein solcher Eintrag wird in einem "cn" (Common Name)-Knoten gemacht. Dessen kompletter DN heisst dann also "cn=admin,dc=bayen,dc=de". Das ist der Anmeldename, den man z.B. in LAM oder mit den Kommandozeilentools angibt. Ich will nicht verschweigen, das es noch den Begiff des RDN "Relative Distinguished Name" gibt. Das ist ein nicht-absoluter Pfad in der DN-Notation, also im Beispiel "cn=admin".

Nun stellt sich die Frage, was wir denn überhaupt verwalten wollen in unserem Verzeichnis. Der Klassiker sind da zweifelsohne Benutzer. Wer Benutzer hat, braucht auch Gruppen. Für diese Verzeichnisse scheint es eine feste Konvention zu geben, das diese den RDN "ou=People" und "ou=Group" erhalten ("ou" für "Organizational Unit").

Unterhalb von "ou=People" können nun Benutzer angelegt werden. Diese haben wieder einen RDN, der mit "cn=" beginnt. So kann ein Benutzereintrag z.B. den folgenden DN haben: "cn=Thomas Bayen,ou=People,dc=bayen,dc=de".

Nun kommen wir zu der Frage, was so ein Eintrag im Verzeichnis denn überhaupt für Daten enthalten kann. Jeder Eintrag kann verschiedene Attribute haben. Das wichtigste Attribut ist dabei "objectClass". Jeder Eintrag hat eine "strukturelle" Objektklasse und beliebige weitere, die man hinzufügen kann. Welche Objektklassen es gibt, wird durch sogenannte Schemas definiert. In diesen Schemas ist dann festgelegt, welche Attribute ein Objekt haben kann und wie diese aussehen. So hat mein Benutzereintrag die strukturelle Klasse "inetOrgPerson". Deren Schema ist vom Standard festgelegt und enthält Einträge wie einen Namen, Adresse, Telefonnummer, EMail, etc. zu einer Person. Das ist zuerst einmal eine feine Klasse, um eine Person zu beschreiben. Als zusätzliche Klasse habe ich noch "posixAccount" eingetragen. Dieses Schema definiert z.B. ein Attribut für die Login-Shell und das Home-Verzeichnis. Das sind Daten, die normale Personen nicht unbedingt haben und die deshalb nicht im Basisschema für eine Person enthalten sind. So kann man also durch hinzufügen verschiedener objectClasses einem Objekt mehr Eigenschaften geben. Es sind dann eigene Schemata denkbar für Thunderbird-Adressbucheinträge, für Samba-Benutzer, etc...

!! Verschlüsselung

Wer LDAP für die Benutzerverwaltung benutzt, muss natürlich darauf achten, das keine Daten dabei wegkommen. Eine Frage ist dabei, welche Daten man überhaupt anonym oder an eingetragene Benutzer herausgibt. Eine andere Frage ist, wie man die Kontrolle des Passwortes regelt. Ohne weitere Konfiguration wird beim Zugriff auf den LDAP-Server jedes Passwort im Klartext übertragen...

So richtig sind mir die Zusammenhänge und Gefahren noch nicht klar, deshalb schreibe ich hier erst einmal meine persönlichen Erfahrungen und Ideen nieder. So weit ich das verstanden habe, ist es eine gute Idee, die Kommunikation mit dem LDAP-Server per SSL mit entsprechenden Zertifikaten zu verschlüsseln. Wozu dann aber oft noch Kerberos empfohlen wird und was da genau der Witz dran ist, hat sich mir bisher noch nicht ganz erschlossen. Mir scheint, das Kerberos interessant ist, um sich im Laufe einer Session mehrfach immer wieder und an anderen Diensten anzumelden ohne jedes Mal das Passwort eingeben zu müssen (oder es im Client zu cachen), also für sog. "single-sign-on". Rein von der Sicherheit her scheint es mir jedoch keinen Vorteil gegenüber einem reinen LDAP-Passwort mit SSL-Verschlüsselung zu bieten...?!?

Man benötigt ein eigenes, signiertes Zertifikat (siehe OpenSSL) (für einen rein internen Gebrauch bietet es sich an, eine [eigene CA|http://www.lug-kr.de/wiki/OpenSSL#section-OpenSSL-ZertifikateMitEigenerCertificateAuthorityCAZertifizieren] zu erstellen.

!! Verschlüsselung, zweiter Versuch

Wenn man LDAP in einem Netzwerk zur Verwaltung von Benutzern verwenden will, ist Verschlüsselung ein Muss. Ansonsten wird die gesamte Kommunikation (inklusive Passwörtern) im Klartext versendet. Da es sich um einen sicherheitskritischen Bereich handelt, ist LDAP allerding auch recht wählerisch, was den Umgang mit Zertifikaten anbetrifft. Ein einfaches selbstsiginiertes benutzen geht nicht, es muss schon als CA im Client eingetragen sein. Dazu sind folgende Schritte zu machen:

* Erzeugen einer (selbstsignierten) root-CA (Certificate Authority) (wie in vielen OpenSSL-Anleitungen beschrieben).
* Erzeugen eines Zertifikates für den LDAP-Server mit dessen Domain-Namen
* Einbinden dieser Zertifikatsdateien (3 Stück) im LDAP-Server (siehe http://mindref.blogspot.de/2010/12/debian-openldap-ssl-tls-encryption.html - http://serverfault.com/questions/455529/openldap-tls-authentication-setup half mir bei einer Fehlermeldung undf http://www.openldap.org/doc/admin24/tls.html erklärt die verwendeten Parameter)
* Starten des LDAP-Servers auf einem TLS-fähigen Port (ldaps-Protokoll)
* Kopieren des öffentlichen CA-Zertifikats auf den(alle) Client(s) (z.B. nach )
* Installieren dieses CA-Zertifikats als root-CA im Client-Betriebssystem (https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/ und manpage von update-ca-certificates)
* Konfiguration der Clients in /etc/ldap/ldap.conf (dabei wie vorgegeben die normale ca-certificates.crt einbinden, die wir gerade geupdated haben - nicht TLS_REQCERT benutzen (wie z.B. [hier|http://wiki.ubuntuusers.de/OpenLDAP_ab_Precise] fälschlich erklärt), das senkt die Sicherheit eklatant)

!! Benutzer-Authentifizierung

Der klassische und meistbenutzte Anwendungsfall für LDAP ist die netzwerkweite Authentifizierung von Benutzern. Um das zu erreichen, installiert man libnss-ldap und libpam-ldap. Ich musste beide Pakete mit dpkg-reconfigure neu konfigurieren, bis alle Einstellungen wirklich richtig waren. Außerdem sollte man natürlich vorher die Datei /etc/ldap/ldap.conf konfiguriert haben (das sollte man vorher schon mit ldapsearch testen).

Falls Benutzer auch Ihr Passwort ändern können sollen, muss noch ein kleiner [Bug in der Konfiguration|https://bugs.launchpad.net/ubuntu/+source/libpam-ldap/+bug/329067] angepasst werden. Dann kann man sein PAsswort wie gewohnt per passwd-Kommando ändern.


!! einzelne Attribute lesen

Wer einzelne Attribute auslesen möchte, um sie z.B. in einer Shellvariable weiterzuverwenden, kann die Ausgabe von ldapsearch parsen. (siehe z.B. http://stackoverflow.com/questions/5434296/i-want-a-shell-script-that-reads-a-specific-attribute-value-from-an-ldapsearch-r)

!! Passwort ändern

Wer das am Anfang angegebene root-Passwort ändern möchte, muss wissen, das das root-Passwort nicht unbedingt das glecihe ist, wie das Passwort des admin-Users. Ggf. hat man zwei Passwörter, mit denen man sich einloggen kann (jawoll!). Wer in die Verlegenheit gerät, kann das admin-Passwort relativ einfach über eine GUI ändern, während das root-Passwort in der config-Datenbank steht (die Deine GUI womöglich nicht anzeigt). Wer in die Verlegenheit kommt, findet Hilfe in [http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/ diesem Blog-Eintrag]

!!! Linkliste zum Thema:

Die Basics:
* http://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
* http://de.wikipedia.org/wiki/OpenLDAP

Debian-Seiten:
* http://wiki.debian.org/LDAP/OpenLDAPSetup (sagt selber, das er sehr veraltet ist und sich seit Squeeze einiges verändert hat)
* http://www.debian-administration.org/article/OpenLDAP_installation_on_Debian

sonstige interessante Links:
* http://tldp.org/HOWTO/LDAP-HOWTO/index.html
* http://dlhp.berlios.de/HOWTO/DE-LDAP-HOWTO.html
* http://directory.apache.org/ Apache-Projekte
** http://directory.apache.org/apacheds/ Directory Server ~ApacheDS (in Java)
** http://directory.apache.org/studio/ Directory Studio (Frontend auf Eclipse Basis zur Pflege eines LDAP Directories, unabhängig von ~ApacheDS)

Programme, um LDAP-Verzeichnisse zu pflegen (Frontends):

* http://ldapwiki.willeke.com/wiki/LDAP%20Browsers
* http://luma.sourceforge.net/about.html - trotz Angabe auf der Webseite konnte ich kein Debian-Paket finden
* https://oss.gonicus.de/labs/gosa/wiki gosa erlaubt, komplexe Systeme mit riesigen Benutzermengen und sehr vielen angeschlossenen Client-Programmen zu verwalten. Für meine Zwecke wohl overkill, aber sicherlich auch einen Blick wert.
* http://sourceforge.net/projects/ldap-at (sieht nach der Projektseite aus wie ein einfaches Tool für den Desktop - läuft aber nicht stabil)
* http://sourceforge.net/projects/phpldapadmin - webgestützt
* https://www.ldap-account-manager.org/lamcms/releases - webgestützt
* http://sourceforge.net/projects/jxplorer/ - Java (habe ich noch nicht getestet)

[{Tag ServerDienste}]