Administratorhandbuch:LDAP

Diese Seite sollte nochmals überarbeitet werden. Eine Begründung befindet sich in der Regel unter Diskussion (oben).

Die zentrale Dienste- und Nutzerverwaltung mit LDAP

Dieses Kapitel ist etwas umfangreicher, da die Einführung von LDAP in den Arktur-Schulserver eine wesentliche Neuerung der Version 4 darstellt.

Grundlagen des LDAP

Was ist LDAP

Das Lightweight Directory Access Protokoll (LDAP) ist in der Lage, die Benutzer- und Diensteverwaltung für unterschiedliche Betriebssysteme in einer zentralen Datenbasis zu übernehmen. LDAP schafft damit die Voraussetzung für die Realisierung von "Single Sign-On", der einmaligen, netzweit gültigen Anmeldung von Benutzern für die verschiedensten Dienste.

Ein Verzeichnisdienst

LDAP ist ein Verzeichnisdienst, aber keine relationale Datenbank. Worin besteht der Unterschied?

• Auf ein Verzeichnis wird sehr oft lesend, aber nur selten schreibend zugegriffen.
• Ein Verzeichnis ist baumartig organisiert.
• Teilbereiche können jederzeit auf verschiedene Server verteilt werden. Damit ist auch deren Administration wesentlich leichter zu verteilen.
• Verzeichnisse ermöglichen von vorn herein ein objektorientiertes Datenmodell.

Ein Beispiel: Das DNS (Domain Name System) ist schon seit vielen Jahren als Verzeichnis organisiert. Damit ist unter anderem gewährleistet, dass jedes Land seine eigene Zone selbst verwalten kann.

Ein weiterer Anwendungsfall für Verzeichnisse ist die Abbildung von Organisationen. Organisationen sind meist hierarchisch aufgebaut. So können Abteilungen ihre eigenen Verzeichnisse aufbauen und verwalten, ohne das in der Spitze der Organisation der Überblick verloren geht. Die Administration kann bis zur untersten Ebene delegiert werden. Damit ist es Beispielsweise sogar einem einzelnen Benutzer erlaubt, sein eigenes Adressbuch direkt im LDAP selbst zu administrieren.

Objektorientierung

Objektmodell: Bitte lesen Sie in entsprechender Fachliteratur nach, denn eine Beschreibung des Objektmodells würde diese Anleitung sprengen. Hier kann also nur auf die Umsetzung des Objektmodells im LDAP eingegangen werden.

Objekte: Verzeichnisse bilden Objekte ab und setzen diese miteinander in Beziehung. Objekte verfügen über einen Satz von Eigenschaften, den Attributen.

Ein ganz besonderes Attribut ist der Name des Objektes. Jedes Objekt hat aber eine Vielzahl weiterer Eigenschaften (Attribute).

Ein Attribut wiederum besteht aus einem Namen und (keinem, genau einem oder mehreren) Attributwerten.

Objektklassen: Bei Verzeichnisdiensten werden Objektklassen verwendet, um die Struktur der Daten zu beschreiben. Wenn also zum Beispiel die E-Mailadresse der Benutzer um einen kryptografische Schlüssel erweitert werden soll, wird durch Vererbung einfach eine neue Objektklasse erzeugt, die um das Feld "kryptografischer Schlüssel" erweitert wird.

Attribute: Um die Wiederverwendbarkeit der Attribute gewährleisten zu können, werden diese getrennt von den Objekten definiert. Das geschieht in "Attribute Type", also den Attributtypen.

Was kann LDAP verwalten

LDAP kann die Dienste- und Nutzerverwaltung in einem Verzeichnis vereinen.

• Benutzer und Gruppen, aus ehemals:

 /etc/passwd
 /etc/shadow
 /etc/groups

• IP-Dienste (Zuordnung zwischen Diensten und Portnummern)
• IP-Protokolle, aus ehemals:

 /etc/protocols

• RPCs, aus ehemals:

 /etc/rpc

• NIS-Informationen
• Boot-Informationen (MAC-Adressen und Boot-Parameter)
• Mountpoints, aus ehemals:

 /etc/fstab

