LDAP Objektklassen und Schemas

Diese Seite drucken

Schema, Objektklassen und Verzeichniseinträge

LDAP-Objekte sind standardisiert, um die Zusammenarbeit mit anderen Verzeichnisdienst-Servern zu gewährleisten.
Ein LDAP-Schema definiert die Liste möglicher Typen von Einträgen (die man als Objektklassen bezeichnet) zusammen mit den mit ihnen verknüpften Attributen. Schema-Definitionen werden in Dateien gespeichert.

Jeder LDAP-Server hat ein oder mehrere bekannte Standard-Schemas, auf das man immer zurückgreifen kann. Das heißt, dass jeder, der einen LDAP-Client programmieren will, erwarten kann, dass der LDAP-Server bestimmte Standard-Objektklassen und Attribute hat.

Beispiel: Ich durchsuche einen LDAP-Server. Das Einzige, was ich über ihn weiß, ist, dass er öffentliche Suchanfragen nach Einträgen akzeptiert, die der Objektklasse inetOrgPerson entsprechen.
Damit weiß ich schon eine ganze Menge: Ich kann nach dem vollen Namen von Personen suchen (das Attribut cn), nach dem Nachnamen (das Attribut sn); mit Hilfe optionaler Attribute kann ich eventuell Einträge über die Email-Adresse (das optionale Attribut mail) oder den Vornamen (das optionale Attribut givenname) finden. Dabei ist es egal, was für eine Implementierung der LDAP-Server ist, ob Netscape, das LDAP-Interface eines Microsoft Exchange-Servers, openLDAP, Oracles Internet Directory oder eine Sun Directory Service.

Objektklassen sind hierarchisch angeordnet, wobei die Objektklasse top die Wurzel des Baums bildet. Objekte der ersten Ebene (Level) sind Child-Objekte dieser Klasse, und alle darunterliegenden Objektklassen sind deren Nachkommen. Child-Klassen enthalten automatisch alle Attribute ihrer übergeordneten Parent-Klasse.

Ein Verzeichniseintrag kann in mehreren Objektklassen vorhanden sein, wie der folgende Datensatz für James Bond zeigt:

dn: cn=James Bond, ou=MI6, dc=gov, dc=uk
 
 
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

ou: MI6
title: Commander
street: The Enquiries Desk
postOfficeBox: 3255
st: CT
postalCode: SW1P 1AE 
facsimileTelephoneNumber: 020 7930 9000

departmentNumber: 00
employeeType: permanent
givenName: James
initials: JB
jpegPhoto: james.jpg
audio: james.wav
homePhone: 020 7930 9007
pager: Opening the toy cabinet
preferredLanguage: English
userCertificate: certs/jb_cert.pem 

Das in diesem Beispiel-Datensatz verwendete Datenformat ist als LDIF (LDAP Data Interchange Format) bekannt. Es ist als Folge von Attributen und (durch Doppelpunkte getrennten) Wertepaaren organisiert. So hat zum Beispiel das Attribut telephoneNumber den Wert 020 7930 9007. Die verschiedenen Attribute sind farblich hervorgehoben, um die Objektklasse zu zeigen, von der sie stammen.

Wo finde ich Schemas?

Der LDAP Schema Viewer stellt eine sehr praktische Schnittstelle für die Untersuchung von Standard-LDAP-Schema-Objekten zur Verfügung.

Es gibt zwei bei der IETF definierte Schemas, die in allen LDAP-Servern implementiert sein sollten: RFC 2307 'Network Information Service Schema' und draft-steinback-ldap-mailgroups-00.txt 'LDAP mailgroups Internet Draft'. Um Naming Information Service (NIS) zu unterstützen, müssen diese beiden Schemas im Directory Server existieren.

Die OpenLDAP-Distribution kommt von Haus aus mit einer Reihe von weiteren Schemaspezifikationen. Jede Spezifikation ist in einer Datei abgelegt, die mit Hilfe der include-Direktive in der slapd.conf implementiert werden kann. Diese Schema-Dateien liegen normalerweise im Verzeichnis /usr/local/etc/openldap/schema .

in OpenLDAP mitgelieferte Schema-Spezifikation	Beschreibung
core.schema	OpenLDAP core (required)
cosine.schema	Cosine and Internet X.500 (useful)
inetorgperson.schema	InetOrgPerson (useful)
misc.schema	Assorted (experimental)
nadf.schema	North American Directory Forum (FYI)
nis.schema	Network Information Services (FYI)
openldap.schema	OpenLDAP Project (experimental)

Schemas erweitern oder verändern: Warum und wie?

Eines der flexibelsten Features von LDAP ist die Tatsache, daß das Schema erweitert werden kann. Man kann Objektklassen und Attribute ganz nach Bedarf hinzufügen, um die jeweiligen Ansprüche erfüllen zu können: Wenn Sie es noch nicht getan haben, gehen Sie jetzt mal zur Website des LDAP Schema Viewer und schauen sich ein paar Schemas an - nur um mal eine Idee davon zu bekommen. Wenn man sich die verschiedenen Schemas im LDAP Schema Viewer ansieht, kann man sich vielleicht gar nicht vorstellen, warum man diese Standard-Schemas noch erweitern sollte. In der Objektklasse inetOrgPerson scheint es doch alle Attribute zu geben, die man braucht. Oder nicht?

Lassen Sie uns das an einem Beispiel aus der Realität überprüfen:
Der Systemadministrator an einer Universität X soll die Informationen aus einer Sun-NIS-Infrastruktur nach LDAP migrieren (Mehr über einen LDAP-NIS-Gateway gibt es auf der Website von PADL Software.). Dabei stellt er fest, dass es in inetOrgPerson kein Attribut für den zweiten Vornamen, Matrikelnummer und andere Namenszusätze (Mädchennamen, Adelstitel etc.) gibt. Die unter NIS vorhandenen Informationen sollen aber mitgenommen werden, und alle relevanten Personendaten zu einer Person sollen in einer einzigen Entry abgelegt werden. Was tun?
Der Systemadminstrator leitet eine neue Objektklasse aus inetOrgPerson ab; er nennt sie uniXPerson, und fügt dort die Attribute hinzu, die gebraucht werden.

Wie man an so eine Aufgabe herangeht, werden wir uns noch genauer anschauen. Soviel vorab:
Wie kommt man an ein Schema heran und wie verändert man es? Wenn der LDAP-Server LDAPv3-konform ist, kann man die Konfigurationsdateien (und dazu gehören die Schemas) manuell oder durch Programmieren und/ oder Tools ändern. Das geht deswegen so gut, weil ein Schema selbst als Entry auf dem Server abgelegt ist - man muss es nur auf eine ganz bestimmte Art und Weise abändern: Zunächst muss man sich als der Directory Server Manager authentifizieren können. Die Einstiegs-dn muss dann "cn=schema" sein, scope muss "base" und Filter auf "objectclass=subschema" . Dann können die Objektklassen oder Attribute geändert werden, wie unter LDAP mit den üblichen Operationen möglich. Das Format der Schemaeinträge ist allerdings gewöhnungsbedürftig. Ein gute Übersicht bietet der Artikel von Mark Wilcox unter http://developer.netscape.com/viewsource/index_frame.html?content=wilcox_schema.html, von dem das Beispiel stammt. Mit diesem Thema werden wir - wie gesagt - uns später noch im Detail auseinandersetzen, weil das Schema-Management auf einem LDAP-Server eine zentrale Rolle bei der Integration von LDAP in Organisationen spielt.

  Petra Haberer  Version 1.0.1