Unentbehrliches Netzwerk-Know-how (tecCHANNEL COMPACT)
LDAP, Teil 2
LDAP-Modelle repräsentieren die Dienste, wie sie über den Server bereitgestellt und vom Client gesehen werden. RFC 2251 teilt ein LDAP-Verzeichnis in zwei Komponenten: das Protokoll- und das Datenmodell.
Auf dieser Seite
In zahlreichen Literaturquellen ist allerdings die Rede von vier Modellen: FunktionsmodellDieses Modell beschreibt die Operationen, die Sie auf den Daten ausführen können, wie etwa
InformationsmodellDieses Modell beschreibt, was in einem Verzeichnis abgelegt werden kann. Jeder Eintrag hat einen ausgezeichneten Namen (Distinguished Name, DN) und jeder Eintrag besitzt eine Menge von Attributen, die einen Typ und einen bzw. mehrere Werte haben. Eine besondere Bedeutung haben hierbei die Schemata. Sie beschreiben, in welcher Weise Objekte in Verbindung zueinander stehen (Ober- und Unterklasse) und an welcher Stelle in der DIT-Hierarchie sie auftauchen. Außerdem bestimmen sie, ob Attribute Werte enthalten müssen oder ob sie leer bleiben können. Es ist zwar möglich, dass jeder Server seine eigenen Schemata entwickelt, aber Ziel sollte es sein, dass sich Standards bilden, die zu einer Vereinheitlichung führen. NamensmodellDieses Modell beschreibt, wie Daten angeordnet und angesprochen werden können. Jeder ausgezeichnete Name (DN) besteht aus einer Sequenz von Teilen, so genannte relative ausgezeichnete Namen (Relative Distinguished Name, RDN). Die Einträge eines Verzeichnisses sind in einer hierarchischen Baumstruktur angeordnet (Directory Information Tree, DIT). DIT erlaubt auch Aliase. Aliaseinträge (Verknüpfungen) ermöglichen einen Eintrag an mehreren Stellen im Verzeichnisbaum. Trotzdem muss dieser Eintrag nur an einer Stelle gepflegt werden. Ein DIT kann auch über mehrere Server verteilt sein. Verweise auf Einträge anderer LDAP-Server erfolgen über LDAP-URLs. Da nicht jeder LDAP-Server alle Einträge speichert, ist es nicht nötig, dass der komplette DIT hinterlegt wird. Es ist möglich, dass der DIT auf verschiedene Server aufgeteilt wird. Dadurch werden nur Teilbäume abgebildet, die z.B. die Wurzel nicht abbilden, sondern erst einige Ebenen tiefer aufsetzen. Die oberste Ebene wird als Suffix bezeichnet. Ein Server kann auch verschiedene Bereiche des DIT abbilden, wodurch auf einem Server mehrere Suffixe (Multiple Suffixes) gespeichert werden können. Um nun aber auf alle Bereiche des DIT zugreifen zu können, müssen die Server Verweise auf andere Server enthalten. Dies wird dadurch realisiert, dass ein Eintrag, an dem der DIT endet, auf ein Suffix eines anderen Servers verweist. Dieser Eintrag wird als Referral bezeichnet. SicherheitsmodellDieses Modell beschreibt, wie ein Verzeichnis geschützt werden kann. Da innerhalb von Netzwerken große Mengen von sensiblen Daten verschickt werden, ist der Schutz dieser Daten von wesentlicher Bedeutung. Da insbesondere bei Verzeichnisdiensten viele Personen auf die Daten zugreifen können, muss eine solche Sicherheit gewährleistet werden. Das Problem lässt sich in vier Aspekte unterteilen:
Um die Unterschiede zu den normalen relationalen Datenbanken deutlich zu machen, wird eine andere Terminologie verwendet, um die Datenstrukturen eines Verzeichnisdienstes zu benennen: Records (also Datensätze) werden als Einträge (Entries) bezeichnet und jedes Feld innerhalb eines Records wird Attribut genannt. LDAP definiert den Nachrichtenaustausch, der zwischen dem LDAP-Client und dem LDAP-Server stattfindet. Die Nachrichten, die übermittelt werden, spezifizieren die Operationen, die der Client (Anwender) vornehmen möchte. Außerdem wird die Antwort des Servers übermittelt. Die Nachrichtenübermittlung erfolgt über das TCP/IP-Protokoll, bei dem es sich um ein verbindungsorientiertes Protokoll handelt. Um solche Verbindungen nutzen zu können, muss LDAP über Operationen verfügen, die Sessions (Sitzungen) zwischen Client und Server öffnen und beenden können. Von besonderem Interesse für ein LDAP-Verzeichnis ist das logische Modell, welches hinter dem Verzeichnis steht. Von Bedeutung ist hierbei die Organisation des Verzeichnisses und das Sicherheitskonzept.Im Folgenden wird die grundsätzliche Interaktion zwischen LDAP-Client und Server dargestellt:
Damit Applikationen leichter mit LDAP-Servern kommunizieren können, wurde ein Interface entwickelt. Dieses Interface wird als LDAP API (Application Program Interface) bezeichnet. SchemaLDAP-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 (Objektklassen) zusammen mit den mit ihnen verknüpften Attributen (siehe Abbildung).  Schema: Eine in einem Schema verwendete Objektklasse. Ein Schema stellt also eine Sammlung von Strukturdefinitionen (Metadaten) dar.
Dazu gehören die Beschreibungen der Klassen und der verwendeten Typen. Es gibt verschiedene Schemata und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) LDAPv3 beinhaltet das Konzept des Schema-Discovery. So ist ein Client in der Lage zu überprüfen, welche Objektklassen, Attribute und Syntaxen der LDAP-Server kennt. Jeder LDAP-Server besitzt ein oder mehrere bekannte Standard-Schemata, auf das man immer zurückgreifen kann. Das heißt, dass jeder, der einen LDAP-Client programmieren will, erwarten kann, dass der LDAP-Server auf bestimmten Standard-Objektklassen und Attributen fußt. Ein Verzeichniseintrag kann in mehreren Objektklassen vorhanden sein. Der LDAP Schema Viewer (z.B. über http://ldap.akbkhome.com/index.php oder http://www.ldapbrowsers.com zu beziehen) stellt eine sehr praktische Schnittstelle für die Untersuchung von Standard-LDAP-Schema-Objekten zur Verfügung. Eines der flexibelsten Features von LDAP ist die Tatsache, dass ein Schema erweitert werden kann. Man kann Objektklassen und Attribute ganz nach Bedarf hinzufügen, um die jeweiligen Ansprüche erfüllen zu können.  Schema: Verwendung eines LDAP Viewer. Objekt-IDs (OIDs)Jedes Schema-Element (Attributtypen, Objektklassen, Regeln (Syntax), Matching Rules usw.) besitzt eine weltweit eindeutige Nummer, mit der es identifiziert werden kann – die OID. Dies ist neben einem mehr oder minder sprechenden Namen die zweite Möglichkeit, ein in einem Schema definiertes Objekt zu referenzieren. Eine Objektkennung (OID) ist eine Zahl, die eine Objektklasse oder ein Attribut in einem Verzeichnisdienst eindeutig kennzeichnet. OIDs werden von Herausgabeinstanzen ausgestellt und bilden eine Hierarchie. Eine OID wird als Zeichenfolge in punktierter Dezimalschreibweise (beispielsweise 1.2.3.4) dargestellt (siehe Abbildung). Organisationen (und Einzelpersonen) können von einer Herausgabeinstanz eine Stamm-OID erhalten und unter Verwendung dieser Stamm-OID weitere OIDs reservieren. Möchten Sie eigene Objekte für LDAP definieren, benötigen Sie einen Object Identifier (OID). Die Verwendung von OIDs ist also nicht auf einen Verzeichnisdienst beschränkt, sondern bei ASN.1-basierten Protokollen verbreitet. Die Vergabe läuft über die IANA (http://www.iana.org/). Auf der Website des LDAP Schema Viewers haben Sie die Möglichkeit, einige Standard-Schemata zu betrachten.  Aufgeteilt: Darstellung von Objektklassen nach OIDs. Attributtypen# attributetype definition telephoneNumber
# basierend auf RFC 2256
attributetype
(2.5.4.20 NAME ‘telephoneNumber’
DESC “Telefonnummer”
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumerSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32})Die Definition eines Attributtypen beinhaltet u.a. Namen (telephoneNumber), OID (2.5.4.20), Beschreibung (DESC), Angabe, ob Mehrfachwerte für dieses Attribut zugelassen sind (SINGLE-VALUE, in diesem Beispiel nicht gegeben), Attributsyntax (SYNTAX), Matching Rules (Treffer-Regeln) für die Gleichheit (EQUALITY) und die Gleichheit von Teilzeichenketten (SUBSTR) sowie Längenbeschränkung (Angabe in geschweiften Klammern hinter der Syntaxangabe).  Detailansicht: Attributtypen im LDAP Viewer.  Struktur: Einträge und Attribute. RFC 2252 realisiert die Definition von Attributtypen mithilfe der Backus-Naur-Form-(BNF-)Grammatik, die als eine Beschreibungssprache für Syntaxregeln fungiert. Dies sieht dann (ein wenig kryptisch) so aus: AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
AttributeUsage =
"userApplications" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific, value depends on serverDabei ist whsp ein Leerzeichen (' '), numericoid eine globale eindeutige OID in numerischer Form (z.B. 1.2.3), qdescrs ein oder mehrere Namen, woid entweder ein Name oder OID und noidlen ein optionales Längenspezifikationssymbol (z.B. {10}). ObjektklassenDie objectclasses-Direktive dient dem Definieren einer neuen Objektklasse.  Klassenübersicht: Objektklassen im LDAP Viewer. Diese Direktive verwendet die gleiche Objektklassenbeschreibung (wie in RFC 2252 beschrieben) wie im objectClasses-Attribut, welche im subschema subentry gefunden wird, z.B.: objectclass <RFC2252 Object Class Description>  Im Beispiel: Die Objektklasse inetOrgPerson. Dabei wird die Objektklassenbeschreibung von dem folgenden BNF definiert: ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
; default structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
Objectclass (2.16.840.1.113730.3.2.2
NAME ‚inetOrgPerson’
DESC ‘RFC 2798: Internet Organizational Person’
SUP organizationalPerson
STRUCTURAL
MAY(
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $
roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12)
)Die meisten Elemente dieser Objektklassendefinition kennen Sie bereits von der Attributklassendefinition. Die Elemente einer solchen Objektklasse bestehen aus Name, OID, Liste von Attributtypen (MUST), Liste von optionalen Attributen (MAY), Art der Objektklasse (hier: structural), Verweis auf die „Superklasse“ (hier: organizationalPerson). Von dieser Klasse werden Attribute übernommen (siehe Abbildung).  Vererbung: Ableitung von Klassen. Objektklassen lassen sich in folgende Typen unterteilen:
Aggregation und Federation/Referral: Aggregation beschreibt das Sammeln von Objekten und Attributen in einer einzigen Quelle. Federation stellen Verweise und Umleitungen auf Originalverzeichnisse dar, wenn die gesuchten Informationen nicht im Verzeichnis gefunden werden. LDIFZum Datenaustausch mit dem LDAP-Verzeichnis können u.a. LDIF-Dateien benutzt werden. LDIF steht für LDAP Data Interchange Format. Diese Dateien sind ASCII-Dateien. Das Format wird durch RFC 2849 definiert und ist ein Standardformat für Textdateien, um LDAP-Konfigurationsinformationen und Verzeichnisinhalte aufzunehmen. Um ihren Inhalt in ein Verzeichnis übertragen zu können (z.B. unter Zuhilfenahme des Tools ldapmodify), müssen spezielle Formatierungsregeln eingehalten werden. Zum Beispiel ist die Verwendung von Leer- und Tabulatorzeichen genau geregelt. Durch diese Regelungen können Daten im Verzeichnis gefunden, bearbeitet und wieder zurück in das Verzeichnis übertragen werden. Außerdem können Objekte von einem Punkt im Verzeichnis an einen anderen kopiert bzw. verschoben werden. In seiner Grundform ist eine LDIF-Datei:
Um ein Objekt zu definieren und zu beschreiben, müssen in der LDIF-Datei folgende syntaktische Regeln eingehalten werden: [<Kennung>] dn: <Distinguished Name> <Attribut>: <Wert> <Attribut>: <Wert> <Attribut>: <Wert> <...> : <...> Ein Objekt in der Datenbank besitzt immer eine eindeutige ID. Als Erstes haben Sie die Möglichkeit, eine Kennung für das Objekt anzugeben. Dies ist jedoch in der Praxis eher selten. In der nächsten Zeile wird der „Distinguished Name” des Objektes angegeben (Bsp.: dn: dc=act,dc=de). In den weiteren Zeilen werden die Attribute des Objektes definiert (Bsp.: objectclass: organization). Wenn Sie eine Datei mit mehreren Objekten erstellen, ist darauf zu achten, dass diese durch eine Leerzeile voneinander getrennt sind. In der Regel bestehen die Attributwerte aus druckbaren Zeichen, jedoch kann es auch vorkommen, dass binäre Daten abgelegt werden sollen. # LDIF Eintrag fuer dn: dc=act,dc=de dn: dc=act,dc=de objectClass: domain dc= act Bei dem Erstellen von Dateien im LDIF-Format ist auf folgende Punkte zu achten (siehe Abbildung):
 Textbasiert: Beispiel einer LDIF-Datei.
