Thomas Kramer

IT-COW | All posts tagged 'OpenLDAP'

Aufsetzen eines OpenLDAP-Servers & Thunderbird-Integration

By Administrator at Juni 24, 2010 22:44
Filed Under: Administration, Anleitungen, Linux

Seit einiger Zeit befasse ich mich mit dem Aufsetzen eines OpenLDAP-Servers, der entsprechende Rechner läuft mit Linux unter Kubuntu 9.04.

 

Empfehlenswerte Seiten, welche sich mit den LDAP-Grundlagen beschäftigen sind dieses PDF von Stefan Kania, der Wikipedia-Eintrag oder die Seiten von Microsoft-TechNet zu dem Thema. Realisiert werden kann mit LDAP beispielsweise ein globales Adressbuch oder ein Single-Sign-On für Server-Dienste.

 

Microsofts Active Directory baut ebenfalls auf LDAP auf, ist aber natürlich im Gegensatz zu OpenLDAP durch die benötigten Windows-Server-Versionen implizit kostenpflichtig. Auf dem Windows Home Server läuft AD übrigens nicht, wenn man versucht es doch zu aktivieren fährt (angeblich) der Server jede Stunde herunter.

 

Als weitere kostenfreie Alternative zu OpenLDAP gibt es u. a. den Apache Directory Server. Mit dem Apache DS wollte ich mich schon seit längerem beschäftigen, bin aber leider noch nicht dazu gekommen.

 

Da mein Linux-Rechner eh 24/7 läuft, bot sich OpenLDAP für meine Zwecke an. Leider sind die meisten Tutorials zu OpenLDAP im Netz mittlerweile veraltet, seit mit LDAPv3 vom slapd.conf- auf das cn=config-Konfigurationsschema umgestellt wurde. Als Faustregel kann man wohl sagen, das Dokumentationen zur Konfiguration von OpenLDAP von vor 2009 (obwohl cn=config offenbar schon 2007 bekannt) und mit dem Stichwort "slapd.conf" eher unbrauchbar sind (ohne sie abwerten zu wollen) - zumindest für eine aktuelle OpenLDAP-Version.

 

Ergänzung 01.07.2010: Ein Artikel zur Umstellung auf das cn=config-Backend: Link.

 

Installation von OpenLDAP

 

Allgemein unterscheiden kann man zwischen den Konfigurationsdateien (cn=config), den Schema-Dateien und den Daten-Dateien. Mit LDAPv3 liegen erstmals alle Dateien als LDIF-Dateien vor, das heisst selbst die Konfiguration wird mittlerweile in die Datenbank importiert. Allerdings war man beim Umstieg bei OpenLDAP nicht ganz konsequent, denn nicht alle mitgelieferten Schemata im /etc/ldap/schema-Verzeichnis liegen bereits im LDIF-Format, sondern zum Teil nur im älteren SCHEMA-Format vor und müssen daher vor Benutzung erst konvertiert werden.

 

Grundsätzlich benötigt man natürlich für alle Änderungen an OpenLDAP Administrator-Rechte. Dazu entweder im Terminal als root einloggen oder vor jeden Befehl ein sudo schreiben.

 

Nach der Installation mit dem Befehl apt-get install slapd ldap-utils kann mit dpkg-reconfigure slapd und dem darauf erscheinenden Dialog die grundlegende Konfiguration vorgenommen werden, wobei der Aufbau sich anschließend an einer Domäne orientiert. Die Datenbank wird dabei mit eingerichtet - gemäß Link soll dies ab (K)Ubuntu 9.10 nicht mehr der Fall sein, dann muss man die Datenbank händisch erstellen. Ich habe hier noch die Vorgängerversion 9.04 im Einsatz.

 

Aufbau LDAP-Struktur und Daten-Dateien

 

