Ldif

LDIF (LDAP Data Interchange Format/Lightweight Data Interchange Format), welches zur Darstellung, und zum Austausch von Daten zwischen LDAP-Verzeichnissen und LDAP-anbindbaren Objekten (z.B. Adressbuch) dient.

Beispiel home.ldif

Durch das Erstellen einer home.ldif Datei können Dateien mit dem Befehl:

ldapadd -x -h localhost -D "cn=Manager,dc=home,dc=yehudi" -f home.ldif -W 

in die LDAP Datenbank eingelesen werden.

Die Datei muss dafür wie folgt aussehen:

# LDAP Domaine
dn: dc=home,dc=yehudi
objectClass: domain
objectClass: dcObject
dc: home

# Container für die Benutzer
dn: ou=users,dc=home,dc=yehudi
ou: users
objectClass: top
objectClass: organizationalUnit

# Container für die NT-Maschinen
dn: ou=hosts,dc=home,dc=yehudi
ou: hosts
objectClass: top
objectClass: organizationalUnit

# Container für die Gruppen
dn: ou=groups,dc=home,dc=yehudi
ou: groups
objectClass: top
objectClass: organizationalUnit

# Manager des LDAP Verzeichnis
dn: cn=manager,dc=home,dc=yehudi
objectClass: organizationalRole
cn: manager 

Achtung:

Es darf vorher keine Konfiguration mit YaST stattfinden!!!

Danke an stka

LDIF Datei in der ein User angelegt wird

Autor: ThomasF
Hier nun ein Beispiel für eine LDIF Datei in der ein User angelegt wird der sich später z.B an einem entfernten Linux Rechern (LDAP-Client) mit diesen Daten Authentifizieren können soll:

dn: uid=test,ou=users,o=meine-firma,c=de
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
sn: test
uidNumber: 26001
gidNumber: 26000
homeDirectory: /home/test
userPassword: {SSHA}MTZJJ9ldbDbYeWinQMh6u2tjr/qNnuPa
loginShell: /bin/bash
uid: test
cn: test

Suche von Attributen aus einer LDIF Datei

Autor: ThomasF
Eine Frage in diesem Bereich könnte so aussehen : Zitat: ich habe eine LDIF Datei die ich gerne in den LDAP Server eintragen möchte, leider sind da Einträge drin, die beim ldapadd nicht funktionieren. Das ist zum Beispiel : officefax

Die Problematik rund um die LDIF Dateien ist sehr umfangreich sodas ich diesem Bereich eine eigenes Thema in der LDAP Sektion dieses Forums witme.

Also hier an dieser Stelle nur sovlel, jedes Attribut das man in einer LDIF Datei bzw. in einem LDAP Verzeichnis nutzen möchte muß vorher in einer Schema-Datei ( /etc/openldap/schema ) deffiniert sein. Die jeweilige Schema Datei wiederum muß in der slapd.conf eingebunden werden (include /etc/openldap/schema/xyz.schema)

Möchte man nun ein bestimmtes Attribut nutzen begibt man sich in das Schema Verzeichnis (/etc/opnldap/schema) und durchsucht die Schema-Dateien nach diesem Attribut.

z.b : grep fax *

Das Suchergebnis sieht dann etwa so aus :

core.schema:attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
core.schema.default:attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
cosine.schema:#  This should be encoded in G3 fax as explained in recommendation T.4,
cosine.schema:  DESC 'RFC1274: photo (G3 fax)'
cosine.schema:#  a person's signature.  This should be encoded in G3 fax as explained
cosine.schema:  DESC 'RFC1274: Personal Signature (G3 fax)'
cosine.schema.default:#  This should be encoded in G3 fax as explained in recommendation T.4,
cosine.schema.default:  DESC 'RFC1274: photo (G3 fax)'
cosine.schema.default:#  a person's signature.  This should be encoded in G3 fax as explained
cosine.schema.default:  DESC 'RFC1274: Personal Signature (G3 fax)'

Wir finden also den Begriff "fax" in der core.schema und wenn wir uns diese Schema Datei mal genauer anschauen finden wir die Deffinition dazu :

attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
       DESC 'RFC2256: Facsimile (Fax) Telephone Number'
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

Fax ist in diesem Fall ein Alias für "facsimileTelephoneNumber"

Um dieses Attribut nun in LDPA nutzen zu können muß die Datei core.schema in der slapd.conf included sein und außerdem muß eine ObjectClass in der LDIF angegeben werden in der dieses Attribut vorkommen darf. Die ObjectClass wiederum finden wir wieder in der core.schema ( z.b organization, organizationalUnit, organizationalPerson ... usw)

Welche ObjectClass man verwendet ist unterschiedlich und je nach Bedarf verschieden bzw. ergibt sich aus dem Zusammenhang.

Probleme beim importieren einer LDIF Datei

Autor: ThomasF
Da dies bei vielen das Hauptproblem zu sein scheint und hier immer wieder Fragen in dieser Richtung auftauchen, hier mein Versuch die ganze Geschichte noch einmal verständlich zu machen.

