LDAP (Schwerpunkt OpenLDAP)

Lightweight Directory Access Protocol (LDAP) ist ein Anwendungsprotokoll aus der Computertechnik. Es erlaubt die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank: absoluter Pfad kennzeichnet Datensatz) über das TCP/IP Netzwerk. Die aktuelle Version ist in RFC 4511 spezifiziert.

Das LDAP-Protokoll wird in vielen bekannten Verzeichnisdiensten (und Servern) benutzt:

• Slapd (University of Michigan, Openldap)
• Netscape Directory Server
• Microsoft Active Directory (AD)
• Microsoft Exchange
• Novell Directory Services (NDS)
• Lotus Domino
• Sun Directory Services (SDS)
• Lucent’s Internet Directory Server (IDS).

LDAP ist für relativ einfache Lesezugriffe optimiert. Man kann zwar mit boolschen Ausdrücken arbeiten, es findet aber keine Sortierung durch den LDAP-Server statt. D.h. die Datensätze kommen in beliebiger Reihenfolge, da die LDAP-Entwickler der Meinung sind, so etwas gehört auf dem Client implementiert (auch um die Serverlast zu minimieren).

Der LDAP-Server hat ein sog. Schema (=genormte und ggf. erweiterte Struktur), das das Format der Datensätze (Entrys) mit ihren Attributen definiert.

Das Schema legt die Regeln für gespeicherten Daten fest (benötigte und erlaubte Attribute) und hilt so die Daten konsistent zu halten. Dabei sollte man sich aus Kompatibilitätsgründen möglichst an vordefinierte Schemata halten bzw. bei sog. Schemaerweiterungen möglichst ein vorhandenes erweitern. Vordefinierte Objektklassen stehen in der Datei /etc/openldap/schema/core.schema .

Ein Datensatz (Entry) hat eine oder mehrere Objektklassen (Objectclass) die zum gruppieren der Informationen benutzt werden und benötigte und erlaubte Attribute festlegt. Der Datensatz ist ein Knoten im Baum (DIT: directory information unit).

Zusätzlich können Aliase (Eintrag mit Objektklasse Alias, Attribut namens „aliasedObjectName“ die auf den DN verweist) angelegt werden.

LDAP ist flexibler als das angegraute NIS: Dieses ist formatgebunden, wenig Möglichkeiten bei den Zugriffsrechten (ACLs) und kann keine Verschlüsselung. Zudem wird autofs als NIS-Ersatz benutzt.

LDAP-User-IDs (UIDs) mit gutem Abstand zu den System UIDs anlegen (falls man später noch lokale Benutzer anlegen will).

Authentifizierung kann auch von Kerberos vorgenommen werden.

LDAP kann sehr gut bei klassischen Einsatzzwecken eines Verzeichnisdienstes eingesetzt werden: Bei verteilten Daten wie Adressbücher für Anwendungen und MUAs (Thunderbird, ..), fingerd, … .

Die Integration in Programme erfolgt entweder über die Shell-Befehle (Änderungsanweisungen im LDIF-Format), Bibliotheken und native Funktionen.

Das LDIF-Format

1. repräsentiert LDAP-Einträge in (menschenlesbarer) Textform
2. erlaubt eine einfache Datenänderung
3. ist nützlich für Massenänderungen: DB in LDIF, Skript drüber jagen, importieren
4. kann Vorlagen benutzen
5. dient zum Backup und zum Datentransfer zu anderen Systemen

dn: uid=user1,ou=People,
         dc=mycompany,dc=com
uid: user1
cn: User One
objectclass: account
objectclass: posixAccount
objectclass: top
loginshell: /bin/bash
uidnumber: 500
gidnumber: 120
homedirectory: /mnt/home/bmarshal
gecos: Brad Marshall,,,,
userpassword: {crypt}KDnOoUYN7Neac

Anmerkung zu „userpassword“ hier wird der verwendete Hash (crypt) in geschweiften Klammern angegeben. Es sind serverseitig mehrere Hash-Algorithmen möglich, die dann auch vom Server verwaltet werden und eine spätere Migration zu einem anderen Hash-Algorithmus problemlos möglich machen (ohne dass alle sofort ihre Passwörter ändern müssen).

• ldbmcat & slapcat: ldbm Datenbank zu LDIF
• ldif2ldbm & slapadd: LDIF zu ldbm Datenbabk

Beispiel: uid=bmarshal,ou=People,dc=mycompany,dc=com

• Containerobjekte sind objekte die weitere enthalten, z.B. CN, OU, O und DC.
• Blattobjekte

Der Datensatz setzt sich aus Attributen zusammen, die wiederum Werte eines bestimmten (Daten-) Typs enthalten. Attribute haben