Zum grundlegenden Aufbau der LDAP-Struktur (innerhalb der Datenbank) gilt, dass diese einer Baumstruktur gleicht. Orientiert habe ich mich beim konkreten Aufsetzen im Wesentlichen an Markus Effinger´s Das kleine OpenLDAP 1x1 (zum Vergleichen), dem Wiki-Eintrag zu OpenLDAP von ubuntuusers.de und diesem Eintrag.

 

Daher habe ich exemplarisch einmal diesen Aufbau erzeugt:

 

dc=de

|_ dc=home

|____cn=admin

|____ou=Adressbuch

|______ou=global

|________[...]

|______ou=privat

|________[...]

 

Gemäß Link bedeutet dc Domain Component, die Domäne lautet im Beispiel also home.de (im Baum von unten nach oben lesen). Objekte mit der Bezeichnung ou (Organizational Unit) sind lediglich Container-Objekte, cn (Common Name) kennzeichnet Namenseinträge in der Datenbank. Wenn ein Passwort für den Eintrag (userPassword) angegeben (und die Zugriffsrechte vergeben) wurden, kann sich auch mit dieser Autorität eingeloggt werden.

 

Grundsätzlich wird zur eindeutigen Kennzeichnung eines Objekts sein Name mit den Namen der übergeordneten Objekte - durch ein Komma getrennt - vervollständigt. ou=global,ou=Adressbuch,dc=home,dc=de würde demnach im obigen Beispiel den Eintrag ou=global bezeichnen. Dieser vollständige Kennzeichner nennt sich in der LDAP-Nomenklatur dn (Distinguished Name) - bei DNS-Servern wird der vollständige Kennzeichner übrigens als Fully Qualified Domain Name bezeichnet.

 

Der Aufbau der Daten-Dateien ist sehr einfach: Zuweisungen geschehen mit Parameter: Wert, # kennzeichnen eine Kommentarzeile und mit einer Leerzeile beginnt ein neuer Eintrag für die Datenbank. Jeder Eintrag muss sein dn-Kennzeichen (absolute Position im Baum) und sein cn/ou-Kennzeichen (eigener Bezeichner) enthalten.

 

Die Daten-Dateien enthalten mit dem Parameter objectClass Verweise auf die Objektklassen, welche in den Schema-Dateien definiert werden. Jeder Eintrag in der Datenbank kann beliebig viele Verweise auf Objektklassen enthalten, wobei jeder weitere Verweis die Vielzahl der möglichen Daten zu diesem Eintrag erhöht.

 

Den Aufbau der Schema-Dateien werde ich nicht explizit erläutern, sondern wieder auf das PDF von Stefan Kania sowie exemplarisch auf diesen Eintrag verweisen. Wichtig an der Stelle ist (u. a.), das der dn-Eintrag der Schema-Datei auf ...,cn=schema,cn=config enden muss. Wie gesagt müssen auch die Schema-Dateien im LDIF-Format vorliegen.

 

Zugriffsrechte festlegen und Allgemeines

 

Durch die mit dpkg-reconfigure slapd erstellte Konfiguration werden zwei Administrator-Benutzer erstellt. Der Erste, cn=admin,cn=config, kann die Konfiguration verändern und Schemata einspielen. Der zweite, cn=admin,dc=home,dc=de (siehe Beispiel oben), kann konkret Daten einspielen und löschen. Diese Rechte sind nicht allein durch das Vorhandensein dieser Benutzer geregelt, sondern mit dem Konfigurationsprogramm werden diesen Benutzern explizit in den Dateien olcDatabase={0}config.ldif und olcDatabase={1}hdb.ldif im Verzeichnis /etc/ldap/slapd.d/cn=config/ die Rechte zugewiesen.

 

In der ersten Datei wird der Admin cn=admin,cn=config definiert und ihm ein Passwort - verschlüsselt - über den Parameter olcRootPW zugewiesen. Mit dem Kommandozeilenprogramm slappasswd kann ein neues Passwort erstellt werden, das dann in diese Datei mit einem Texteditor geschrieben werden kann.

 