LDAP-URLs (RFC 1959):<ldapurl> ::= "ldap://" [ <hostport> ] "/" <dn> [ "?" <attributes> [ "?" <scope> "?" <filter> ] ] <hostport> ::= <hostname> [ ":" <portnumber> ] <dn> ::= a string as defined in RFC 1485 <attributes> ::= NULL | <attributelist> <attributelist> ::= <attributetype> | <attributetype> [ "," <attributelist> ] <attributetype> ::= a string as defined in RFC 1777 <scope> ::= "base" | "one" | "sub" <filter> ::= a string as defined in RFC 1558 LDAP-URLs definieren einen Standard, um sich auf Ressourcen im Internet bzw. Intranet zu beziehen. Sie werden u.a. in Verweisen (Referrals) verwendet, wie sie bei partitionierten Verzeichnissen vorkommen. Weiterhin dienen sie zur Angabe von Standardverweisen (References) auf übergeordnete Verzeichnisserver, falls eine Anfrage im lokalen Namensraum nicht erfüllt werden kann.  Abgefragt: Ergebnis eines LDAP-Aufrufs im Browser. LDAP-URLs finden auch Verwendung als Lesezeichen (Bookmarks). So ist es z.B. möglich, eine stets aktuelle E-Mailverteilerliste zu bekommen, indem eine Mailanwendung nicht die Empfänger der Liste, sondern eine Suchanfrage in Form einer LDAP-URL speichert und bei Bedarf diese Anfrage ausführt, um die einzelnen Empfänger zu ermitteln. ldap[s]://[<host>:[<port>]][/[<searchbase>[?[<attributes>][?[<scope>][?[<filter>][?<extensions>]]]]]] URL = "ldap://ldap.act-site.de/pfad/default.asp" Die URL beginnt mit der Spezifikation des Protokolls: ldap für normale, ungesicherte Verbindungen bzw. ldaps für gesicherte, verschlüsselte Verbindungen, z.B. über SSL. Es folgt der Host-Name des LDAP Servers und optional der Port. Die Standards sehen Portnummer 389 für ldap bzw. 636 für ldaps vor. Die Angabe der Suchbasis ist trotz der eckigen Klammern, die optionale Teile kennzeichnen, bei den meisten LDAP-Servern nötig, um Ergebnisse zu erhalten. Die restlichen Argumente sind optional, wobei bei Auslassungen von Parametern die entsprechenden Fragezeichen zur Wahrung der Eindeutigkeit trotzdem anzugeben sind. Wird also z.B. die Angabe der Attribute und des Suchraumes (scope) ausgelassen und ein Filter angegeben, müssen drei Fragezeichen in Folge zwischen der Suchbasis (searchbase) und dem Filter angegeben werden. Mit freundlicher Genehmigung von www.addison-wesley.de
|
In diesem Beitrag
|