Also Voraussetzung ist das man den LDAP Server (z.B Openldap) zum laufen bekommen hat. Dies bedeutet auch das man die Konfigurationsdatei des Servers (z.B /etc/openldap/slapd.conf ) nach seinen Vorstellungen abgepasst hat !!!

Weiterhin sollte man sich auch schon Gedanken über die Struktur seines LDAP Verzeichisses Gedanken gemacht haben, also welche Daten man in welcher Struktur speichern möchte.

Der erste und wichtigste Punkt den es zu beachten gilt liegt in der slapd.conf

...
suffix          "o=meine-firma,c=de"
...

Dieser Eintrag suffix ist sozusagen der wichtigste in der ganzen LDAP Konfiguration !!!

Er ist sozusagen die "Wurzel" allen Übels. ;-)

Der Suffix ist der Startpunkt, die Wurzel (/ ) an der man beginnt Daten in das LDAP Verzeichniss zu speichern oder später dann abzufragen.

Zu einem Vergleich kann man z.B eine Partition auf einer Festplatte oder die URL einer Website im Internet heranziehen.

Der Suffix oder an anderer Stelle auch basedn genannt ist immer "exakt" so zu verwenden wie er in der slapd.conf steht.

(Wenn ich in einem Browser z.B www.linus-club.de eingebe kann ich ja auch nicht erwarten auf der richtigen Site hier rauszukommen, oder ? )

Außerdem sei noch einmal erwähnt das jeder Eintrag im Verzeichniss 100% eindeutig sein muß.

Nachdem wir dies geklärt hätten und sich ja jeder schon Gedanken über die Struktur seines LDAP Verzeichnisses gemacht hat wollen wir uns einmal mit der LDIF Datei auseinandersetzen.

Ein Eintrag eines Objektes in einer LDIF Datei beginnt immer mit einem dn:.

Dieses dn (Distinguished Name) ist die vollständige Bezeichnung eines Objektes mit seiner Pfadangabe einschließlich der Basedn (Suffix) . Vergleichbar einer FQHN (Fully Qualified Host Name) bei einer Webadresse.

Der erste Eintrag in einer LDIF Datei, sofern es sich um ein leeres LDAP Verzeichniss handelt, ist der Eintrag der Basedn (Suffix) genau so wie er auch in der slapd.conf steht.

dn: o=meine-firma,c=de
objectClass: top
objectClass: organization
o: meine-firma

Da jeder bei der Planung ein wenig anders vorgeht kann es sein das dort Unterschiede auftauchen, doch das Prinzip ist immer gleich. Die erste Zeile mit dem dn: beschreibt immer den vollständigen Pfad und die Bezeichnung es neuen Objektes. Die ObjectClass top bedarf IMHO keiner weiteren Beschreibung, man könnte sie zwar auch weglassen, aber man sollte sich dennoch angewöhnen sie einfach mit reinzunehmen.

Dann wird in Abhängigkeit der Bezeichnung ( hier o= ) die ObjektClass eingebunden in der die Attribute für dieses Objekt deffiniert sind, hier also organization

