In der ORDIX News 4/2007 [1] haben wir bereits über neue Funktionen des OpenLDAP berichtet, die in der Version 2.3 Einzug gehalten haben. Hierbei kamen der neue Replikationsmechanismus syncrepl und die overlays zur Sprache. In diesem Artikel wird eine weitere, neue Funktion präsentiert: die LDAP-Serverkonfiguration ohne Neustart des Dienstes oder Neuladen der Konfigurationsdatei. Zudem wird am Beispiel sudo demonstriert, wie sich das vielfältige LDAP-Protokoll für andere Zwecke, fernab der Benutzerauthentifizierung, nutzen lässt.

Konfiguration zur Laufzeit

In der Praxis setzen die meisten Unternehmen aus Redundanz- und Lastverteilungsgründen mehrere LDAP-Server zur Authentifizierung und Namensauflösung ein. Selbst in mittelgroßen Unternehmen sind das schon mal schnell fünf bis acht LDAP-Server. In älteren OpenLDAP-Versionen musste der Dienst jedes Mal neu gestartet beziehungsweise die Konfigurationsdatei neu geladen werden, nachdem eine Änderung in der Konfigurationsdatei /etc/openldap/slapd.conf durchgeführt wurde. Da die Änderungen meistens auf allen LDAP-Servern durchgeführt werden sollten, musste dies für jeden Server separat durchgeführt werden.

Seit der Version 2.3 des OpenLDAP-Servers kann die Konfiguration zur Laufzeit geändert werden. Für die Umsetzung wurde ein neues Datenbank-Backend namens ldif eingeführt, in dem die Konfigurationseinstellungen gespeichert werden. Die Konfigurationsdateien werden im LDIF-Format im Verzeichnis /etc/openldap/slapd.d erwartet.

Das Ändern von Konfigurationseinstellungen erfolgt nun analog zum Hinzufügen von Benutzern oder Gruppen. Es wird eine LDIF-Datei mit Konfigurationseinstellungen erstellt, die dann mit einem der beiden Befehle ldapadd oder ldapmodify auf die Datenbank angewendet werden. Der LDAP-Server erkennt die Konfigurationsänderungen und wendet sie sofort ohne Neustart an.

Die bisherige Konfigurationsdatei kann zwar weiterhin genutzt und geändert werden, allerdings mit den bekannten Nachteilen des anschließenden Neustarts des LDAP-Dienstes.

/etc/init.d/ldap stop
mkdir /etc/openldap/slapd.d
/usr/lib/openldap/slapd -f /etc/openldap/slapd.conf \
-F /etc/openldap/slapd.d
rm /etc/openldap/slapd.conf
chown -R ldap:ldap /etc/openldap/slapd.d
/etc/init.d/ldap start

Von der Parallelnutzung beider Konfigurationsverfahren ist abzuraten, da kein automatischer Abgleich stattfindet und schnell die Übersicht verloren geht, wo welche Einstellung aktiviert wurde. Wir empfehlen deshalb, die bestehende Konfiguration in das neue Verfahren zu konvertieren und die alte Konfigurationsdatei anschließend zu löschen. Abbildung 1 zeigt die notwendigen Schritte zur Konvertierung.

Es gilt dabei allerdings eine kleine Einschränkung zu beachten: Der alte Replikationsdaemon slurpd kann mit dem neuen Verfahren nicht umgehen und braucht zwingend eine slapd.conf. Dies stellt jedoch ein zu vernachlässigendes Problem dar, da der wesentlich flexiblere und auf Performance ausgelegte syncrepl-Mechanismus [1] von OpenLDAP Version 2.3 diese Einschränkung nicht besitzt.

slapd.d Internals

Der LDAP-Konfigurationsbaum unter /etc/openldap/slapd.d ist nun folgendermaßen aufgebaut: Direkt im Konfigurationsverzeichnis befinden sich das Objekt cn=config und die Datei cn=config.ldif, in der globale Konfigurationsattribute wie z. B. PID, args, TLS, Threads oder der Pfad zum Konfigurationsverzeichnis gesetzt werden. Letztendlich entsprechen die Einstellungen den globalen Einstellungen der alten Konfigurationsdatei.

Die unterhalb von cn=config befindlichen Objekte, wie z. B. cn=schema beinhalten weitere Einstellungen zur Konfiguration: Das Objekt cn=schema ist für die Konfiguration der vom slapd verwendeten Standardschemata wie z. B. core, cosine und inetOrgPerson zuständig. Mit den in geschweiften Klammern bei 0 beginnenden Zahlen kann die Ladereihenfolge der Einträge bestimmt werden.

