LDAP - die neue Auskunft

Überblick über das Chaos

von Peter Wächtler

Heutige Rechner-Infrastrukturen werden immer umfangreicher und somit komplizierter. Nicht nur im Internet verlieren sich die Informationen, die unstrukturiert ins Web gestellt werden. Auch in Unternehmensnetzen drohen Informationen verloren zu gehen, da sie entweder nicht mehr aufgefunden werden oder niemand mehr weiß, daß sie existieren. Fragen wie: "Welches ist der nächstgelegene Drucker?" oder "Wie lautet die Email-Adresse des Projektleiters?" möchten einfach und schnell beantwortet werden. Zeit für ein entsprechendes Auskunftssystem!

Die Anforderung ist alles andere als neu. Notwendige Informationen müssen für einen schnellen und leichten Zugriff katalogisiert werden. Was nützen mir dutzende Handwerker in der Stadt, wenn ich keinen finde? Seit langem existieren die "Yellow Pages" für Unix-Netze: das Network Information System (NIS) von Sun Microsystems. NIS katalogisiert Metadaten, wie Benutzer-, Netzwerk- und Dienstezuordnungen, ist aber auf Unix Systeme beschränkt, skaliert aufgrund seiner "flachen" Struktur eher schlecht und hat erhebliche Sicherheitsmängel, die heutigen Ansprüchen widersprechen.

Um solche Ressourcen schnell und sicher finden, verwalten und nutzen zu können ,wird ein Verzeichnis benötigt, in dem alle relevanten Informationen gehalten werden. Mehrere solcher Verzeichnisdienste existieren bereits: Novells NDS, Microsofts NTDS, Banyans StreetTalk oder OSI's X.500.

X.500 wurde 1988 von der CCITT spezifiziert als "eine Menge offener Systeme, die gemeinsam eine Datenbank halten, in der Informationen über Objekte der realen Welt abgelegt sind". Die CCITT spezifiziert im wesentlichen drei Protokolle: DAP (Directory Access Protocol), das zum Zugriff auf die Informationen dient, DSP (Directory Service Protocol), mit dem die Kommunikation zwischen Servern durchgeführt wird, und DISP (Directory Information Shadowing Protocol). Allerdings setzt X.500 auf einem vollständigen ISO/OSI-Stack auf, was einen durchschlagenden Erfolg unmöglich machte.

X.500 kann als vollständig bezeichnet werden: Nichts, was nicht in ihm gespeichert werden könnte. Das Verzeichnis stellt eine Objektdatenbank dar. Zu speichernde Informationen werden in Objektklassen beschrieben: Attributnamen, Typen und deren Wertebereich. Wesentliche Nachteile sind der hohe Implementationsaufwand und der "schwergewichtige" Zugriff: die Kommunikation zwischen Client und Server erzeugt eine recht hohe Netzlast, die einer allgegenwärtigen Nutzung hinderlich ist - denn schließlich spielt ein Verzeichnisdienst erst mit der allgemeinen Verwendung seine Stärken aus. LDAP schlägt eine Brücke.

Im Jahr 1995 wurde von Yeong, Howes und Kille an der Universität von Michigan LDAP (Lightweight DAP) spezifiziert, um "einen Teil der Last des Verzeichniszugriffs vom Client zu nehmen und die Verbreitung von Verzeichnisdiensten zu vergrößern". LDAP bietet einen vollen Verzeichniszugriff über einen TCP/IP-Stack und vereinfacht so den Zugriff auf ein X.500-Verzeichnis. Es wurde nur ein Teil der DAP-Funktionen übernommen, allerdings reichen die vorhandenen vollständig aus, um den Rest zu emulieren.

Ursprünglich sollte LDAP nur als Mittler zwischen IP-Clients und einem OSI-X.500 Server dienen. Der ldapd aus dem Paket der University of Michigan [1] bildet diese Funktionalität ab. Inzwischen wurde auch ein "standalone" Server implementiert - der slapd; dieser speichert die Objektinformationen selbst, wodurch die Notwendigkeit eines X.500 Servers entfällt. Für eine bessere Skalierbarkeit und Verfügbarkeit ist auch die Replikation solcher standalone Server vorgesehen - dies setzt der slurpd um.

Wofür noch 'ne Liste?