In der Datei olcDatabase={1}hdb.ldif werden dagegen die Zugriffsrechte festgelegt - man kann aber auch die gesamte Konfiguration in einer einzelnen Datei vornehmen. 

 

Allgemein muss man die Änderungen an der Konfiguration anschließend händisch mit ldapadd in die Datenbank einspielen, das schreibt auch dieser Link... jedoch wurden Änderungen an den Zugriffsrechten bspw. in meinen Tests auch bereits mit den Veränderungen an den Konfigurationsdateien ansich und anschließendem Neustarten des Dienstes aktiviert, den ldapadd-Befehl musste ich da nicht anwenden...

 

Als guten Überblick über die Zugriffsrechte von OpenLDAP habe ich diesen Link gefunden. Eine alternative Seite (etwas übersichtlicher) findet sich hier - wobei beachtet werden sollte dass die erste Auflistung auf dieser Seite das veraltete slapd.conf-Konfigurationsschema behandelt, die aktuell gültige Variante betrifft dagegen die olcAccess-Objekte welche weiter unten behandelt werden. Mit den geschweiften Klammern {} wird übrigens die Reihenfolge der Rechte festgelegt - die Rechte-Zuweisung kann also schon kompliziert werden.

 

Damit jeder Lese- und Schreibrechte auf das globale Adressverzeichnis, auf das private des Admins aber gar keine Zugriffsrechte hat (außer dem Admin selbst, auf das obige Beispiel bezogen), kann man die Einträge in der Datei olcDatabase={1}hdb.ldif folgendermaßen ändern:

 

olcAccess: to dn.base="ou=global,ou=Adressbuch,dc=home,dc=de" by * manage

olcAccess: to dn.subtree="ou=global,ou=Adressbuch,dc=home,dc=de" by * manage

olcAccess: to dn.children="ou=global,ou=Adressbuch,dc=home,dc=de" by * manage

olcAccess: to * by dn="cn=admin,dc=home,dc=de" manage

 

Das liest sich folgendermaßen: Auf was Zugriff, durch wen, welche Rechte konkret. Es können auch mehrere Rechte pro Zeile geregelt werden, der Übersicht wegen empfiehlt es sich aber dann eine neue Zeile anzufangen. Manage kennzeichnet das höchste Recht, jede Rechte-Stufe beinhaltet auch jede kleinere - am besten den bereits erwähnten Link durchlesen. Eine gute deutsche Anleitung dazu habe ich noch nicht gefunden, bitte melden wenn Ihr eine findet.

 

Der Standard-Port für LDAP ist 389, kann aber über die Datei /etc/default/slapd und über die Zuweisung slapd_services="IP:Port" geändert werden. Anschließend - und nach jeder Konfigurationsänderung - nicht vergessen OpenLDAP neu zu starten: /etc/init.d/slapd restart.

 

Übrigens kann durch die Eingabe von ldap://IP-Adresse:Port/ im Webbrowser der Personen-Suchen-Dialog von Windows-Contacts, welches im Lieferumfang von Windows Vista und Windows 7 enthalten ist, aufgerufen werden. Dafür sollte der anonyme Zugriff auf dc=home,dc=de (siehe Beispiel) gewährt werden, weil über den Webbrowser kein Start-Eintrag (Basis-DN) festgelegt werden kann, ab welchem gesucht werden soll.

 

Leider ist aus dem verbreiteten Mail-Programm Thunderbird heraus nur lesender Zugriff auf ein LDAP-Verzeichnis möglich. Es gibt aber auch das AddOn LdapRW, mit dem auch schreibender Zugriff möglich sein soll - das habe ich aber noch nicht getestet.

 

Frontend-Programme

 

Nachdem die grundlegende Konfiguration erstellt wurde kann mit Programmen wie JXplorer und LDAP Admin (kostenlos) oder auch mit LDAP Administrator (kostenpflichtig) die Datenbank bearbeitet werden - diese befindet sich übrigens im Verzeichnis /var/lib/ldap.

 

Für die Frontend-Programme benötigt man Zugangsdaten: Mit Bind-DN wird der Benutzer für die Authentifizierung angegeben, als Basis-DN bezeichnet man dagegen den Start-Eintrag ab dem im Baum gesucht werden soll - das ist deswegen wichtig weil der Benutzer möglicherweise nicht bereits ab dem Root-Eintrag über Zugriffsrechte verfügt.

 

Ergänzung 29.06.2010: Mittlerweile habe ich mir auch mal das Frontend-Programm für den Apache Directory Server, das Apache Directory Studio angesehen, welches natürlich auch für andere LDAP-Server genutzt werden kann. Einen direkten Vorteil zu JXplorer sehe ich eigentlich nicht, zumal Apache Directory Studio wegen des Eclipse-Backgrounds nur langsam geladen wird.

 

Zugriff durch Thunderbird

 

Nun wollte ich primär ein LDAP-Adressbuch für Thunderbird installieren. Der LDAP-Verzeichnisdienst wird in Thunderbird 3 über den Extras/Einstellungen-Dialog und dort über den Verfassen/Adressieren/LDAP-Verzeichnisserver-Eintrag festgelegt. Anschließend kann im Adressbuch der LDAP-Server durchsucht werden. Etwas gewöhnungsbedürftig ist, das erst dann Einträge erscheinen wenn oben in der Suchzeile ein Zeichen (bspw. . oder @) eingegeben wurde.

 

Die Einträge in der Datenbank, welche als Klasse inetOrgPerson zugewiesen haben, verfügen über ein Mail-Attribut. Auf dieses greift Thunderbird u. a. standardmäßig zu.

 

Nun kann man auch das Adressbuch von Thunderbird als LDIF-Datei für LDAP exportieren - dabei fällt einem u. a. auf, das das modifytimestamp-Attribut der Einträge in einem völlig falschen Format geschrieben und als übergeordneter Eintrag zudem jeweils ein mail=...-Eintrag vorausgesetzt wird. Das bedeutet genau genommen, das jeder Eintrag aus dem Adressbuch zweimal definiert werden müsste - zuerst der übergeordnete Eintrag (welcher mit der Mail-Adresse immer verschieden ist) und dann der untergeordnete Eintrag. Das ist natürlich unsinnig, wenn dann gibt es als übergeordneten Eintrag nur _einen_ Gruppen-Eintrag.

 

Im oben genannten Beispiel müsste ich also die generierte Datei mit einem Texteditor verändern und jeweils bei den dn-Zeilen ab dem mail-Attribut die folgenden Spalten durch etwas anderes ersetzen: bspw. müsste die Zeile dn: cn=Name,mail=name@gmx.de demnach durch dn: cn=Name,ou=global,ou=Adressbuch,dc=home,dc=de (auf das obige Beispiel angewandt) ersetzt werden. Die modifytimestamp-Zeilen am besten direkt löschen.

 

Beim Import wird einem dann auffallen dass die Klasse mozillaAbPersonAlpha OpenLDAP per default natürlich nicht bekannt ist. Diese Klasse wird benötigt um die erweiterten Eingabefelder des Thunderbird-Adressbuchs zu unterstützen. An der Stelle kommen die Schema-Definitionen ins Spiel, über diese können weitere Objektklassen hinzugefügt werden.

 

Die Klasse für das Mozilla-Adressbuch kann über Link heruntergeladen werden, wobei das Schema noch im älteren SCHEMA-Format vorliegt und erst ins LDIF-Format konvertiert werden muss. Wie man dabei vorgehen muss wird hier beispielhaft erklärt, wobei man schon darauf achten muss das Mozilla-Schema erst am Ende der erwähnten schema_convert.conf-Datei aufzuführen, da die Einträge aufeinander aufbauen. Sprich, man führt nicht nur das Schema auf welches konvertiert werden soll, sondern zuerst die von denen es ableitet.

 

