View Attach Info

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. (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 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:

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 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 diesem Blog-Eintrag

Linkliste zum Thema:#

Die Basics:

Debian-Seiten: sonstige interessante Links: Programme, um LDAP-Verzeichnisse zu pflegen (Frontends):
Tags:  ServerDienste

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-17) was last changed on 09-Oct-2020 00:43 by ThomasBayen