OpenLDAP
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.
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