Was verspricht man sich nun von LDAP? Wie eingangs erwähnt, gibt es ja bereits eine erkleckliche Anzahl von Verzeichnisdiensten. Warum also noch einen? LDAP bildet selbst keinen Verzeichnisdienst - wird aber als "heisser" Kandidat gehandelt, mit dem eine Integration der unterschiedlichen proprietären Verzeichnisdienste gelingen könnte. Alle relevanten Hersteller haben auch bereits eine Unterstützung von LDAP zu ihrem Verzeichnis angekündigt oder bieten sie bereits an. So wie sich IP als Netzprotokoll durchgesetzt hat, wird mit LDAP eine einheitliche Möglichkeit geschaffen auf Verzeichnisse zuzugreifen.

Der Mehrwert beschränkt sich aber nicht nur auf die Interoperabilität zwischen verschiedenen Verzeichnissen und dem Abbild von Benutzerinformationen in einem Unternehmen. Denkbar, und bereits in RFC 2307 vorgesehen, ist die Speicherung folgender Einträge um einen Netzwerk-Informationsdienst zu bilden:

Benutzer [/etc/passwd],
Gruppen [/etc/group],
IP Dienste (Zuordnung zwischen Namen zu Portnummern und umgekehrt [/etc/services]),
IP Protokolle ([/etc/protocols]),
RPCs (Zuordnung von Remote Procedure Call-Nummern [/etc/rpc]),
NIS Netzwerkgruppen,
Boot-Informationen (Boot Parameter und MAC-Adresszuordnungen),
Einhängepunkte für Dateisysteme,
IP Hosts und Netzwerke oder auch
RFC822 konforme Mail-Aliase.

Aber es ist mehr möglich: durch Integration von LDAP als "Namensdienstleister" in Anmeldediensten ist auch ein "single-sign-on" in heterogenen Umgebungen denkbar: ein Username/Paßwort-Paar regelt den Zugriff auf sämtliche Resourcen im Netz! Weitere Zukunftsmelodien sind ein WWW-Katalog oder ein weltweites Branchenbuch.

Login über LDAP

Das login bezieht seine Informationen aus den Dateien /etc/passwd und /etc/shadow um einen Benutzer zu authentifizieren. Die Namen und Paßwörter müßten also von einen LDAP-Server bezogen werden. Damit auch ohne funktionierende Netzanbindung ein lokales Anmelden möglich bleibt - zumindest einer lokalen Administratorkennung, muß mindestens eine Alternative für die Authentifizierung vorgesehen sein. Dies erinnert an die Lösung in der Resolver-Funktionsgruppe in der Standard-C-Bibliothek (gethostbyname und Konsorten). Hier wird über Einträge in der Konfigurationsdatei /etc/hosts.conf die Reihenfolge bestimmt, in der die Dienste für die Namensauflösung zu benutzen sind (order hosts,bind oder umgekehrt).

Um die Dienstprogramme von der Methode zur Namensauflösung unabhängig zu machen, entwickelte Sun Microsystems den "Solaris Nameserver Switch". Über diesen Mechanismus läßt sich ohne Neuübersetzung oder Austauch von Programmdateien zwischen verschiedenen Arten der Namensauflösung umschalten. Abbildung 1 zeigt eine Konfiguration, die die Namensauflösung in der vorgegebenen Reihenfolge versucht. Der NSS-Mechanismus ist in der GNU libc2 (aka libc.so.6) integriert. Ein entsprechendes Modul für die Namensauflösung mittels LDAP ist unter [2] zu finden.

Abb. 1: NSS-Konfiguration (/etc/nsswitch.conf)

passwd: files nis ldap group: files nis ldap

Authentifizierung über PAM