$> ldapsearch -LLL -x -D "cn=config" -W -b cn=config objectClass=*


dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigDir: /etc/openldap/slapd.d/
olcArgsFile: /var/run/slapd/slapd.args
...
olcThreads: 16

ldap1:/tmp # cat test.ldif


dn: cn=config
changetype: modify
replace: olcThreads
olcThreads: 4


ldap1:/tmp # ldapmodify -x -W -D "cn=config" -f test.ldif

Auch innerhalb der Schemadateien sind die Objekte nun im LDIF-Format und können zur Laufzeit durch importieren einer Datei im LDIF-Format geändert werden. Um administrativen Zugriff auf die Konfiguration zu erlangen, muss nun in der Datei /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif ein Kennwort für den schon eingetragenen Benutzer cn=config gesetzt werden. Der Eintrag in der Datei hat das Format {SSHA}0JAlK29Fna1PmJvjdch2SxidRUXhLKP7. Das gehashte Kennwort kann mit dem Befehl slappasswd -s <Kennwort> erzeugt werden und erlaubt anschließend den Zugriff auf die Konfiguration mit den normalen LDAP-Befehlen. Mit dem Befehl ldapsearch (siehe Abbildung 2) kann die Konfiguration innerhalb des LDAP-Verzeichnisses angesehen werden, während mit ldapmodify (siehe Abbildung 3) Werte zur Laufzeit verändert und aktiviert werden.

LDAP als zentrales Konfigurationsdepot

In großen Unix-Umgebungen kommt häufig das Produkt sudo zum Einsatz. Das Wort „sudo“ steht hier für „substitute user do“. Um nicht allen Benutzern eines Unix-Systems alle Berechtigungen zu geben, kann der Administrator mit sudo die Berechtigungen einschränken, indem nur bestimmte Kommandos erlaubt sind und festgelegt wird, auf welchem Server sie von wem und unter welcher Benutzerkennung ausgeführt werden dürfen. Dafür schreibt der Benutzer den Befehl sudo vor den eigentlichen Befehl. Ein Beispiel wäre sudo useradd -m user1.

Klassisch wird die Konfiguration in der Datei /etc/sudoers vorgenommen. Von der Herstellerseite ist die Datei zwar so aufgebaut, dass nur eine Datei für alle Systeme gepflegt werden muss. Diese muss aber nach einer Änderung auf die betroffenen Systeme verteilt werden, was vor allem in größeren Umgebungen einen erheblichen Pflegeaufwand verursacht. Dieser Pflegeaufwand wird mit Hilfe von NIS oder anderen Möglichkeiten reduziert. Hier möchten wir aufzeigen, welche Anwendungsmöglichkeiten LDAP bietet, indem wir die sudo-Konfigurationsdaten in unserem LDAP-Verzeichnisdienst pflegen.

Vorteile der LDAP Integration

• Die sudo-Konfiguration kann zentral verwaltet werden und muss bei Änderungen nicht mehr auf die Server verteilt werden.
• Bei der sudo-Kommandoausführung muss nicht mehr die ganze sudoers-Datei ausgewertet, sondern nur im LDAP nach bestimmten Einträgen gesucht werden.
• Das Programm visudo wird nicht mehr zum Editieren der Konfiguration benötigt. Stattdessen wird der LDAP-seitige Objekt/Attribut-Check genutzt.

Nachteile der LDAP Integration

• Die sudo-Konfiguration kann nicht vollständig im LDAP implementiert werden. So ist z. B. die Gruppierung von Befehlen (command aliase), Rechnern (host aliase) und Usern (user aliase) nur bedingt umsetzbar. Das ist aber keine bedeutende Einschränkung, da bei einem LDAP-Eintrag beliebig viele Kommandos, Rechner oder Benutzer/Gruppen angegeben werden können.
• Es muss einmalig der Aufwand betrieben werden, ein LDAP-fähiges sudo auf die Server zu verteilen und eine Konfigurationsdatei anzupassen.
• Falls kein Netzwerk zu Verfügung steht, kann die sudo-Konfiguration nicht geladen werden. Als Fallback kann aber eine lokale /etc/sudoers lokal abgelegt werden.

Vorbereitung des LDAP-Servers

Um die sudo-spezifischen Objekte innerhalb des LDAP-Verzeichnisdienstes zu verwalten, muss eine Schemaerweiterung auf den LDAPServern vorgenommen werden. Dazu wird die Schemadatei sudo.schema benötigt, welche von der sudo-Webseite heruntergeladen werden kann. Zusätzlich muss die Schemadatei von OpenLDAP geladen werden. Dies kann entweder über den herkömmlichen Weg include/etc/openldap/schema/sudo.schema innerhalb der Konfigurationsdatei slapd.conf oder über das oben beschriebene Verfahren cn=config gelöst werden.

