Um einen LDAP Server für sein eigenes Netzwerk einzurichten gibt es zwei Möglichkeiten.
Die eine Möglichkeit besteht über die Commando-Zeile und Verbindung mit einer Textdatei.
Der andere Weg ist nicht nur die sichere sondern auch in die bequemere Methode.
Dafür gibt es Anwendungen mit einer GUI.
Die folgenden Tools habe ich selber getestet ( phpLDAPadmin, JXplorer, ApacheDirectory-Studio) und für mich persönlich war das Tool 'ApacheDirectory-Studio' von der Bedienung das Durchdachteste.
Angefangen habe ich mit phpLDAPadmin und meine ersten erfolgreiche Test-Strukturen erstellt. Mich störte nur, das die Anzeige der verschiedenen Schematas nicht sauber durchdacht war und bei manchen Fehlern zu wenig Hilfestellung geliefert wurde. Aber der Export und Import klappte prima. Dann entdeckte in JXplorer war in Verbindung mit phpLDAPadmin recht brauchbar, aber nicht mein Fall.
Dann entdeckte ich ApacheDirectory-Studio und wurde im ersten Moment einmal erschlagen.
Nachdem ich mein in phpLDAPAdmin erstellte LDAP-Struktur eingelesen (importiert) hatte und danach eine neue Struktur erstellt hatte, fand in das Tool einfach super. Aber wie alle Java-Programme ist die wichtigste Taste die 'F5' = Aktualisieren. Ein weiterer Pluspunkt ist, das man für den Einsatz von ApacheDirectory-Studio keine Installation braucht, entpacken und loslegen! Nur eins muss man wissen: die IP-Adresse des LDAP-Server, den Namen des Admin und das Passwort. Dazu werde ich später noch etwas sagen.
Aber jetzt erst einmal zu etwas Wichtigem, die Begriffserklärung ohne das die Strukturierung des LDAP-Server nicht recht von statten gehen kann und will.
root dse =
Root Directory Server Agent Service Entry
oder ROOT-DSA
Jeder Verzeichnisserver beinhaltet einen spezielle (einzigartigen) Eintrag. Da man in der Regel zum besseren Verständnis der gesamten Struktur Analogismen aus der Biologie verwendet, kann man hier auch getrost vom "Keimling-Samen" oder auch Wurzel sprechen.
Die 3 Buchstaben DSA stehen in der X.500-Welt für "Directory System Agent".
Angesprochen wird die Wurzel mit leerer Zeichenkette als "DN" in virtualisiebaren Systemen:
"Dies wird als eine Gruppe von Attributen in der Wurzel DSE befindet (DSA-Specific Entry), die mit der Länge Null LDAPDN Namen dargestellt. Diese Attribute sind abrufbar, wenn ein Client eine Basisobjekt der Suche nach der Wurzel mit Filter (objectclass = *) ", aber sie unterliegen der Kontrolle Einschränkungen zugreifen. Die Wurzel DSE darf nicht aufgenommen werden, wenn der Client einen Teilbaum Suche ausgehend von der root." Quelle: dapwiki.willeke.com/wiki/RootDSE
Der Server muß natürlich dem Anwender die Möglichkeit geben die Attribute zu modifizieren.
Es stehen folgende Attribute zur Verfügung:
"
- namingContexts : Namenskontexte in dem Server statt. Namenskontexte sind in Abschnitt 17 von X.501 definiert.
- subschemaSubentry : Teilschema Einträge (bzw. Untereinträge) von diesem Server bekannt.
- altServer - Die Werte für dieses Attribut sind URLs anderer (alternative) Server, der kontaktiert werden kann, wenn dieser Server nicht verfügbar ist.
- supportedExtension : Die Werte dieses Attributs sind Objekt-Identifikatoren identifiziert die unterstützten ausgedehnte Operationen, die der Server unterstützt.
- supportedControl : Die Werte dieses Attributs sind die Objekt-Identifikatoren der Bedienelemente, die der Server unterstützt.
- supportedSASLMechanisms : Die Werte dieses Attributs sind die Namen der unterstützten SASL-Mechanismen, die der Server unterstützt.
- supportedLDAPVersion : Die Werte dieses Attributs sind die Versionen des LDAP-Protokolls, die der Server implementiert.
...
Das Root-DSE ist eine spezielle Eingabe es enthält Informationen über den Inhalt und die Funktionen des Servers. Der DN ist eine leere Zeichenfolge ohne RDN Komponenten, die auch als null DN ... "
Quelle: dapwiki.willeke.com/wiki/RootDSE
Das Attribut 'namingContexts' ermöglicht vielen LDAP-Werkzeugen eine Verbindung mit Angabe des Hostname und des Kommunikations-Port aufzubauen und die gespeicherten Informationen im Baum mit Hilfe von Abfragen über die 'Basis -DN' preiszugeben.
DIT = Directory information tree
Die Gesamtheit alle Einträge (Objekte, Objects) in einer hierarchischer Struktur wird auch als Baumstruktur bezeichnet.Wobei hier zu beachten ist, das die Wurzel des Baumes oben ist und die Blätter an den Verzweigungen unter sind.Dabei gibt es Container-Objekte und Batt-Objekte.
Die Container-Objekte können als einzige Objekte wiederum andere Objekte ( Container- oder Blatt-Objekte) enthalten.
Den höchsten Punkt bzw. die Wurzelspitze bildet immer der Verzeichnis Service Eintrag auch rootDSE (DSE = Directory Service Entry) genannt.
"... Der rootDSE enthält »unsichtbare« Informationen über den LDAP-Server selbst und seine Kapabilitäten (Fähigkeiten) in Form von sogenannten operationellen Attributen (operational Attributes)..."
Da der DIT kopfüber steht, ist die höchste Ebene (Wurzel) oben und jede Objekt-Stufe nach unten ist ein Ebene tiefer.
"... Die höchste »greifbare« Ebene eines jeden DIT bildet üblicherweise die so
genannte Basis-DN oder auch BaseDN (DN = Distinguished Name), die aus min-
destens einer, oft jedoch auch zwei oder mehreren Komponenten bestehen kann.
Im vorgenannten Beispiel existieren 3 BaseDNs, die zugleich eine TLD (Top-
Level-Domain)-Komponente enthalten (hier: c=de und c=at, wobei c für country
steht). ...
firma1.de , firma2.de und firma3.at
Die Kurzform der Schreibweise erinnert an einen DNS-artigen Domainnamen,
und das aus gutem Grund, denn die Vorfahren von DNS und LDAP haben, wie
wir wissen, die gleichen Wurzeln. In der LDAP-Welt werden die DNs eines
Objektes jedoch immer voll ausgeschrieben, und zwar in der Form:
Attribut1=Attributwert(von Attribut1),Attribut2=Attributwert(von Attribut2),usw.
Bezogen auf unser Beispiel also: o=firma1,c=de
Hinweis: Unser LDAP akzeptiert zwar in der Regel Leerzeichen vor und nach den Kom-
mas eines DN (und entfernt sie normalerweise auch beim Import eines Datensatzes), sie
sollten jedoch in der Regel vermieden werden.
Die Organisation (o = organization) Firma1 beherbergt in diesem Beispiel wiederum untergeordnete organisationelle Einheiten, sogennante ou’s, oder auch
organizationalUnits, die wiederum in der Regel Container für weitere Objekte
bilden (üblicherweise User oder Drucker einer bestimmten Abteilung, shares, weitere ou’s oder sonstige Objekte).
Bezogen auf das kleinste, greifbare bzw. nicht weiter zerlegbare Objekt innerhalb eines Trees (üblicherweise ein User-Objekt wie »user1« in unserem Beispiel), stellt sich ein komplett ausgeschriebener DN wie folgt dar:
uid=user1,ou=verkauf,o=firma1,c=de
Wie wir unschwer erkennen können, wird der DN eines Objektes immer ausgehend vom Objekt selbst (z.B. dem User: uid=user1) hin zur BaseDN gelesen und geschrieben. Dieser DN schlüsselt sich wie folgt auf: Das Userobjekt mit der uid (userID) user1 liegt in der organizationalUnit (ou) verkauf, welche der BaseDN o=firma1,c=de untergeordnet ist.
Diese an den äußersten Enden des Baumes gelagerten Objekte werden auch oft als Blatt- oder Leaf-Objekte bezeichnet. Vereinfacht kann man auch sagen, dass der DN eines Objekts immer vom Blatt zur Wurzel (rootDSE) gelesen und geschrieben wird.
Wir wissen also nun, dass jedes Objekt innerhalb eines Trees durch seinen vollständigen DN definiert wird. Der DN ist in der LDAP-Terminologie damit am ehesten mit einem indizierten Datenbankfeld einer relationalen Datenbank vergleichbar, das nur genau einmal pro Datenbank vorkommen und keine Dubletten haben darf.
Die DNs aller Objekte innerhalb des DIT erzeugen eine hierarchische, baumartige
Struktur. Teile von DNs werden als Relative Distinguished Names (RDNs) bezeichnet. So lässt sich der DN: ou=verkauf,o=firma1,c=de durch Hinzufügen des RDN uid=user1 zum vollen DN des Users konstruieren..." ( entnommen aus OpenLDAP 2.4 von Oliver Liebel)
OIDs = Object Identifiers
Das OID ist eine Zahlenkette, die aus Ziffern und Punkten besteht.
Der Aufbau der Struktur ist hierarchisch, ähnlich der Vergabe von Kapitelnummern in einer Dissertation (besser noch ist das System vergleichbar mit der Organisation der Gesetzestexte). Mit der Kapitelnummer ist natürlich auch eine Überschrift fest verbunden unter der der Anwender die gewünschte Information ansprechen kann.
Im Gegensatz zur Ansprache über den Namen ist die OID-Nummer immer eindeutig.
Die OID wird von einem Konsortiums vergeben, damit keine Konflikte entstehen, da ein LDAP Server in der Regel öffentlich seine Informationen zum Besten gibt.
Anmerkung:
Will man seinen LDAP-Server nicht öffentlich stellen, so ist man diesem Reglement nicht oder zu mindestens nur teilweise unterlegen und kann so ein eigenes 'schemata' entwerfen.
Will man mit einem eigenen Schema arbeiten soll sollte man zur Sicherheit eine OID zuweisen lassen. Dafür wenden Sie sich an 'iana' = 'internet assigned numbers authority'.
z.B.: das NIS Schema
NAME 'loginShell'
OID Nr -> attributetype 1.3.6.1.1.1.1.4
OID Bedeutung
1. Durch die ISO zugewiesen
1.3.6.1 Der Internet OID
1.3.6.1.1.1 RFC2307 NIS Netgroup
1.3.6.1.1.1.1 NISSchema Syntax
1.3.6.1.1.1.1.4 loginShell im NIS Schema
Ps:
Auch meine Kapitelbeschriftung basiert auf dem System!
C = Country
Der Buchstabe 'C' steht für das Objekt des Ländercodes.
z.B.: Deutschland (Germany) c=de
In der Regel wird zwar der Ländercode verwendet, aber in der heutigen Zeit haben sich für die TLD (Top Level Domain) begriffliche Sinnabkürzungen eingebürgert und führen so zu einer Aufweichung von der Bedeutung 'c' als Ländercode.
O = oranisation
Der Buchstabe 'O' steht für das Objekt des Namen oder der der Bezeichnung einer Organisation oder Firma oder einer sonstigen Vereingung.
z.B.: o=uvrnc oder o=cdu oder o=ms oder o=krebshilfe
OU = Organisation Unit
Die OU, auch Organisationseinheit genannt, ist ein Container für unterschiedlichste Objekte. Das kann wie im oben gezeigten Beispiel eine Gruppierung von Personen sein, kann aber auch jeder andere logisch zusammenfassbare Gruppierung von Objekten beinhalten.
Eine OU kann selber wiederum eine oder mehrere Organisationseinheiten (OUs) enthalten.
Die OU wird meistens dazu verwendet die Organisationsstruktur eines Unternehmens oder Firma oder sonstiger Gruppierung wiederzugeben.
DC = Domain COmponent
Der DC , auch 'domain code' spiegelt die IT-Technische Struktur wieder. D.h. man ist in der Lage recht komplexe, verschachtelte Domänen-Strukturen (DNS-Strukturen sind gemeint, bitte nicht mit der Mircosoft-Domäne verwechseln!) einfach und sauber strukturiert wiederzugeben.
z.B.: dc=uvrnc, dc=lemptal, dc=hessen, dc=de
Für Objekte unterhalb der Top Level Domain bzw. BaseDN kommt normalerweise die OrganizationalUnit (OU) zu Verwendung. Die OU beinhaltet, wie oben schon besprochen, als typisches
Container-Objekt weitere untergeordnete Objekte.
CN = Comman Name
Die Buchstabenkombination 'CN' steht für einen allgemeinen Objektnamen, der nur unterhalb der TLD oder BaseDN (RootDSE) auftreten kann und keine Verzweigungen auf untergeordnete Objekte (OU's) beinhaltet. Der Objekt-Container 'CN' beinhaltet nur Objektattribute, die normaler Weise mit dem Namen 'cn' = 'common name' oder in Anlehnung an die Biologie mit dem Synonym eines 'Blattes' verglichen werden kann.
Hier geht es weiter: [1.5] [1.5.2]
Wichtige Links:
Links:
dapwiki.willeke.com/wiki/RootDSE
http://www.effinger.org/blog/wp-content/uploads/2008/12/ldap-grundlagen.pdf
Bücher:
1. OpenLDAP 2.4 von Oliver Liebel, John Martin Ungar im GalileoPress Verlag nur als PDF!
2. LDAP unter Linux von Jens Banning im Addison-Wesley Verlag gibt offiziell nicht mehr(rebuy,amazon oder ebay)!
3. openLDAP Verzeichnisdienst pdf
4. LDAP für Java-Entwickler von Stefan Zörner (4. Auflage Verlag: entwickler.press)