• Mail-Aliase

Hinweis: Der Arktur-Schulserver Version 4.0 verwaltet nicht alle hier genannten Dienste im LDAP.

Wo wird dem Server denn gesagt, das er auf LDAP zugreifen muss

• Zum einen beim Kompilieren der Pakete. Fehlt die LDAP-Unterstützung beim Übersetzen, wird er nie mit einem LDAP-Server kommunizieren können.

• Zum anderen müssen die Zugriffsdaten auf LDAP in der jeweiligen Konfigurationsdatei, beim DHCP-Server beispielsweise in "/etc/dhcpd.conf" stehen.

LDIF-Dateien

Das LDAP Data Interchange Format (kurz LDIF) dient zum ein- und auslesen von Daten in/aus LDAP mittels einer Textdatei. Eine LDIF-Datei enthält eine Versionsnummer, eine Anweisung (add, delete, modify...) zur Behandlung des folgenden Datensatzes und einem (oder vielen) Datensätzen.

Wo liegen diese LDIF-Dateien

Wenn Sie als Nutzer sysadm eine Änderung veranlassen, dann wird im Hintergrund mit echo-Befehlen aus Ihren Eingaben eine LDIF-Datei erzeugt. Wenn Sie dann auf "Aktivieren" gehen, wird diese LDIF-Datei in den LDAP eingelesen und danach weggeworfen, also gelöscht.

Beispiel: Sie können die LDIF-Dateien der Ersteinrichtung (Serverinstallation) in "/var/adm/setup/done" nachlesen.

Hinweis: Der Arktur-Schulserver 4 hat einen cron-Job, der täglich in der Nacht eine gesamt.ldif Datei erstellt und diese im Verzeichnis "/etc/ods" ablegt. Wenn Sie also "/etc" immer komplett sichern, sind die Daten aus Ihrem LDAP später wiederherstellbar.

---

Suche im LDAP

Nachzulesen mit "man ldapsearch"

So liefert z.B.

 ldapsearch -x -LLL "(gecos=*,7a)" gecos

die Realnamen aller Schüler der Klasse 7a.

Verknüpfungen mit UND bzw. ODER sind ebenfalls möglich. So liefert also

 ldapsearch -x -LLL "(&(objectclass=posixGroup)(cn=zeit*))"

die Daten aller Gruppen, die mit "zeit" beginnen (Zeitung, Zeitformen,...).

Wo liegen die Daten?

Die eigentliche Datenbasis von LDAP liegt in /var/lib/ldap

LDAP-Daten auslesen

Die man-page von slapcat verrät,...

  /usr/sbin/slapcat  [-v]  [-c]  [-d  level]  [-b  suffix] [-n dbnum] [-f
        slapd.conf] [-l ldif-file]

...dass die Ausgabe auf dem Bildschirm erfolgt, wenn nicht die Option -l mitgegeben wird.

 -l ldif-file  Write LDIF to specified file instead of standard output.

Jede Nacht legt Arktur genau diese Ausgabe in /etc/ods als gesamt.ldif ab. Darin ist also _alles_ enthalten bis letzte Nacht.

Slapadd liest mit der gleichen Option aus einer Datei ein.

 # slapadd -l /wo/ichs/mittlerweile/hinkopiert/habe/mein.ldif.file

Wichtig: slapadd sollte nur ausgeführt werden, wenn LDAP _NICHT_ aktiv ist. Also vorher

 /etc/init.d/ldap stop

ausfühen, dann

 slapadd -l /etc/ods/gesamt.ldif

LDAP-Administration

Der Nutzer root

Der Nutzer root hat auf dem LDAP nur Gastrechte. Sie müssen also erst als sysadm eine Nutzerkennung als Hauptadmin festlegen und können sich dann mit dieser Nutzerkennung anmelden. Eine Beschreibung finden Sie unter Teiladmin und Hauptadmin einrichten im Installationshandbuch.

Verwaltung des LDAP

Starten Sie einen Browser und geben Sie die Adresse https://Arktur/ldapadmin ein. Sie werden nach Benutzername und passwort gefragt. Geben Sie Ihre normalen Nutzerdaten ein.