Nachdem der LDAP-Server mit den Schemaerweiterungen gestartet ist, können nun erste Einträge vorgenommen werden. Dies kann sowohl mit klassischen LDIF-Dateien geschehen, als auch mit Scripting-Verfahren, wie beispielsweise Perl oder einem grafischen LDAP-Browser wie phpLDAPadmin oder dem LDAP Account Manager (LAM).

Auch die Konvertierung einer bestehenden sudo-Konfiguration ist leicht möglich. Mit den Kommandos

export SUDOERS_BASE=ou=SUDOers,dc=ordix,dc=de sudoers2ldif /etc/sudoers > /tmp/sudoers.ldif

dn: ou=SUDOers,dc=ordix,dc=de
objectClass: top
objectClass: organizationalUnit
ou: SUDOers


dn: cn=defaults,ou=SUDOers,dc=ordix,dc=de
objectClass: top
objectClass: sudoRole
cn: defaults
description: Standard sudo Optionen
sudoOption: always_set_home
sudoOption: env_reset
sudoOption: log_host
sudoOption: log_year
sudoOption: logfile=/var/log/sudo.log


dn: cn=%users,ou=SUDOers,dc=ordix,dc=de
objectClass: top
objectClass: sudoRole
cn: %users
sudoUser: %users
sudoUser: !joe
sudoHost: nameserver1
sudoHost: nameserver2
sudoCommand: /sbin/mount /cdrom
sudoCommand: /sbin/umount /cdrom
sudoCommand: /sbin/shutdown -[hr] now

uri             ldap://ldap1.ordix.de
sudoers_base    ou=SUDOers,dc=ordix,dc=de
sudo_debug      2

kann aus einer bestehenden Konfigurationsdatei eine LDIF-Datei erstellt werden, die dann in den LDAP-Verzeichnisbaum importiert werden kann. Abbildung 4 zeigt ein Beispiel für eine LDIF-basierte Konfiguration, die nun mit dem Kommando ldapadd importiert werden kann.

In diesem Beispiel wird eine separate Organisationseinheit SUDOers angelegt, um die sudo-Konfiguration von anderen Einträgen getrennt zu verwalten. Mit dem Eintrag cn=defaults können globale sudo-Optionen konfiguriert werden, wie beispielsweise das logfile, indem lokal auf dem System die mit Hilfe von sudo ausgeführten Kommandos protokolliert werden.

Mit dem Eintrag cn=%users wird allen Mitgliedern der Gruppe users - außer joe - auf den Servern nameserver1 und nameserver2 das Recht gegeben, das CD-ROMLaufwerk zu mounten bzw. zu unmounten und den Server herunter zu fahren bzw. neu zu starten.

Anpassung der Clients

Nun müssen die sudo-Clients von dem LDAP-Server erfahren. Hierzu wird auf dem Client lokal die Datei /etc/ldap.conf bearbeitet bzw. neu angelegt. sudo_debug ist bei der Fehlersuche hilfreich, sollte bei erfolgreichem Betrieb aber auf 0 gesetzt werden. Die Datei sollte dem Benutzer root gehören und auch nur für ihn Leserechte besitzen. Die alte Datei /etc/sudoers könnte jetzt vom System entfernt werden.

Möchte man allerdings einen Fallback-Mechanismus realisieren, welcher bei Netzwerkausfall greift, lässt man sie lokal bestehen. Die Datei wird dann automatisch genutzt, falls der LDAP-Server nicht erreichbar sein sollte. Das Kommando sudo -l sollte nun die Kommandos anzeigen, die der aufrufende Benutzer ausführen darf.

Resümee

Wie in diesem und dem letzten ORDIX News Artikel berichtet, bietet OpenLDAP 2.3 einige neue Funktionen, die die Administration vor allem von größeren Netzwerken mit mehreren LDAP-Servern erleichtern.

Die in der Ausgabe 4/2007 beschriebenen overlays bieten modulare Möglichkeiten, den LDAP-Server um Funktionen zu erweitern, ohne ihn neu zu kompilieren. Die hier beschriebene Konfiguration zur Laufzeit erweitert die Administration, ohne dass lästige Neustarts der Dienste erforderlich werden.

Die Integration der sudo-Verwaltung ist nur ein Beispiel von vielen, wie man die Konfiguration zentral im LDAP verwaltet. Weitere Möglichkeiten sind zum Beispiel die Pflege der E-Mail-Adressen, die Verwaltung von Radiusbenutzern oder die Verwaltung der DHCP/DNS-Daten innerhalb von LDAP.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen