OpenLDAP
 |
Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist. |
Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.
Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.
Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt, da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.
Inhaltsverzeichnis
Theorie
LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.
Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.
Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.
Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.
Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar. Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....
Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet. Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.
Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.
Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.
Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.
Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.
Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst. Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.
Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.
Hinweis :
Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.
Beispiele für Containerobjekte :
c : Country o : Organization ou : Organizational Unit
Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.
In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen. Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.
Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.
Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.
Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.
Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann
Beispiele für Blattobjekte :
cn : Common Name uid: UserID ...
Beispiele für Attribute:
userPassword homeDirectory loginShell telephoneNumber ...
Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können. Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.
Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.
Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.
Planung
Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut, also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.
Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.
Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.
Hinweis :
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen und dann bei dieser auch bleiben !!! Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt. Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!
Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht. In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)
Besser passt in diesem Fall der Vergleich mit einer Internet-Domain. Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.
Gut, also das Root-Objekt hat also in unserem Beispiel die Form :
dn: o=meineFirma, c=de
Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de
dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt. Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.
Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht, ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten. Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.
Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen. Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen. Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.
Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".
Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?
Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand. Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn, sodass wir hier diesen Fall nicht berücksichtigen.
Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.
Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :
ou = Users ou = Groups ou = Workstations
Aufsetzen eines Openldap-Servers
Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen) kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.
Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.
Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.
Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.
Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.
Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.
Wichtig:
Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)
Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!! Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.
Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.
Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.
Wichtig : Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.
Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :
core.schema cosine.schema nis.schema inetorgperson.schema samba.schema (oder samba3.schema) misc.schema
Ein Beispiel für die slapd.conf wäre nun:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema
Hinweis : Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.
Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.
Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix" Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen. Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :
suffix "o=meineFirma, c=de"
sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.
Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"
Bitte beachten : Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.
Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :
rootdn "cn=admin, o=meineFirma, c=de"
Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.
Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.
Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd
Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.
Code:
slappasswd >> passwort.txt
Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :
{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C
Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.
Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!! Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!
Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :
rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C
nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.
Code:
rcldap start
Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.
Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )
Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.
Auch kann man mit : Code:
nmap localhost
testen ob der Port 389 in Benutzung ist.
Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client ) kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.
Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten. Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )
Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:
Code:
ldapsearch -x -h localhost -b o=meineFirma,c=de ... bzw. ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W
Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.