Ein Anfang aus einer Mail

Frage:

Wo liegt der Unterschied der 2 Verzeichnisse /usr/www/secure/ldapadmin und /usr/www/phpldapadmin und warum Version 0.9.3 und nicht 0.9.6?

Antwort:

Frage 1: an ldapadmin kann man sich mit seinem Nutzernamen und seinem Passwort anmelden. Bei phpldapadmin, das weitestgehendst Hardlinks sind, muss man die vollständige dn angeben. Da man sich an ldapadmin nicht als "cn=admin, dc=meine_schule,c=de" anmelden kann, habe ich einfach beides vorgesehen. Der Platzunterschied ist minimal (eigentlich nur config).

Frage 2: Seit 0.9.4 werden Attribute, die einen Binärtyp haben, nicht mehr angezeigt. Damit kannst Du z.B. die MAC-Adresse im DHCP-Baum nicht mehr per ldapadmin anpassen. Er bietet nur an, den Binärwert zu laden. Daher habe ich einen Downgrade gemacht. Neben DHCP trifft das auch auf einige Samba-Attribute zu.

Nachträgliches Ändern

Beispiel:

An eine einzige Netzwerkkarte im Arktur-Schulserver sollen mehrere Räume der Schule angebunden werden, wobei jeder Raum einen Adressbereich (192.168.0.0, 192.168.1.0, 192.168.2.0 etc.) bekommen soll.

Wenn Sie per sysadm eine neue Netzkarte einrichten, dann dürfen Sie die Netzmaske nicht im Menü ändern, solange Arktur die IP 192.168.0.1 hat.

Trick, damit es trotzdem geht:

Richten Sie die Netzwerkkarte nochmals neu ein. Geben Sie ihr aber die IP 172.168.0.1 statt der eigentlich gewünschten 192.168.0.1. Jetzt dürfen Sie auch die Netzmaske setzen. Hier bei Ihnen auf 18 Bit. Die Nachfrage sollte nun:

 IP 172.168.0.1
 Netzmaske 255.255.192.0
 Netz 172.168.0.0
 BCast 172.168.63.255

ergeben. Dies bestätigen Sie nun. Aber es wird nicht aktiviert, da ja die Adresse nicht die richtige ist.

Nun kommt die Änderung auf die richtige Adresse (als root). Öffnen Sie die Datei /etc/Systemverwaltung/ether und ändern Sie die 172 wieder auf die 192. Das sollte in der Datei 3 mal der Fall sein.

Jetzt erst wird aktiviert. Und danach der ganze Server neu gestartet.

Problem dabei:

Hier liegt jetzt aber Dein Problem: Als Du den PC eingerichtet hast, der die IP 192.168.1.39 erhalten soll, wurde dieser Eintrag an das Netz 192.168.1.0 gebunden. Im LDAP findet sich ein Zweig cn=192.168.1.0,cn=DHCP Service Config,o=DHCP,dc=...,c=de

Änderst Du nun die Maske des Netzes 192.168.0.0, wird das Script von ether den Eintrag im LDAP von cn=192.168.0.0 anpassen. (Das hat es gemacht, sonst hätte der Client nichts von der neuen Netzmaske erfahren.) Sein Eintrag im LDAP steht nun aber im falschen Netz. Das wäre im Prinzip auch passiert, wenn dieser Eintrag in einer Textdatei stehen würde. Also wertet der DHCP-Server diesen Eintrag nicht aus.

Das bedeutet: Du musst von Hand den Zweig cn=192.168.1.0 löschen. Anschließend kannst Du versuchen, einen weiteren Computer einzutragen, das ganze AKTIVIEREN und notfalls diesen zusätzlichen Eintrag wieder zu löschen. Dabei erkennt das sysadm-Script, dass sich die Netzmaske geändert hat und wird den DHCP-Eintrag des Computers beim Aktivieren in der richtigen cn=192.168.0.0 neu erstellen. Nach dem AKTIVIEREN kannst Du den Client noch mal neu starten. Er sollte nun die 192.168.1.39 erhalten können.

---

zurück | Hauptseite