DebianLDAP
Back to current versionRestore this version

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

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

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.

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.

Linkliste zum Thema:

Die Basics:

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