1. einen Namen
2. eine OID (siehe Tabelle)
3. eine Syntax (Datentyp und wie die Wert verglichen können)
4. eine Anweisung ein oder mehrere Werte zu enthalten

Siehe RFC2256 - A Summary of the X.500(96) User Schema for use with LDAPv3

• Die mitgelieferten (kommandozeilenbasierten-) Such-/Bearbeitungstools: ldapsearch, -modify, …
• Directory Administrator
• Luma - LDAP browser + utility (Python, PyQt und python-ldap)
• phpLDAPadmin (PHP)
• web2ldap - web-based LDAPv3 client
• GQ - LDAP client (GTK+)
• LDAP Browser/Editor (Java)
• JXplorer - A Java Ldap Browser
• Softerra LDAP Browser (Freeware, Windows)
• GOsa² - Der GONICUS System Administrator (GPL, web)

OpenLDAP läuft auf den meisten UNIX-basierten Systemen: FreeBSD, Linux, NetBSD, OpenBSD und Windows (http://lucas.bergmans.us/hacks/openldap/|Homepage des Ports). . Siehe OpenLDAP Homepage.

OpenLDAP arbeitet mit den Modulen

• nss_ldap (für weniger sensible Daten)
• pam_ldap (authentication und Passwortänderungen)

nss_ldap eignet sich nur für wenig sensible Daten: user-id, shell, …

Es wird in der Datei /etc/nsswitch.conf konfiguriert.

passwd: files ldap
shadow: files ldap
hosts: files dns

Eine Delegation von Unterbereichen ist möglich (man kann Teile mounten). Der Datenaustausch wird in den Formaten

• LDIF (Einträge der Form „Attribut: Wert“ in einer Textdatei)
• ?

Für sensible Daten wie Passwörter eignet sich eher pam_ldap.

Die Abfragen beschränken sich meist auf:

1. ldap_simple (zum Passwortüberprüfen; ohne SASL-Schicht): Klartext (aber über TLS), der Hash wird vom Server berechnet (transparent für den Client)
2. SASL external (beide Zertifikate: Server und Client) ohne SASL

RFC 2255 - LDAP URL Format (ersetzt RFC1959): Format für LDAP-Urls und mit Lesezugriff.

Aufbau LDAP-URL, vereinfacht:

1. Protokoll ldap / ldaps (verschlüsselt)
2. Servername und Portnummer
3. BASE-DN (Einsprungspunkt)
4. auszulesende Attr.
5. Suchbereich (scope)
6. Boolscher Filterausdruck
7. Erweiterungen

Also z.B.: ldaps://ldap.mycompany.com/dc=bar,dc=com?cn?sub?uid=user1

Komplett aus RFC 2255:

       ldapurl    = scheme "://" [hostport] ["/"
                    [dn ["?" [attributes] ["?" [scope]
                    ["?" [filter] ["?" extensions]]]]]]
       scheme     = "ldap"
       attributes = attrdesc *("," attrdesc)
       scope      = "base" / "one" / "sub"
       dn         = distinguishedName from Section 3 of [1]
       hostport   = hostport from Section 5 of RFC 1738 [5]
       attrdesc   = AttributeDescription from Section 4.1.5 of [2]
       filter     = filter from Section 4 of [4]
       extensions = extension *("," extension)
       extension  = ["!"] extype ["=" exvalue]
       extype     = token / xtoken
       exvalue    = LDAPString from section 4.1.2 of [2]
       token      = oid from section 4.1 of [3]
       xtoken     = ("X-" / "x-") token

Zugriffsrechte lassen sich fein granular zuweisen.

access
to dn.sub="ou=, .."
by self write
by * auth 

by * auth: nur fragen

Die erste zutreffende Regel gilt!

• Datenbank-Backend (meist Berkeley DB = BDB, andere möglich: SQL etc., wenn man keinen guten Grund hat: beibehalten; An Indices und Caches denken!)
• Anwendung
• SASL
• TLS
• TCP/IP

Durch ein Replication-Logfile (Übertragung mit slurpd) ist auch ein Backupserver (Slave) möglich, das delegieren einzelner Teile bleibt ebenfalls möglich.

Damit wird die

1. Verlässlichkeit
2. Verfügbarkeit (durch mehrere Server, master:lesen+schreiben und slaves=Backupserver:nur-lesen; Eleminierung des „single point of failure“)
3. Geschwindigkeit: Sowohl durch örtliche Nähe (langsame Verbindungen) als auch durch Lastverteilung (Suchanfragen)

erhöht.

Temporäre Inkonsistenzen sind ok, geschrieben wird eh nicht allzu oft.

Replikationsablauf: Verweise (Referrals)

1. Client sendet Änderungen an den slave-Server
2. slave-Server gibt den Verweis an den master zurück
3. Client sendet Änderungen diesmal an den master-Server
4. master-Server gibt das Änderungsergebnis an den Client zurück
5. master-Server gibt die Änderungen an den slave-Server weiter

Replikationsablauf: Verketten (Chaining)

1. Client sendet Änderungen an den slave-Server
2. slave-Server leitet den Änderungswunsch an den master weiter
3. master-Server gibt das Änderungsergebnis an den slave-Server zurück
4. slave-Server schickt Ergebnis an den Client weiter
5. master-Server gibt die Änderungen an den slave-Server weiter

• OpenLDAP Replikation

• openldap.org (Doku, FAQ)

Die mitgelieferten man-pages (Hileseiten)

• man slapd.conf
• man slapd.access
• man slapd

• Liste der LDAP-Fehlermeldungen

• nur ein master catalog server zu einer Zeit pro domain (noch aktuell? )
• OpenLDAP for Win32
• Da OpenLDAP (vor allem beim Server) sehr aktiv entwickelt wird, ist die Doku (vor allem die man-pages) oft hinterher (z.B. werden veraltete Funktionen beschrieben) wenn man aus dem Quellcode kompiliert. Deshalb sollte man nicht allzu oft upgraden. Wenn man eine vorkompilierte Version einer Distribution (z.B. aus Debian) benutzt, wird das Problem (hoffentlich) geringer ausfallen, da auf einer stabilen Version verblieben wird und der Paketbetreuer (maintainer) sich mehr drum kümmern sollte.
• kryptische Fehlermeldungen
• ACL erst „nach und nach“ machen (und testen!)
• NICHT für viele Schreibzugriffe geeignet!
• komplexe Abfrage und Strukturänderungen sind ein großes Problem
• keine Transaktionen (add / modify sind aber atomar) / kein Locking

• Backups machen und/oder Daten replizieren
• man kann komplette Server migrieren/replizieren durch „dump“ der Konfiguration und Daten
• Server mit persönlichen Daten vor Zugriff schützen (Slave-Server öffentlich (ro), Master-Server intern)
• DB-Strukturen sorgfältig planen, Attribute (z.B. „memberOf:“), möglichst vordefinierte (Kompatibilität)
• Keep it simple!
• keine Schreibzugriff durch Applikationen

• Straffe Verwaltung - OpenLDAP-Praxis
• OpenLDAP - Artikel
• LDAP-Einführung
• Introduction to LDAP
• Demystifying LDAP

• LDAP Howto, LDAP Links, LDAP Whitepapers

• Top Five Open Source Packages for System Administrators #4: LDAP
• Verzeichnisdienst.de - Links zu Verzeichnisdiensten
• LDAP Tutorial (PDF)
• Building an LDAP Server on Linux, Part 1

• LDAPv3 Präsentation

• LDAP Implementation HOWTO
• Building a LAMP Server w/ LDAP Authentication

• Mit LDAP Accounts für Unix und Windows zentral verwalten
• Authenticating with LDAP using Openldap and PAM
• LDAP Authentication In Linux
• The Exchange Server Replacement HOWTO (IMAP, POP3 Authentification using LDAP
• using LDAP for Authentification
• LDAP Authentication in PHP

• O´Reilly: LDAP System Administration

• OpenLDAP-Adressbuch für Thunderbird

1. Linux Journal: LDAP Series [Parts I and II]
2. Linux Journal: LDAP Series Part III--The Historical Secrets
3. Linux Journal: LDAP Series Part IV--Installing OpenLDAP on Debian Plus Some LDAP Commentary
4. Linux Journal: LDAP Series Part V--Getting a Grip on Directory Service Modeling

Firewalling:

• 53 (udp/tcp) dns → AD
• 88 (udp+udp) kerberos
• 389 (tcp+udp) LDAP
• 445 tcp AD GPOs
• 464 (udp+udp) kpasswd
• 636 (tcp) LDAP TLS
• 3268 (tcp) Ad global catalog
• 3269 (tcp)

SASL Bind (RFC 2829)

LDAP Funktionen von PHP. Benutzer mit PHP gegen ein Active Directory (LDAP) authentifizieren Webzentriert - Zugriff auf LDAP-Daten mit PHP

• Overlays: zwischen dem Datenbank-backend und Anwendungsschicht kann man eigene Overlays einfügen die dann Anfragen modifizieren, abkürzen usw.

Beispiel: eigene eMail-Adresse mit Verfallsdatum und Signatur modifizieren:

bbmail: http://www.best-before.qipc.org