Nach dem Konvertieren mit dem Befehl slapcat muss die erste Zeile des Schemas zu  

 

dn: cn=mozillaAbPersonAlpha,cn=schema,cn=config

 

geändert werden, die dritte Zeile dagegen zu cn: mozillaAbPersonAlpha. Anschließend kann das Schema mit

 

ldapadd -x -D "cn=admin,cn=config" -W -f /etc/ldap/schema/mozillaAbPersonAlpha.ldif

 

importiert werden. Danach am besten OpenLDAP mit /etc/init.d/slapd restart neu starten und anschließend endlich die Daten-Datei des Mozilla-Adressbuchs importieren - entweder über das Terminal mit ldapadd oder mit einem Programm wie JXplorer.

 

Ergänzung 29.06.2010: Als privaten Ersatz für Exchange, welches auf einem Windows Home Server sowieso nicht läuft und für private Zwecke auch zu teuer wäre, kann ich daher hMailServer als MailServer, OpenLDAP als globales Adressbuch (läuft mit Cygwin auch unter Windows, man könnte aber auch den Apache DS nehmen) und als gemeinsamen Kalender Sharepoint Services (wenn Ihr Outlook benutzt oder euch alternativ nicht daran stört es mit einem Webbrowser benutzen zu müssen) empfehlen.

 

Wenn Ihr Thunderbird benutzt ist eher die Kombination von OpenLDAP/ApacheDS mit dem Thunderbird-AddOn Provider for Google Calendar zu bevorzugen (Sunbird dann zuerst installieren). Ansonsten können mit Sharepoint Services natürlich auch gemeinsame Kontakte verwaltet werden, wobei SS allein noch keine (eMail-) Benachrichtigungen für anstehende Termine ermöglicht, dafür gibt es ja die Möglichkeit der Outlook-Integration... während Thunderbird SS leider nicht unterstützt, auch nicht über ein AddOn (bislang) - es wird zwar kein Fehler angezeigt wenn man den SS-Kalender in Thunderbird hinzufügt, aber es passiert auch nichts.

 

Ergänzung 23.08.2010: Ich habe eben festgestellt, das weder die Standard-Klasse inetOrgPerson noch mozillaAbPersonAlpha ein Geburtstags-Feld besitzen - seltsam, denn im Mozilla Adressbuch gibt es natürlich ein Geburtstagsfeld. Es wird einem dazu geraten die Schemata selbst zu erweitern, aber dem Schema dann auch einen neuen Namen zu geben: 1 2.

 

Es wäre aber fraglich ob Thunderbird das neue Feld dann wirklich benutzt, die Eingabefelder im Adressbuch sehen mir hartkodiert aus - dann kann man genausogut die Geburtstage in die benutzerdefinierten Felder eintragen. Ich hatte kurz überlegt das Schema bei mir zu erweitern, aber wenn es dann im Adressbuch nichtmal angezeigt wird macht es keinen Sinn.

 

Warum das Feld in der Klasse mozillaAbPersonAlpha nicht enthalten ist ist mir ehrlich gesagt ein Rätsel. Schreibe ich die Geburtstage eben in das Feld mozillaCustom1.

 

Weitere Links

 

  • Die Historie von LDAP: Link
  • Das Buch LDAP unter Linux: Link
  • OpenLDAP-Tutorial von Arne Schirmacher (altes slapd.conf-Schema): Link
  • Einrichtung von OpenLDAP (altes slapd.conf-Schema): Link
  • Das LDAP-Skripting-Tutorial: Link
  • Übersicht über verfügbare Objektklassen: Link
  • Die Fehlermeldungen von OpenLDAP: Link
  • OpenLDAP-Verzeichnis mit JXplorer bearbeiten: Link
  • Ein umfangreicher Thread im Ubuntuusers.de-Forum bezüglich OpenLDAP: Link
  • Das Thunderbird-Mail-Forum dazu ist sicher auch interessant: Link

 

Tag-Wolke

Monats-Liste