Wer den Wechsel auf die Benutzung von shadow-Paßwörtern zur Authentifizierung mitgemacht hat, kennt die Situation: ohne abstrakte Zwischenschicht mit wohldefinierter Schnittstelle ist eine Anpassung der login-Programme (xdm, xlock, login, ftpd, pop3d etc.) auf Quellcode-Niveau unumgänglich. Die Änderungen sind zwar minimal ausgefallen - um den Austausch der Programmdateien führte aber kein Weg vorbei. Auch hier hat SunSoft mit der Entwicklung von PAM - den Pluggable Authentication Modules - Abhilfe geschaffen, um eine Unabhängigkeit von den sich weiterentwickelnden Authentifizierungsmethoden zu erlangen. Hier können die Anforderungen für ein erfolgreiches Login über eine Konfigurationsdatei gesteuert werden - ein Beispiel zeigt Abbildung 2. Die angegebenen dynamischen Bibliotheken werden zur Laufzeit in den Adressraum des Authentifizierungsprogrammes geladen. Sie bilden Module deren Implementation nicht bekannt sein muß. In dem konkreten Beispiel wird zuerst geprüft, ob die Verbindung von einem erlaubten Terminal erfolgt. Dann werden mit dem unter [3] erhältlichen PAM-Modul Username und Paßwort an einer NT-Domäne verifiziert. War das erfolgreich, wird noch geprüft, ob überhaupt eine Anmeldung zum derzeitigen Zeitpunkt erlaubt ist.

Abb. 2: PAM-Konfiguration (/etc/pam.d/login)

#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_smb_auth.so auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow nullok use_authtok session required /lib/security/pam_pwdb.so

Mit PAM ist es möglich unterschiedliche Methoden zur Authentifizierung zu nutzen oder zu kombinieren. Die Methoden müssen Zugriff auf die Benutzerdaten haben und können sich des NSS-Mechanismus bedienen, um ihre Informationen zu erhalten. Diese Architektur ist sehr flexibel und wird hoffentlich bald in allen Linux-Distributionen zu finden sein.

Aufbau des Verzeichnisses

LDAP ist als Zugriffsprotokoll auf X.500-Verzeichnisse entworfen worden. Seine Spezifikation beruht auf der Nomenklatur von X.500. Durch Gateways ist es aber nicht mehr auf diesen einen Verzeichnisdienst festgelegt. Die Einträge sind als Objekte verpackt. Sie bestehen aus Attributen mit Typen und Werten und sind in einem hierarchischen Baum strukturiert - wie ihn Abbildung 3 zeigt. Objektklassen definieren welche Attribute mit welchen Wertetypen erlaubt sind. Mögliche Typen sind unter anderem IA5 (~ASCII) Zeichenketten, JPEG Fotos, u-law kodierte Sounddaten, URLs und PGP Schlüssel. Die Objektklasse "person" muß z.B. die Attribute " cn" (common name) und "sn" (surname ), darf aber auch das Attribut "telephoneNumber" und weitere besitzen (siehe /etc/slapd.oc.conf). Unter den meist genutzten Objektklassen befinden sich

Alias
Country
Locality
Organization
Organizational Unit und
Person.

Häufig genutzte Attribute sind unter anderem:

Common Name (CN)
Organization Name (O)
Organizational Unit Name (OU)
Locality Name (L)
Street Address (SA)
State or Province Name (S)
Country (C)

Jeder Eintrag hat einen "distinguished name" - welcher ihn eindeutig adressiert. Für Personen eignet sich das CN-Attribut als bestimmender Namensteil, da er in der Regel aus dem vollständigen Namen gebildet wird. Eine eindeutige Schreibweise für einen Benutzer wäre z.B. cn=Dr. Paul Sommer, ou=PKW, ou=Produktion, o=fiktiv AG, c=DE.

Wem angesichts dieser Notation das kalte Grausen ereilt, sei auf RFC-1781 verwiesen, in dem eine benutzerfreundlichere Schreibweise vorgestellt wird. So ist danach die Schreibweise "Dr. Paul Sommer, PKW, Produktion, fiktiv AG, DE" äquivalent zur oben aufgeführten.

Abb 3: Baum von Objekten

Konfiguration des slapd

Die Übersetzung ist nicht ganz trivial - aber unumgänglich, da keine Binaries zum Herunterladen bereitliegen. Zu der Version 3.3 gibt es diverse Patches, die in ldap-3.3-4.src.rpm enthalten sind.

Vor der Übersetzung sollte in include/ldapconfig.h.edit der Organisationsname korrigiert werden. Unterläßt man dies muss entweder in /etc/defaultbase.ldap der Eintrag o=fiktiv AG, c=DE vorgenommen werden - oder es muss bei jedem Aufruf von ldapsearch mit dem Schalter -b "o=fiktiv AG, c=DE" die neue Suchbasis angegeben werden.

In Make-common sollten die Symbole HAVEISODE und PEPSY_DUMP auskommentiert sein, da das isode-Paket extra beschafft werden muß und nur für den ldapd-Server (X.500 Gateway) notwendig ist. Als LDBMBACKEND sollte allein die GNU gdbm gewählt werden.

Abb. 4: slapd-Konfiguration (/etc/slapd.conf)

include /etc/slapd.at.conf include /etc/slapd.oc.conf schemacheck off referral ldap://ldap.itd.umich.edu ################################### # ldbm database definitions ################################### database ldbm suffix "o=fiktiv AG, c=DE" directory /var/ldap rootdn "cn=root, o=fiktiv AG, c=DE" rootpw secret

Nach Installation, Editieren der Datei /etc/slapd.conf (Abbildung 4) und Anlegen des Verzeichnisses /var/ldap kann der Server von root (wegen des privilegierten Ports) mit

# /usr/sbin/slapd -f /etc/slapd.conf

gestartet werden.

Definition der fiktiv AG

Um Einträge in das Verzeichnis einzufügen, generiert die Verwalterin eine Textdatei im LDIF-Format (LDAP Data Interchange Format - siehe man 5 ldif). Abbildung 5 zeigt den Inhalt einer Datei, die den Baum in Abb.3 der fiktiv AG im LDIF-Format beschreibt. Bei laufendem Server können die Einträge in das Verzeichnis eingetragen werden. Der Aufruf

$ ldapadd -D "cn=root,o=fiktiv AG,c=DE" -w secret -c -f /tmp/fiktiv.ldif

erledigt das für uns.

Abb. 5: fiktiv AG im LDIF-Format (fiktiv.ldif)

dn: o=fiktiv AG, c=DE o: fiktiv AG objectclass: organization dn: ou=Produktion, o=fiktiv AG, c=DE objectclass: organizationalunit dn: ou=PKW, ou=Produktion, o=fiktiv AG, c=DE objectclass: organizationalunit dn: cn=support, ou=Vertrieb, o=fiktiv AG, c=DE cn: support mail:support@fiktiv.de facsimileTelephoneNumber:0190 332 332 objectclass: organizationalRole dn: cn=Dr.Sommer, ou=PKW, ou=Produktion, o=fiktiv AG, c=DE cn: Dr. Sommer sn: Sommer mail: Dr.Sommer@fiktiv.de objectclass: person

Läßt man die Bindungsinformation und Paßwort weg oder gibt falsche an, erhält man die lapidare Meldung:

ldap_add: Insufficient access

Die einfache Authentifizierung erfolgt hier über die Angabe des distinguished name von root (rootdn) und das in der Konfigurationsdatei /etc/slapd.conf angegebene Paßwort (hier: secret). Dieses Paßwort wird in Klartext übermittelt und ist somit leicht durch Paket-Sniffer wie tcpdump oder tcpview "abzuhören" - wie Abbildung 6 zeigt.

Abb. 6: Einfache Authentifizierung mit Klartext-Paßwort

Wer Kerberos, ein anerkannt sicheres Ticket-basiertes Authentifizierungsverfahren, sein Eigen nennt, kann den slapd auch mit dieser Zugriffskontrolle kompilieren. Der LDAP-Server von Netscape Communications bietet zur Verwaltung der Server eine Verbindung über SSL (Secure Socket Layer) an, um Mißbrauch abzuwenden. Hier steckt auch noch Bedarf für weitere Entwicklungen und Standardisierungen.

Zum Ändern eines Eintrages dient ldapmodify. Hier wäre es wünschenswert, wenn jeder Benutzer seinen eigenen, nicht aber die Einträge anderer ändern darf, um dem Administrator Arbeit abzunehmen. Dies setzt aber die Zuweisung von Zugriffsrechten und eine bessere Authentifizierung voraus. So könnte ein Mitarbeiter z.B. seine EMail-Adresse selbst ändern:

$ ldapmodify -r <<EOF
>dn: cn=Dr. Sommer, ou=PKW, ou=Produktion, o=fiktiv AG, c=DE
>changetype: modify
>replace: mail
>mail: Paul.Sommer@fiktiv.de
>EOF

Die Nadel im Heuhaufen ...