(siehe /etc/openldap/schema/* und auch die "include" Anweisungen in der /etc/openldap/slapd.conf)

In der dritten Zeile nun wird das Attribut des neuen Objektes aus dem dn-Eintrag deffiniert. Auch wenn dies manchen als überflüssig erscheint, da es oben in der dn: Zeile ja schon erscheint, ist dieser Eintrag zwingend notwendig.

An dieser Stelle sei noch erwähnt das es sein kann das eine ObjectClass mehrere Attribute "verlangt" die deffiniert werden müssen. Die entsrechenden Attribute findet man entweder in der Schema Datei in der die ObjectClass deffiniert ist oder einem grafischen Fontend das die entsprechenden Attribute farbig markiert (z.B GQ).

Je nach geplanter Struktur können nun noch "Ordner" angelegt werden in denen gleichartige Objekte zusammengefasst werden. (also z.B verschiedene Abteilungen eines Unternehmens )

In unserem Beispielfall lege ich nun einen "Ordner" an in dem später User abgelegt werden sollen, die sich über LDAP an einem LINUX Rechern authentifizieren können.

# Container für die Benutzer
dn: ou=users,o=meine-firma,c=de
objectClass: top
objectClass: organizationalUnit
ou: users

Hier finden wir nun nichts überraschend neues Wink Zuerst der dn: Eintrag mit dem "kompletten" Pfad also seiner Lage im LDAP Verzeichniss. Dann die Einbindung der objectClasses die wir benötigen. Und zuletzt die Deffinition des Attributes das wir neu erstellen wollen.

Nun wollen wir auch noch einen User hinzufügen :

dn: uid=test,ou=users,o=meine-firma,c=de
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
sn: test
uidNumber: 26001
gidNumber: 26000
homeDirectory: /home/test
userPassword: {SSHA}MTZJJ9ldbDbYeWinQMh6u2tjr/qNnuPa
loginShell: /bin/bash
uid: test
cn: test

Und auch hier wieder das gleiche Prinzip wie vorher auch schon. Zuerst der dn: Eintrag, dann das Einbinden der ObjectClasses und dann die Deffinition der Attribute ... Fertig

Spätestens hier sollte man sich jedoch einmal eingehend mit den Schema Dateien auseinandersetzen Wink

Denn erstens müssen die Schema die man benötigt auch in der slapd.conf eingebunden werden (include) und zweitens hat jede ObjectClass zwei Arten von Attributen die man kennen sollte (MUST und MAY) also solche die zwingend in der LDIF Datei deffiniert sein müssen (MUST) und solche die optional (MAY) sind ....

Die objectClass: inetOrgPerson liefert in diesem Zusammenhang kein MUST Attribut, in der Deffinition der objectClass: posixAccount wird jedoch eine structural object class erwartet. Dies kann zum Beispiel person oder inetOrgPerson sein.

Falls man dies nicht beachtet bekommt man später bei dem Versuch diese LDIF Datei zu importieren folgende Fehlermeldung:

ldap_add: Object class violation (65)
       additional info: no structural object class provided

Ein weiterer Eintrag aus der slapd.conf kommt nun noch ins Spiel :

rootdn          "cn=admin,o=meine-firma,c=de"

Auch wenn für den Zugriff von der Console kein Eintrag für diesen Admin erfolderlich ist, da er ja schon in der slapd.conf steht sollte man ihn trotzdem im LDAP Verzeichniss hinzufügen.

dn: cn=admin,o=meine-firma,c=de
objectClass: top
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
userPassword: {SSHA}jslfkjslkfjretijegoi

Und auch hier wieder das gleiche Prinzip wie oben ...

Aber vielleicht ein gutes Beispiel für die Vorgehensweise bei der Suche nach ObjectClasses und Attribute Wink

Also der neue Eintrag heißt cn=admin, die Funktion ist ja wohl klar und ebenfalls das wir für dieses Objekt ein Passwort eintragen wollen. Mehr brauchen wir allerdings auch nicht wirklich.

Das heißt wir suchen ObjectClasses die die Attribute cn und userPassword liefern. Nach einer Suche in den Schema Dateien habe ich in diesem Fall diese beiden ObjectClasses gewählt, die jeweils eines der beiden Attribute mit der Bedingung MUST liefern . Je nachdem kann man sich auch anders entscheiden, es sollte aber wie gesagt auf die Abhängigkeiten geachtet werden die die ObjectClasses vorgeben.

Fehler die beim Importieren gemeldet werden haben haupsächlich Schreibfehler oder Missachtung der für die ObjectClasses deffinierten Bedingungen als Grund. Dabei gibt es einmal das Problem das als MUST deffinierte Attribute nicht gesetzt wurden oder aber Attribute verwendet wurden desen ObjectClass nicht mit aufgeführt wurde.

Deshalb sollte jeder eine gewisse Sorgfalt an den Tag legen wenn er LDIF Dateien erstellt !!!

Der vorläufig letzte Punkt ist der Import ansich wenn die LDIF Datei fertig ist. Dies geschied z.B mit dem Befehl ldapadd

Hier ein Beispiel :

ldapadd -x -D "cn=admin,o=meine-firma,c=de" -W -f base.ldif

Wie bei allen Linux-Befehlen üblich erfährt man mit ldapadd --help oder man ldapadd mehr über die möglichen Optionen dieses Befehls. Ich erwähne hier jedoch nur die verwendeten.

• -x steht für eine Verbindung zum LDAP Server ohne Verschlüsselung (SSL )
• -D steht für BindDN also der vollständige Pfad des Eintrages desjenigen der das Recht dazu hat auch Einträge in LDAP hinzuzufügen.
• -W steht für die Eingabe des Passwortes für den mit -D angegebenen Users. Das Passwort wird aber nicht wie bei -w in den Befehl geschrieben sondern nach der Eingabe des Befehls nach einer Aufforderung auf der Console.
• -f schließlich ist die LDIF Datei die importiert werden soll. Wenn sie nicht in dem Pfad liegt in dem der Befehl ausgeführt wird muss auch hier der Pfad mit angegeben werden.

Fertig ....

Ich war zwar der Meinung das zu diesem Thema sehr viel Doku im Netz zu finden ist, dennoch tauchen zu diesem Thema immer wieder Fragen auf .... merkwürdig oder nicht ?!?

Ich gebe hier noch einmal jedem der sich mit LINUX oder LDAP im speziellen beschäftigt den Rat sich ein wenig mehr in die Materie einzulesen und zu experimentieren. Die daraus resultierenden Erfahrungen sind viel sinnvoller und nachhaltiger als das zu frühe posten in ein Forum oder Mailingliste.

Ausserdem, wo bleibt denn da die persönliche Herausforderung ? ;-)

Quellen und weiterführende Links

• http://tools.ietf.org/html/rfc2849

---

zurück zu LDAP