Administratorhandbuch:LDAP

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

Die zentrale Nutzerverwaltung mit LDAP

• Der Anfang stammt aus einer Mail von Reiner

Was ist LDAP

Es gibt EINE Bibliothek, die der LDAP-Server mitbringt (libldap, liblber).

Die Programme, die auf den LDAP-Server zugreifen sollen, werden beim Kompilieren gegen diese Bibliotheken gelinkt.

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