Nachdem der slapd läuft und auch ein paar Einträge gespeichert hat, geht es nun darum die Informationen abzufragen. Im Paket der University of Michigan befindet sich hierzu das bereits erwähnte ldapsearch. Das eignet sich erstmal hervorragend dazu, die Funktionstüchtigkeit des Servers zu überprüfen.

$ ldapsearch -h localhost cn=\*
cn=support, ou=Vertrieb, o=fiktiv AG, c=DE
cn=support
mail=support@fiktiv.de
facsimiletelephonenumber=0190 332 332
objectclass=organizationalRole

cn=Dr.Sommer, ou=PKW, ou=Produktion, o=fiktiv AG, c=DE
cn=Dr. Sommer
sn=Sommer
mail=Dr.Sommer@fiktiv.de
objectclass=person

Bei Angabe von objectclass=\* als Suchfilter erhält man alle Einträge angezeigt. Über weitere Möglichkeiten gibt die Hilfeseite Auskunft (man ldapsearch).

Der Netscape Communicator 4.x "versteht" das in RFC-1959 definierte LDAP-URL-Format und ermöglicht es Suchparameter anzugeben, um die Ausgabe großer Verzeichnisse auf die relevanten Informationen zu beschränken. Die Syntax für das URL-Format lautet folgendermaßen (siehe Abb. 7):

Abb. 7: Syntax für das URL-Format

<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

Abbildung 8 zeigt den interessanten Teil des Verzeichnisbaums unterhalb der fiktiv AG im Web-Browser, wobei ein weiterer Eintrag hinzugefügt wurde.

Abb. 8: Ausgabe des gesamten Baumes der fiktiv AG

Spieglein, Spieglein ...

Man muß kein Prophet sein, um die Bedeutung von LDAP zu erkennen - die Realität bestätigt dies auch bereits. Im Umfeld proprietärer Verzeichnisdienste wie Novells NDS oder den von Microsoft angekündigten Active Directory Services für Windows NT hat LDAP die Rolle des Standardprotokolls übernommen. Microsoft bietet mit ADSI 1.0 eine Ergänzung für NT 4.0 an, die als Provider bereits LDAP, NDS, NetWare 3.x und NT enthält. ADSI wird in NT 5.0 standardmäßig enthalten sein.

Auch die Open Group ergänzt den Global Directory Agent (GDA) des Distributed Computing Environment (DCE) um den LDAP-Mechanismus. Und während dieser Artikel sein Ende findet, bietet Control Data seinen IntraStore Server 98.1 für Linux zum kostenlosen Download unter [7] an. IntraStore bündelt Mail-, Datei-, Dokumenten- und Web-Dienste und stellt sie in einem zentralen Verzeichnis bereit - wie wird wohl darauf zugegriffen?

Abb. 9: Liste der RFCs

RFC-1558: A String Representation of LDAP Search Filters
RFC-1777: Lightweight Directory Access Protocol
RFC-1778: The String Representation of Standard Attribute Syntaxes
RFC-1779: A String Representation of Distinguished Names
RFC-1781: Using the OSI Directory to Achieve User Friendly Naming
RFC-1798: Connectionless LDAP
RFC-1823: The LDAP Application Programming Interface
RFC-1959: An LDAP URL Format
RFC-1960: A String Representation of LDAP Search Filters
RFC-2251: Lightweight Directory Access Protocol (v3)
RFC-2307: LDAP as a Network Information Service

Infos

[1] http://www.umich.edu/~dirsvcs/ldap/index.htmlLDAP-Server der University of Michigan
[2] http://www.xedoc.com.au/~lukeh/ldap/nss_ldap.tar.gz Nameservice Switch-Modul für LDAP-lookup in glibc
[3] http://www.csn.ul.ie/~airlied/pam_smb/ PAM Modul für Authentifizierung an NT-Domäne
[4] http://www.intranet.csupomona.edu/~henson/www/projects/nss_dce/ NSS-Modul für DCE
[5] http://www.critical-angle.com/ldapworld/ldapfaq.htmlLDAP-FAQ
[6] http://www.nexor.com/public/directory.html Nexor, Informationen zu X.500
[7] http://intrastore.cdc.com IntraStore Server von Control Data

Der Autor

Peter Wächtler ist freiberuflicher DV-Anwendungsentwickler und Netzwerk-Ingenieur. Der erste Kontakt mit Linux fand vor knapp 5 Jahren statt.