Administratorhandbuch:LDAP

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

Die zentrale 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 übernehmnen. 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.

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.

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.

---

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

Zum einen beim Kompilieren. Fehlt die LDAP-Unterstützung beim Übersetzen, wird er nie mit einem LDAP-Server kommunizieren können. Zum anderen müssen die Zugriffsdaten in der Konfigurationsdatei, beim DHCP-Server beispielsweise in

 /etc/dhcpd.conf

stehen.

Wo sind diese LDIF Dateien?

Sie werden mit echo-Befehlen erzeugt, in den LDAP eingelesen und dann weggeworfen. Sie können die LDIF-Dateien der Ersteinrichtung in

 /var/adm/setup/done

nachlesen.

Die aktuellen Versionen von Arktur 4 (seit Februar) haben einen cron-Job, der eine gesamt.ldif Datei erstellt und in /etc/ods ablegt. Wenn Sie /etc immer komplett sichern, sind die Daten im LDAP wiederherstellbar.

LDAP nutzt aber keine Abfragesprache wie SQL, oder?

Nicht SQL, aber dennoch eine spezielle Form. 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