Ferner hatte ich auf diesem Server die YaST2-Clients zur Anwenderverwaltung eingerichtet. In diesem Zusammenhang hatten wir neben der Konfigurationsdatei

“/etc/openldap/ldap.conf”

auch die wichtige Konfigurationsdatei

“/etc/ldap.conf”

für PAM und NSS betrachtet. Allerdings haben wir die User- und Gruppenverwaltung bislang nur lokal auf dem LDAP-Server selbst durchgeführt und getestet. Server- und Client-System waren also identisch.

In diesem Beitrag erinnern wir deshalb an die Skizze am Anfang des LDAP II-Artikels. Unser nächstes Ziel ist es, einen Zugriff auf den LDAP-Server von einem echten Opensuse 12.1-Client-System aus zu realisieren. Dieser Client sei im lokalen Testnetz unter der Adresse “vms1.anracona.de” erreichbar.

Wir wollen auf dem System “vms1″ natürlich auch wieder die YaST2-Tools zur Anlage von User- und Gruppenaccounts benutzen. Diese Accounts sollen aber nicht lokal, sondern auf dem LDAP-Server hinterlegt werden. Wir benötigen also einen TLS-geschützten Zugriff von LDAP-Clients des Systems “vms1″ auf den LDAP-Server “vms2″.

Die im letzten Beitrag bereits durchgeführte Einrichtung der YaST2-LDAP-Client-Module sowie der YaST2-User- und Gruppen-Verwaltung auf dem Server sah sehr generisch aus. Wir vermuten daher zu Recht:

Auf dem System “vms1″ können wir im Prinzip ähnlichen Schritten zur Einrichtung der YaST2-LDAP-Module folgen wie bei der Einrichtung des YaST2-LDAP-Clients und der YaST2-Benutzerverwaltung auf dem LDAP-Server selbst.

Damit wir dabei aber auch etwas Neues kennenlernen, werden wir uns in diesem Beitrag zusätzlich folgende Punkte genauer ansehen:

• Templateartige und opensuse-spezifische Vorgaben für die Anlage von Usern- und Gruppen. Zentrale Hinterlegung der Vorgaben auf dem LDAP-Server und Ort der entsprechenden Einträge im LDAP-Verzeichnisbaum. Änderung der Vorgaben per YaST2.
• LDAP-Einträge in den Konfigurationsdateien für PAM und NSS

Ein später nachfolgender Beitrag “LDAP IV” widmet sich dagegen einer zentralen Passwort-Politik, die wir auf dem LDAP-Server einrichten sowie Fragen der Absicherung des Servers gegenüber Logins von beliebigen Usern, die im LDAP-System hinterlegt wurden.

Konfiguration des YaST-LDAP-Clients auf dem externen System “vms1″

Schritt 1: Beschaffung des CA-Zertifikats

Wir gehen hier unter YaST2 völlig analog zu den Schritten vor, die ich im Beitrag LDAP I unter dem Schritt 4 und im Beitrag LDAP II unter dem dortigen Schritt 3 beschrieben habe. Im Unterschied zur Ersteinrichtung der LDAP-Clients auf dem Server (s. LDAP I) berücksichtigen wir hier aber von vornherein die Nutzung von TLS.

Die auszufüllenden Masken geben wir hier nicht erneut vollständig wieder. Wir betrachten nur die wichtigsten:

Unser Server ist in unserem Beispiel natürlich nach wie vor das System “vms2.anracona.de” (und nicht “vms1″ !). Auch die “LDAP Base DN” ist natürlich identisch zu der, die wir bei der Client-Einrichtung auf dem Server eingetragen hatten.

Eine wichtige Ausnahme zum bisherigen Vorgehen gibt es allerdings auf der Maske

“Advanced Configuration >> Reiter Administration Settings”

des LDAP-Clients:

Wichtiger Hinweis 1:
Der Haken bei “Home Directories on This Machine” ist unbedingt erforderlich. Wir wollen ja, dass die Home-Verzeichnisse definitiv auf dem System “vms1″ angelegt werden - und nicht sonst wo (etwa auf dem LDAP-Server “vms2″) oder evtl. gar nicht.

Wichtiger Hinweis 2:
Wir setzen keinen Haken beim Punkt “Create Default Configuration Objects” ! Dadurch würden wir auf dem Server “vms2″ bereits durchgeführte Konfigurationen zur Anlage von User- und Gruppen Accounts ggf. überschreiben. Was das bedeutet, werden ich weiter unten (s. Schritt 1.4) beschreiben.

Erwartungsgemäß benötigen wir für den Aufbau von TLS-Verbindungen der YaST2-LDAP-Clients und der PAM/NSS-Komponenten vom System “vms1″ zum Server “vms2″ auch Kopien von Zertifikaten. Der Ablageort dieser Zertifikate muss natürlich auch auf dem System “vms1″ in die Konfigurationsmasken eingetragen werden. Wir nehmen der Einfachheit halber auch hier das lokale Verzeichnis “/etc/openldap” (auf “vms1″):

Welche Art von Zertifikatsdateien benötigen wir? Brauchen wir überhaupt mehrere?

Ohne großes Nachdenken tippen wir mal darauf, dass uns der LDAP-Server im Rahmen des TLS- Verschlüsselungsdialogs sein eigenes Server-Zertifikat übermitteln wird, damit wir auf “vms1″ seine Authentizität überprüfen können. In unserem Beispiel liegt das Server-Zertifikat auf dem Server “vms2″ - und dort in der Datei “/etc/openldap/vms2_cert.pem”. Dieses Zertifikat wird auf dem Client-System nicht benötigt.

Für die Überprüfungsprozesse, die LDAP-Client-Module auf “vms1″ bzgl. des Server-Zertifikats von “vms2″ durchführen, müssen wir jedoch angeben, welchen CA-Authorities (bis hin zu Root-CA) das System “vms1″ dabei vertrauen soll.

Hinweis:
Dies ist in unserem Testbeispiel umso wichtiger, als es sich bei “vms2_cert.pem” im Kern ja um ein “self-signed” Zertifikat für den LDAP-Server handelt. Denn es wurde ja gerade von einer Root-CA ausgestellt, die auf dem LDAP-Server “vms2″ beheimatet ist.

Dieser Root-CA muss unser Client-System im Testnetz also explizit vertrauen. Wodurch identifizieren wir auf dem Client aber die CA? Natürlich durch ihr eigenes Zertifikat! Wir benötigen also das Zertifikat “anracona_vms2.pem” unserer Root-CA. Genauer müsste man eigentlich sagen: Die Zertifikate der für das Serverzertifikat “vms2_cert.pem” des LDAP-Server ausschlaggebenden CA-Authorities. Wären in einem realistischeren Beispiel mehrere hierarchische CAs involviert gewesen, so würden wir alle Zertifikate der CA-Kette benötigen!

In unserem einfachen Fall müssen wir also die Datei “/etc/openldap/anracona_vms2.pem” vom Server auf unser Clientsystem kopieren. Wir können dies z.B. mit “scp” erledigen, wenn wir openssh auf beiden Systemen installiert haben.

Auf dem Server “vms2″:

vms2:~ # scp /etc/openldap/anracona_vms2.pem root@vms1.anracona.de:/etc/openldap/

Im realen Leben würden wir das Zertifikat der Root-CA dagegen für unseren Client von einem LDAP-Server herunterladen. Danach versehen wir die Zertifikatsdatei auf dem Clientsystem “vms1″ mit passenden Zugriffsrechten:

vms1:~ #: chown ldap.ldap /etc/openldap/anracona_vms2.pem
vms1:~ #: chmod 644 /etc/openldap/anracona_vms2.pem

Schritt 2: Die Datei “/etc/openldap/ldap.conf”

Wir erinnern uns, dass die Einstellungen, die YaST2 bei der Einrichtung der LDAP-Client-Fähigkeit vornimmt, sich an mehreren Stellen auf die Konfiguration des Opensuse-Systems auswirken (u.a. in den Dateien “/etc/openldap/ldap.conf” und “/etc/ldap.conf”).

Zunächst sehen wir uns mal die benötigten Einträge in der Datei “/etc/openldap/ldap.conf” des Clients “vms1″ an.

Diese Datei steuert systemweit Standard-LDAP-Zugriffsverfahren (vergl. mit dem Beitrag LDAP II). Hier Auszüge aus dem Datei-Inhalt für das System “vms1″:

/etc/openldap/ldap.conf

base dc=anracona,dc=de
uri ldap://vms2.anracona.de
ldap_version 3
ssl start_tls
TLS_CACERTDIR /etc/openldap
TLS_CACERT /etc/openldap/anracona_vms2.pem
TLS_REQCERT allow

Über den Parameter “uri” wird die Adresse des LDAP-Servers angegeben. Einen speziellen Port geben wir dabei nicht an. Stattdessen sorgt die Zeile

ssl start_tls”

dafür, dass eine TLS-geschützte Verbindung über den Standard-LDAP-Port 389 initialisiert wird. Bzgl. der übrigen Parameter werfen wir zur Vervollständigung unseres Wissens auch mal einen Blick in die man-Seiten. Es folgen Ausschnitte:

URI
Specifies the URI(s) of an LDAP server(s) to which the LDAP library should con-
nect. The URI scheme may be any of ldap, ldaps or ldapi, which refer to LDAP over
TCP, LDAP over SSL (TLS) and LDAP over IPC (UNIX domain sockets), respectively.
Each server’s name can be specified as a domain-style name or an IP address lit-
eral. Optionally, the server’s name can followed by a ‘:’ and the port number the
LDAP server is listening on. If no port number is provided, the default port for
the scheme is used (389 for ldap://, 636 for ldaps://).
 
TLS_CACERT
Specifies the file that contains certificates for all of the Certificate
Authorities the client will recognize.
 
TLS_CACERTDIR
Specifies the path of a directory that contains Certificate Authority cer-
tificates in separate individual files. The TLS_CACERT is always used
before TLS_CACERTDIR. This parameter is ignored with GnuTLS.
 
TLS_REQCERT
Specifies what checks to perform on server certificates in a TLS session,
if any. The can be specified as one of the following keywords:
 
never The client will not request or check any server certificate.
 
allow The server certificate is requested. If no certificate is provided,
the session proceeds normally. If a bad certificate is provided, it
will be ignored and the session proceeds normally.
 
try The server certificate is requested. If no certificate is provided,
the session proceeds normally. If a bad certificate is provided, the
session is immediately terminated.
 
demand | hard
These keywords are equivalent. The server certificate is requested.
If no certificate is provided, or a bad certificate is provided, the
session is immediately terminated. This is the default setting.

Aha, an den Werten für den Parameter “TLS_REQCERT” erkennen wir, dass es durchaus unterschiedliche “Level” für den Umgang mit dem Zertifikat des Servers gibt. Wir können in unser Testkonfiguration nun durchaus mal die Einstellung “demand” ausprobieren und sehen, ob auf dem Client “vms1″ das Absetzen eines Kommandos der Art:

vms1:~ # ldapsearch -b dc=anracona,dc=de uid=* -x -D “cn=Administrator,dc=anracona,dc=de” -W -xLLL -ZZ

funktioniert. Bzgl. der Parameter siehe die man-Seiten zu “ldapsearch”. (Zitat: “-Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be successful.” / Zum Beobachten des Zertifikatsaustausches kann man die Option -d2 anschließen.)

Die Durchführung des “ldapsearch-Kommandos” sollte in unserer Testkonfiguration anstandslos Ergebnisse für die bereits eingetragenen User liefern. Damit haben wir auch gleich unseren ersten Test für die Client-Anbindung hinter uns gebracht. Normale LDAP-Operationen funktionieren zwischen unseren Opensuse-Systemen bereits.

Schritt 3: Die Datei “/etc/ldap.conf”

Wir erinnern uns daran (siehe Beitrag “LDAP II), dass diese Datei unter Opensuse 12 für die Anbindung von PAM und NSS an LDAP zu steuern. Wir sehen uns nur die Parameter an, die von Standardeinstellungen abweichen. Weitere Informationen zu den einzelnen Parametern liefern die man-Seiten zu “/etc/ldap.conf”.

/etc/ldap.conf

# The distinguished name of the search base.
base dc=anracona,dc=de
 
# Reconnect policy:
# soft: return immediately on server failure
bind_policy soft
 
# Search the root DSE for the password policy (works
# with Netscape Directory Server). Make use of
# Password Policy LDAP Control (as in OpenLDAP)
pam_lookup_policy yes
 
# Use the OpenLDAP password change
# extended operation to update the password.
pam_password exop
 
# returns NOTFOUND if nss_ldap’s initgroups() is called
# for users specified in nss_initgroups_ignoreusers
# (comma separated)
nss_initgroups_ignoreusers root,ldap
 
# Enable support for RFC2307bis (distinguished names in group
# members)
nss_schema rfc2307bis
 
# configure –enable-nds is no longer supported.
# NDS mappings
nss_map_attribute uniqueMember member
 
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
ssl start_tls
uri ldap://vms2.anracona.de
ldap_version 3
pam_filter objectClass=posixAccount
 
# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap’s default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for
# OpenLDAP 2.0 and earlier is “no”, for 2.1 and later is “yes”.
#tls_checkpeer yes
 
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is “yes”
tls_cacertdir /etc/openldap
tls_cacertfile /etc/openldap/anracona_vms2.pem

Einige Einträge sind offenkundig ganz ähnlich zu den Einträgen in der “/etc/openldap/ldap.conf”. Einige sind jedoch auch spezifisch:

Die Einstellung “soft” des Parameters “bind_policy” bedeutet nach den man-Seiten und der Quelle “http://linux.die.net/man/5/nss_ldap“, dass kein Reconnect (mit erheblicher Zeitverzögerung) versucht wird, wenn ein (initialer) Connect-Versuch gemäß der NSS-Anweisungen fehlschlägt.

bind_policy
Specifies the policy to use for reconnecting to an unavailable LDAP server. The default is hard_open, which reconnects if opening the connection to the directory server failed. By contrast, hard_init reconnects if initializing the connection failed. Initializing may not actually contact the directory server, and it is possible that a malformed configuration file will trigger reconnection. If soft is specified, then nss_ldap will return immediately on server failure. All “hard” reconnect policies block with exponential backoff before retrying.

“Hard”-Einstellungen für diesen Parameter können also problematisch werden; siehe auch :
http://www.held.org.il/blog/2008/09/ldap-default-bindhard-policy-is-problematic/
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-02/msg01126.html
https://bugzilla.redhat.com/show_bug.cgi?id=502072

Ganz unten sehen wir wieder die Einstellungen für die Zertifikate, denen zu vertrauen ist. Bzgl. des “tls_cacertdir”-Wertes siehe die entsprechenden Ausführungen im früheren Beitrag LDAP II.

Die Bedeutung des Parameters “tls_checkpeer” ergibt sich aus der in der Datei unmittelbar darüber stehenden Erläuterung. Wir können das Kommentarzeichen vor diesem Parameter in unserer Testumgebung auch mal versuchsweise entfernen und den Wert auf “yes” setzen. Das sollte zu keinen Problemen führen.

Interessanter sind die Parameter “pam_password” und “pam_lookup_policy”.

Unter der Web-Adresse http://karmak.org/archive/2003/02/ldap/ldap-linux.htm

lesen wir:

“The directive “pam_password exop” tells pam-ldap to change passwords in a way that allows OpenLDAP to apply the hashing algorithm specified in /etc/ldap/slapd.conf, instead of attempting to hash locally and write the result directly into the database.”

Tja, nun hatten wir ja schon früher gesehen, dass es die “slapd.conf”-Konfigurationsdatei unter Opensuse gar nicht mehr gibt!

Jetzt könnte man unbedarft versuchen, auf dem Opensuse LDAP-Server in dessen modularen Konfigurationsdateien einen Eintrag für ein Standard-Hash-Verfahren des LDAP-Servers zu finden. Also einen Eintrag der Art “password-hash {SHA},{SSHA}”, wie es ihn früher in der guten alten “slapd.conf” gab.

Eine Suche der Art

vms2:/etc # grep -d recurse hash /etc/openldap/

liefert aber nur Kommentarzeilen aus diversen Schema-Dateien. Deshalb stellen sich jetzt folgende Fragen:

• Woher wissen die Yast2-Userverwaltung auf “vms1″ und der LDAP-Server eigentlich, welches Passwort-Verschlüsselungsverfahren bei der Anlage der Userdaten auf einem LDAP-Server angewendet werden soll?
• Woher kennt die YaST-Userverwaltung für LDAP auf “vms1″ eigentlich die nächste lfd. UID-Nummer, die bei der Anlage eines neuen Users verwendet werden soll, wenn die Nummern der bisher angelegten User doch auf dem LDAP-Server liegen?
• Woher erfährt das YaST2-Modul zur Anlage von Usern eigentlich das Skeleton-Verzeichnis oder andere Standarddaten, die bei der Neuanlage eines Users berücksichtigt werden sollen?
• Wie zentralisiert man eigentlich die Standarddaten für die Anlage von Useracounts über mehrere Systeme hinweg?
• Wo wurde eigentlich festgelegt, dass User-Daten auf unserem Testsystem im LDAP-Baum unter “ou=people,dc=anracona,dc=de” angelegt werden sollen ?

Vielleicht ist man nun durch diese Fragen verunsichert worden und bezweifelt, dass die YaST2-Benutzerverwaltung auf dem System “vms1″ überhaupt funktioniert. Höchste Zeit also für die testweise Anlage einiger Testuser auf dem System “vms1″.

Die Möglichkeit zur YaST2-gestützten Useranlage unter Hinzuziehung des LDAP-Servers erhalten wir, wie in den früheren Beiträgen beschrieben, auch auf dem System “vms1″ über folgende Maske der YaST2-Benutzerverwaltung und die Wahl des Filters “LDAP-Users”:

Dort drücken wir auf den Button “Add” und nehmen in den nachfolgenden Masken die erforderlichen Einträge vor. Auf der Maske “Details” erkennen wir dabei übrigens, dass auf wundersame Weise automatisch die nächste freie Nummer für den Testuser gewählt wird.

Ohne hier alle Schritte vorzuführen, endet unser Test der Useranlage mit YaST2 auch auf “vms1″ erfolgreich:

• die Kommunikation unserer YaST2-Benutzerverwaltung auf “vms1″ mit dem LDAP-Server “vms2″ funktioniert,
• unter dem Zweig “ou=people,dc=anracona,dc=de” werden im LDAP-Verzeichnis auf “vms2″ die erforderlichen User-Einträge angelegt,
• auf “vms1″ (und nicht etwa auf vms2) werden die Home-Verzeichnisse für die neuen User korrekt angelegt und
• jeder neu mit YaST2 von “vms1″ aus angelegt User kann sich auf “vms1″ auch einloggen.

Offenbar haben wir “vms1″ richtig konfiguriert. Ein Blick mit dem LDAP-Browser auf “vms2″ zeigt denn auch die angelegten Testuser an:

Studiert man nun die User-Einträge unter dem Ast “ou=people,dc=anracond,dc=de” des LDAP-Verzeichnisses genauer, so findet man bzgl. der Passwortverschlüsselung Feldeinträge der Form:

userPassword {ssha}dMU9M69W………

Es wurde also SSHA als Hash-Verfahren für die Passwortverschlüsselung herangezogen. Gehen wir dagegen auf die Passworteinstellungen der YaST2-Userverwaltung (Expert-Options >> Password Encryption) auf dem System “vms1″, so finden wir dort überraschenderweise jedoch Folgendes:

Opensuses’s YaST ist nach einer Standardinstallation eigentlich auf MD5 als Hashverfahren eingestellt! Unseer Fragenkatalog von obeen erweiter sich also um die Frage:

• Woher also kommt also die SSHA-Einstellung für das LDAP-System?

Um diese Frage und auch die anderen offen gebliebenen Fragen zu beantworten, müssen wir auf einen Punkt aus dem Beitrag “LDAP I” zurückkommen, der SuSE-spezifisch ist und auf den wir bislang nicht eingegangen sind.

Schritt 4: Opensuse-spezifische Konfigurationsvorgaben und Templates für die Anlage von Usern und Gruppen

Im Beitrag “LDAP I” hatten wir in folgender Maske zur Einrichtung der YaST2-LDAP-Clients auf “vms2″

die Option “Create Default Configuration Objects” gesetzt.

Läßt man dies bei der Einrichtung eines anderen LDAP-Servers testweise weg und legt später User an, so wird man u.a. feststellen, dass die User Accounts dann keineswegs unter dem LDAP-Verzeichniszweig

“ou=people,dc=anracona,dc=de”

angelegt werden. Diesen Zweig gibt es dann nicht einmal ! Im LDAP-Baum würde die Anlage von Informationen zu User Accounts in einer solchen Situation vielmehr direkt unter der Base-DN erfolgen, was aus einer Reihe von Gründen natürlich nicht erstrebenswert wäre.

Die Option “Create Default Configuration Objects” bei der Konfiguration des LDAP-Clients scheint also dazu zu führen, dass YaST2 während der Einrichtung des LDAP-Clients auf dem LDAP-Server (!) einige Standardeinstellungen vornimmt und dabei auch bestimmte Äste des LDAP-Baums einrichtet.

Ein Blick mit dem YaST2-LDAP-Browser offenbart denn auch, was so alles während unserer LDAP-Einrichtung angelegt wurde:

Zunächst stellen wir fest, dass es drei interessante “ou-Zweige” gibt:

• ou=people
• ou=ldapconfig
• ou=group

(Der darüber liegende Eintrag “cn=Default Policy” ist übrigens kein Standardeintrag. Wie dieser Eintrag auf meinem Testsystem “vms2″ entstanden ist, bespreche ich im Beitrag “LDAP IV”.)

Unter dem Zweig “ou=people” hinterlegt die YaST-Userverwaltung offenbar die Informationen zu User Accounts, unter “ou=group” die Informationen zu Group Accounts. Für die User hatten wird dies im Beitrag “LDAP II” bereits explizit gesehen. Dass das auch für Gruppen gilt, kann jeder selbst durch Anlegen entsprechender Test-Accounts für Gruppen verifizieren.

Von größerem Interesse ist aber der Bereich “ou=ldapconfig”. Dort wurden von YaST2 bei unserer initialen Konfiguration des “LDAP-Clients” auf dem System “vms2″ (s. LDAP I) offenbar schablonen- und templateartige Informationen als Vorgaben für die Anlage von User- und Group-Accounts angelegt. Ein Blick auf die Felder der “cn”-Einträge

• cn=groupconfiguration
• cn=grouptemplate
• cn=userconfiguration
• cn=usertemplate

ist wirklich ganz instruktiv. Man erkennt sofort, dass die Inhalte tatsächlich in etwa den Informationen entsprechen, die man bei einer manuellen Verwendung von “useradd” bzw. “usermodify” auf Standardsystemen auch anlegen bzw. modifizieren würde.

U.a. finden wir in den genannten LDAP-Einträgen auch die vorhin gesuchte Vorgabe zur Verwendung von SSHA als Hash-Verfahren für die User-Passwörter sowie eine Vorgabe für das Skeleton-Verzeichnis.

Auch die zuletzt benutzte UID-Nr und GID-Nr. werden bei der Anlage neuer Accounts auf dem LDAP-System in Feldern der Einträge “userconfiguration” und “groupconfiguration” neu eingetragen.

Die Struktur der Einträge entspricht übrigens einem spezifischen LDAP-Schema, das bei der Einrichtung des LDAP-Servers von YaST2 mit angelegt wurde, nämlich dem “yast”-Schema.

Dies bestätigen ein Blick in das Konfigurationsverzeichnis “/etc/openldap/slapd.d/ ”

sowie zusätzliche Blicke in die Dateien

• /etc/openldap/slapd.d/cn=config/cn=schema/cn={4}yast.ldif” und
• Die YaST2-Client-Anwendungen zur Userverwaltung holen sich diese Daten im Vorfeld einer Account-Einrichtung oder -Änderung also vom LDAP-Server selbst ab. (Faktisch geschieht dies bei der Setzung des Filters für das Account-Backend auf “LDAP User” oder “LDAP Group” (Button “Set Filter” in den Masken zur User- und Gruppenverwaltung).

Die Antworten auf die oben gestellten Fragen liegen also in den Tiefen von YaST2 und den dort in ycp-Scripts verankerten Ideen von Opensuse zur Account-Verwaltung und einem spezifischen “yast”-LDAP-Schema.

YaST’s ycp-Scripts fragen im Zuge der User- und Gruppen-Verwaltung im LDAP-System dort hinterlegte Instruktionen zur User- und Gruppen-Anlage ab. Bei der Konfiguration des YaST2-LDAP-Clients hingegen werden durch ycp-Scripts auf dem LDAP-Server bestimmte Verzeichnis-Zweige angelegt und Einträge mit Vorgaben zur User- und Gruppen-Anlage hinterlegt.

Tatsächlich findet man nach ein wenig Recherche in der Datei “/usr/share/YaST2/modules/Ldap.ycp” auch die Codezeilen für diejenigen Informationen, die bei der initialen Anlage der Vorgaben zu User- und Gruppenaccounts unter “ou=ldapconfig” von den YaST2-Konfigurationsskripts herangezogen werden:

Nun fragt man sich als nächstes, ob und wo man diese Standardeinstellungen für die account-bezogenen Configuration- und Template-Vorgaben ändern kann.

Auch dies geschieht natürlich über YaST2 und zwar im YaST2-Modul “LDAP-Client”.

Auf der Einstiegsmaske “LDAP Client Configuration” nutzt man den Button “Advanced Configuration”, geht auf der nächsten Maske in den Reiter “Administration Settings” und klickt dort auf den Button “Configure User Management Settings”. Auf der nachfolgenden Maske hat man alle Möglichkeiten zum Überschreiben der Werte für die User- und auch der Gruppenkonfiguration sowie der zugehörigen “Templates” :

Diese Änderungen kann per YaST2 man von jedem System aus vornehmen, das den LDAP-Server als Backend für die User- und Gruppenverwaltung verwendet.

Inzwischen wird wohl auch ein wenig klar, wie man mittels YaST2 und LDAP eine (in diesem Stadium einfache!) systemübergreifende User- und Gruppenverwaltung hinbekommt, die zumindest elementaren Bedürfnissen ganz gut gerecht wird.

Grundsätzlich finde ich das Opensuse-Vorgehen zur User- und Gruppenverwaltung mit YaST2 und LDAP ja für eine Basisausstattung und einfache Situationen hinreichend und clever. Aber zwei Dinge stören mich doch ganz erheblich:

• Weder aus den YaST-Masken selbst noch aus den zugehörigen Hilfeseiten ist ersichtlich, was die “Default Configuration Objects” sind und wo sie hinterlegt werden. Die Bezeichnung “LDAP Client” verführt geradezu zu der Annahme, dass auch hierbei nur Einstellungen auf dem Client vorgenommen werden - was aber offenkundig falsch ist.
• Wenn man den LDAP-Server als Backend für die User- und Gruppenverwaltung von mehreren Systemen aus verwendet, so kann man mit dem YaST”-LDAP-Client-Modul von jedem System aus die Vorgaben unter “ou=ldapconfig” auf dem zentralen Server überschreiben.

  Blöderweise gilt dies auch während der initialen Konfiguration des YaST2 LDAP-Client Moduls auf einem jeden neuen System, das an den LDAP-Server angebunden werden soll. Setzt man hier versehentlich den Haken bei der Option “Create Default Configuration Objects”, so werden die bisherigen, auf dem LDAP-Server gepflegten User- und Gruppen-Konfigurationsoptionen erneut durch die Default-Einstellungen überschrieben.

  Daher ist mein obiger Hinweis, diesen Haken bei der Einrichtung von “vms1″ nicht zu setzen, wichtiger als man zunächst vielleicht meinen möchte!

NSS und PAM auf dem System “vms1″ und ihr Zusammenspiel mit LDAP

NSS-Konfigurationsdatei für LDAP

Bereits im Beitrag LDAP II hatten wir festgestellt, dass das YaST2-Module “LDAP Client” offenbar auch Einstellungen für PAM und NSS vornimmt. Bislang hatten wir nur die Datei “/etc/ldap.conf” betrachtet. Es ist aber auch ganz lehrreich, mal einen Blick in ein paar andere NSS- und PAM-spezifische Dateien auf dem System “vms1″ zu werfen.

Sehen wir als erstes in die Datei “/etc/nsswitch.conf”:

/etc/nsswitch.conf

passwd: compat
group: files ldap
 
hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns
 
services: files ldap
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files ldap
publickey: files
 
bootparams: files
automount: files nis
aliases: files ldap
passwd_compat: ldap

Grundlegende Informationen zum Aufbau dieser Konfigurationsdatei zum NSS-Service findet man unter:

http://cims.nyu.edu/cgi-systems/man.cgi?section=4&topic=nsswitch.conf
http://serverfault.com/questions/289933/pam-nsswitch-and-ldap-configuration
http://cims.nyu.edu/cgi-systems/man.cgi?section=4&topic=passwd

Wir stellen fest, dass Opensuse bereits (vorsorglich?) für einige der eingetragenen Punkte “ldap” vorgemerkt hat, obwohl z.T. noch gar keine entsprechenden Informationen im LDAP-Baum vorhanden sind. Dadurch lassen wir uns nicht beunruhigen. Wir kümmern uns zunächst um die Einträge

• passwd: compat
• group: files ldap
• passwd_compat: ldap

Hierzu ist zu sagen, dass Opensuse - vermutlich aus Rücksichtnahme auf Installationen mit vorhandenem NIS eine ältere Variante des Zugriffs auf “ldap” hinsichtlich der Passwörter über den Parameter “passwd: compat” und ein anschließendes “passwd_compat: ldap” vornimmt.

Der NSS-Service erwartet dann in der Datei “/etc/passwd” eine Zeile der Form

+::::::

und in “/etc/shadow” eine Zeile

+

vorzufinden, was tatsächlich auch der Fall ist.

Die Platzhalter stehen für Einträge aus NIS und eben auch LDAP-Quellen.

Zur Prüfung, dass die Abfrage-Kette

• Durchsuche die Datei “/etc/passwd/” und
• gehe dann zusätzlich auf LDAP

funktioniert, bietet sich auf “vms1″ das Absetzen des Befehls “getent passwd” an. Man bekommt dann alle passwd-Einträge aber auch alle Einträge auf dem LDAP-Server aufgelistet:

vms1:~ # getent passwd
at:x:25:25:Batch jobs daemon:/var/spool/atjobs:/bin/bash
…
…
…
rmx:x:1000:100:rmx:/home/rmx:/bin/bash
rmo:*:1004:100:rmo:/home/rmo:/bin/bash
rmu:*:1005:100:rmu rmu:/home/rmu:/bin/bash
rmv:*:1006:100:rmx rmx:/home/rmv:/bin/bash
vms1:~ #

Der einzige auf dem Test-System regulär eingetragene User ist rmx, die anderen User-Einträge kommen vom LDAP-Server “vms2″.

Alternativ hätte es natürlich auch die etwas modernere Variante gegeben, in der Datei “nsswitch.conf” den LDAP-Zugriff für “passwd” zu gestalten, nämlich:

passwd: files ldap

Das funktioniert auf einem System ohne NIS genauso, nur sollte man dann auch die Platzhalterzeilen “+::::::” bzw. “+” in “/etc/passwd” bzw. “/etc/shadow” eliminieren. Das mag jeder mal selbst ausprobieren.

Interessant ist, dass Opensuse im Gegensatz zu früheren Veröffentlichungen

http://www.pks.mpg.de/~mueller/docs/suse10.0/suselinux-manual_de/manual/sec.ldap.yast.client.html

oder

http://www.linuxtopia.org/online_books/suse_linux_guides/SLES10/suse_enterprise_linux_server_installation_admin/sec_ldap_yast_client.html)

für die Gruppen einen analoge “compat”-Politik nicht mehr verfolgt. Hier wird das modernere Verfahren eingesetzt.

In professionellen Umgebungen mit vielen hundert Usern würde es laufend entsprechend viele Netzwerkzugriffe auf den LDAP-Server geben. Um das zu vermeiden, sollte man auf den Systemen den Daemon für den sog. “Name Service Cache”-Service - kurz “NSCD” - starten. Unter Opensuse ist das vorkonfiguriert. Die zugehörige Konfigurationsdatei findet man auf “vms1″ unter “/etc/nscd.conf”. Ob der Dienst läuft, kann man mit “rcnscd status” prüfen.

PAM-Konfigurationsdateien für LDAP auf “vms1″

Wir setzen nachfolgend ein Grundverständnis von PAM voraus. Eine erste Übersicht gibt
http://www.comptechdoc.org/os/linux/howlinuxworks/linux_hlpam.html

Einen instruktiven Foliensatz findet man unter
http://www.linuxcampus.net/component/remository/func-startdown/56/?Itemid=186

Für PAM allgemein und für die PAM-Konfiguration zu SSHD findet man erste Übersichtsinformationen unter
http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.0/suselinux-manual_de/manual/cha.pam.html

Details zu einigen PAM-Modulen entnimmt man dem “Linux-PAM System Administrators’ Guide”
http://webapp5.rrz.uni-hamburg.de/SuSe-Dokumentation/packages/pam/pdf/Linux-PAM_SAG.pdf

Die wichtigsten PAM-Konfigurationsdateien für sicherheitsrelevante Services findet man im Verzeichnis “/etc/pam.d”. Welche dieser Konfigurationsdateien enthalten Einträge bzgl. LDAP?

Unter Opensuse werden einige zentrale Dateien in die Konfigurationsdateien der einzelnen sicherheitsrelevanter Services inkludiert. Diese zentralen Dateien (meist als Link auf eine weitere Datei ausgelegt) sind die folgenden:

• /etc/pam.d/common-auth
• /etc/pam.d/common-account
• /etc/pam.d/common-password
• /etc/pam.d/common-session

Uns verwundert es daher nicht, dass LDAP-Module genau in diesen Dateien aufgerufen werden:

vms1:~ # grep -d recurse ldap /etc/pam.d/

/etc/pam.d/common-auth:auth required pam_ldap.so use_first_pass
/etc/pam.d/common-auth-pc:auth required pam_ldap.so use_first_pass
/etc/pam.d/common-account-pc:account required pam_ldap.so use_first_pass
/etc/pam.d/common-password-pc:password required pam_ldap.so try_first_pass use_authtok

/etc/pam.d/common-password:password required pam_ldap.so try_first_pass use_authtok
/etc/pam.d/common-session-pc:session optional pam_ldap.so
/etc/pam.d/common-session:session optional pam_ldap.so
/etc/pam.d/common-account:account required pam_ldap.so use_first_pass
vms1:~ #

Hier wird also an verschiedenen Stellen auf die Shared Object Library “pam_ldap.so” zurückgegriffen, die die erforderlichen Abfragen und die Kommunikation mit dem LDAP-System (auf Basis der “/etc/ldap.conf”-Regeln) für PAM erledigt.

Die genannten zentralen PAM-Dateien des Opensuse-Systems unter “/etc/pam.d/” werden z.B. in der Konfigurationsdateien für den Login-Mechanismus (/etc/pam.d/login) oder SSH (/etc/pam.d/sshd) benutzt. Wir betrachten auf unserem Clientsystem als Beispiel mal die Datei “/etc/pam.d/login”:

/etc/pam.d/login

#%PAM-1.0
auth requisite pam_nologin.so
auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so

session include common-session
session optional pam_lastlog.so nowtmp showfailed

session optional pam_mail.so standard
session optional pam_ck_connector.so

Opensuse wartet hier nicht mit besonderen Überraschungen auf. Eine kurze, prägnante Erklärung zum Aufbau einer PAM-Konfigurationsdatei für den Login-Mechanismus bietet etwa
http://www.selflinux.de/selflinux/html/grundlagen_sicherheit05.html

Man erkennt in unser Datei sofort Elemente der im gerade genannten Link beschriebenen Struktur wieder:

Zuerst wird überprüft, ob die Datei “/etc/nologin” existiert und nur root Zugang zum System haben darf. Danach wird der Root-Zugang über sichere TTYs geregelt. Anschließend wird die Authentizität des Users anhand seienr Credentials überprüft - dies geschieht durch die Elemente der Datei “common-auth”:

/etc/pam.d/common-auth

auth required pam_env.so
auth optional pam_gnome_keyring.so
auth sufficient pam_unix2.so
auth required pam_ldap.so use_first_pass

Man erkennt hier, dass die Anfrage an des LDAP-System gestartet wird, falls eine lokale Prüfung durch das “pam_unix2″-Modul nicht erfolgreich ist (Check Anmeldename und Passwort gegen “/etc/passwd” und “/etc/shadow”). Durch “use_first_pass” ist dafür gesorgt, dass das bereits eingegebene Password an das LDAP-Modul weitergereicht und nicht neu beim User abgefragt wird.

Danach werden Zugangsberechtigungen untersucht, die mit dem Account zusammenhängen - u.a., ob keine Zeitbeschränkungen des Accounts verletzt sind. Die Schlüsselfrage ist: “Gibt es diesen Benutzer im System und darf er sich anmelden?” Ein Blick in “common-account” zeigt auch hier die Abfrage des LDAP-Systems an:

/etc/pam.d/common-acount

account requisite pam_unix2.so
account sufficient pam_localuser.so
account required pam_ldap.so use_first_pass

Damit die erste Bedingung erfüllt wird, müssen die weiter oben erläuterten Verweis-Einträge im NIS-Format in den Dateien “/etc/passwd” und “/etc/shadow” vorhanden sein !

LDAP ist im Zusammenhang mit der Account-Prüfung auch aus folgendem Grund interessant:

The pam_ldap module provides the ability to specify a list of hosts a user is allowed to log into, in the “host” attribute in LDAP. The host attribute can be specified multiple times for each user. If any of the entries match the hostname (of the machine logging in to), login is succesful. Otherwise, login is denied.
 
This feature is enabled by specifying pam_check_host_attr yes in /etc/pam_ldap.conf. When it is enabled, the account facility of pam_ldap will perform the checks and return an error when no proper host attribute is present.

Zitiert nach: http://wiki.debian.org/LDAP/PAM

Das “pam_ldap.so”-Modul kann also untersuchen, ob im LDAP-System eingetragene User bestimmten Hosts zugeordnet sind. Hierdurch kann der Zugriff auf bestimmte Hosts verhindert werden. Mit diesem sicherheitsrelevanten Thema werden wir uns im Beitrag “LDAP - IV” genauer befassen.

Im Anschluss an PAM’s account- und Berechtigungs-Prüfungen kommen Bedingungen an Passwörter zu tragen, die dann von Bedeutung sind, wenn ein User im Login-Vorgang zur Änderung des Passworts gezwungen ist. Das genaue Studium und die Analyse der Bedingungen in “common-password” überlassen wir dem interessierten Leser.

/etc/pam.d/common-acount

password requisite pam_cracklib.so minlen=8
password optional pam_gnome_keyring.so use_authtok
password sufficient pam_unix2.so use_authtok nullok
password required pam_ldap.so try_first_pass use_authtok

Die “Session”-Bedingungen sorgen für eine ordnungsgemäße Sitzungsabwicklung. Hier ein Auszug

session optional pam_mkhomedir.so

session required pam_limits.so
session required pam_unix2.so
session optional pam_ldap.so
session optional pam_umask.so
session optional pam_systemd.so

Wir erkennen an den Namen der Module bereits Aufgaben der involvierten Module:

Falls erforderlich kümmert sich zunächst “pam_mkhomedir.so” beim Login eines neuen Users um die Erzeugung eines Home-Dirs (oder aber um die Umlenkung auf ein Ersatz-Verzeichnis). Pam_unix2 protokolliert in den Logfiles nicht nur den Beginn einer Sitzung, sondern auch deren Ende. Das Modul “limits.so” begrenzt Systemressourcen-Anforderungen, u.a. Hauptspeicherbedarf, CPU-Zeit, Prozesse und Dateien für einzelne Benutzer bzw. Benutzergruppen. User- oder gruppen-spezifische Limit-Einstellungen können in der Konfigurationsdatei “/etc/security/limits.conf” vorgenommen werden. Hinweis: Systemweite Limit-Konfigurationen erfolgen unter Opensuse unter “/etc/sysconfig/ulimit” (s. auch: https://build.opensuse.org/package/show?package=ulimit&project=openSUSE%3A12.1).

Danach werden LDAP-Einträge für Session-Bedingungen abgefragt. Diese Abfrage ist im Gegensatz zu anderen PAM-Bedingungen jedoch optional - das Ergebnis verhindert den Erfolg eines Einloggens in keinem Fall. Es folgen die Prüfung von umask-Regeln und unter Opensuse neuerdings auch von systemd-Regeln.

Ich denke, der Leser hat nun ein gewisses Gefühl dafür bekommen, dass und in welcher Form PAM und LDAP ineinander greifen. Bei Opensuse ist das Ganze (vernünftigerweise?) so organisiert, dass bestimmte erfolgreiche lokale Prüfungen in der Regel hinreichend sind. Erst im negativen Fall wird auf die LDAP-Einträge zur Auth- und Account-Prüfung ausgewichen. Entsprechend Anfragen müssen dann aber auch zu einem positiven Ergebnis führen. Bzgl. der Login-Session-Handhabung sind LDAP-Einträgen nur optional.

Zu beachten ist, dass es in der PAM-Konfiguration, die die YaST2-Module standardmäßig vornehmen, keine einzige “sufficient”-Bedingung im Zshg. mit LDAP-Anfragen gibt.

Nun kann man ja versucht sein, den Ergebnissen von LDAP-Abfragen ein höheres Gewicht zu geben als lokalen Bedingungen. Dies führt typischerweise zu Experimenten, bei denen man die Reihenfolge der PAM-Bedingungen für LDAP-Abfragen und lokale Abfragen umstellt.

Warnung:

Hierbei muss man wirklich genau wissen, was man tut. Im besonderen sind dann auch Kriterien wie “use_first_pass” und “use_authtok” nicht mehr unbedingt in der Zeile zum LDAP-Modul sondern bei den nachfolgenden PAM-Bedingungen anzugeben. Generell gilt, dass ein unvorsichtiges Vorgehen bei der PAM-Konfiguration zu erheblichen Schwierigkeiten bzgl. des Systemzugangs führen kann. Also seid bitte vorsichtig und experimentiert bzgl. PAM nicht an Produktivsystemen herum!

Ich persönlich finde übrigens an der Politik von Opensuse, lokalen Kriterien den Vorrang zu geben, nicht viel auszusetzen.

Wer LDAP-Abfragen dennoch den Vorrang geben will, sollte sich unbedingt die von PADL vorgeschlagenen Standard-Konfigurationen für PAM ansehen

http://oss.sgi.com/LDP/HOWTO/LDAP-Implementation-HOWTO/pamnss.html ,

gründlich analysieren und sich fragen, ob und wie das zum eigenen System passt.

Weniger gefährlich sind entsprechende Tests für die Einstellungen zu SSH in der Datei “/etc/pam.d/sshd”. Siehe hierzu:

(http://quark.humbug.org.au/publications/ldap/system_auth/sage-au/system_auth.html

oder

http://www.linuxlaboratory.org/articles/linux-ldap-client/

Zusammenfassung und offene Punkte

Wir haben in diesem Beitrag gesehen, wie wir ein anderes System (hier “vms1″) an den LDAP-Server anbinden können. Dabei haben wir uns damit befasst, in welcher Form Opensuse auf dem LDAP-Server templateartige Vorgaben zur Anlage von Usern und Gruppen hinterlegt und wie man diese Vorgaben verändert. Ferner haben wir uns über die entsprechenden Konfigurationsdateien auf dem Testsystem ein paar Hinweise dazu geholt, wie das Zusammenwirken von NSS, PAM mit LDAP durch die von YaST2 automatisch vorgenommenen Einstellungen konfiguriert wird.

Im Ergebnis können wir nun mehrere Clientsysteme mit dem LDAP-Server TLS-gesichert verbinden und von jedem Client aus (per YaST2) neue User für die Benutzung des jeweiligen Clients anlegen. Damit haben wir aber immer noch keine wirklich tragfähige zentrale Authentifizierungsstruktur erreicht.

Folgende durchaus sicherheitskritische Fragen sind nämlich offen und sollten von einem verantwortungsbewußten Admin untersucht werden:

• Wie kann ich unter Opensuse auf dem LDAP-Server eine zentrale Passwort-Politik hinterlegen, die für alle LDAP-User gleichermaßen gelten soll?
• Können sich eigentlich User, die man von bestimmten Clientsystemen aus auf dem LDAP-Server (hier “vms2″) angelegt hat, auch auf dem Server “vms2″ selbst einloggen? Oder auf anderen Client-Systemen? Per grafischer Oberfläche oder am Login-Prompt oder per ssh ? Ist ein Login möglich, selbst wenn auf dem System kein Home-Verzeichnis angelegt wurde?
• Wie schütze ich ggf. den Server oder auch andere Systeme gegen den Zugriff von x-beliebigen Usern, die wir im LDAP-Verzeichnis per YaST2 von irgendeinem bestimmten Client-System aus angelegt haben ? Wie begrenze ich den Zugriff eines im LDAP erfassten Users oder einer Gruppe auf bestimmte Hosts?

Auf diese Fragen bietet der nächste Beitrag LDAP IV aus der LDAP-Reihe eine Antwort. Und dann werden wir auch einige Grenzen der Bordmittel von YaST2 zur Interaktion mit einem LDAP-Server erkennen.

Dabei fiel mir auf, dass das gesamte System regelmäßig kurzzeitig hängen blieb - so etwa alle 2-3 Minuten für ca. 1-2 Sekunden, manchmal auch etwa länger. Damit einhergehend traten ungewöhnlich hohe Spikes in der CPU-Belastung mehrerer Prozessor-Cores auf.

Ein wenig Analyse mit “ksysguard” und “ps” zeigte, dass die CPU-Belastung tatsächlich vom Prozess “vmware-vmx” herrührten. Es half auch nichts, die Last mit “taskset” an bestimmte Cores zu binden. Das ziemlich ärgerliche Verhalten des Gesamtsystems war bis einschließlich der Version VMware 8.0.1 nicht aufgetreten.

Nach etwas Recherche in VMwares’s Workstation Forum und anderen Foren schien es so, als ob es unter VMware WS 8.0.2 wohl Probleme mit externen Laufwerken gäbe:

http://forums.techarena.in/windows-software/1431610-2.htm

In Frage kamen in meinem Fall entweder das der virtuellen Maschine zugeordnete Floppy-Laufwerk oder aber eines der DVD-Laufwerke bzw. der DVD-Brenner.

Tatsächlich brachte ein völliges Entfernen der Ressource “Floppy Drive” vom Setup des virtuellen Gastes bei mir die Lösung. (Zusätzlich habe ich beim DVD-Laufwerk die Einstellung auf “autodetect” gesetzt. Das erwies sich aber nach mehreren Tests mit anderen Einstellungen aber als nicht ausschlaggebend.)

Danach verschwanden bei mir die CPU Spitzen und das Gesamtsystem lief wieder glatt und ohne Hänger. Hier hat VMware wohl noch etwas zu tun …..

Im vorhergehenden Beitrag hatte ich dargestellt, wie man einen LDAP-Server ohne TLS unter Opensuse 12.1 mit YaST-Bordmitteln anlegt. Ferner hatte ich gezeigt, wie man danach die lokale YaST2-”User- und Gruppenverwaltung” auf dem Server für die Benutzung des LDAP-Systems einrichtet.

Nun stellen wir den LDAP-Server auf unserem Server-Testsystem “vms2″ auf eine TLS-Absicherung der Kommunikation mit internen und externen Clients um. Danach passen wir zunächst die lokalen YaST2-Clients und PAM zur “User- und Gruppenverwaltung” für einen TLS-Zugriff auf das LDAP-Backend an.

Eine TLS-abgesicherte Kommunikation lokaler LDAP-Clients mit dem LDAP-Server auf ein und demselben System ist aber natürlich nicht das wirkliche Ziel unserer Arbeiten, sondern nur ein Zwischenschritt. Vielmehr wollen wir später von anderen Opensuse-Systemen aus den LDAP-Server zur systemübergreifenden Benutzerverwaltung heranziehen.

Im nächsten Teil “LDAP III” dieser Beitragsserie werden wir deshalb die erforderlichen Client-Konfigurationsschritte auch auf einem anderen externen Opensuse 12.1-System (Testsystem namens “vms1″) vornehmen. Die Yast2-User und Gruppenverwaltung auf dem System “vms1″ wird dann auf unseren LDAP-Server “vms2″ zugreifen. Auch PAM-basierte Login-Versuche auf “vms1″ werden dann über den LDAP-Server des Systems “vms2″ autorisiert werden.

Dadurch erreichen wir letztlich eine rechnerübergreifende Authentifizierung, und die UIDs und GIDs werden systemübergreifend eindeutig. Letzteres ist u.a. auch für Remote-Zugriffe auf Samba- oder NFS-Verzeichnisse wegen der UNIX-Rechtekämme durchaus von Bedeutung. Die Unix-Zugriffsrechte auf Verzeichnisse und Dateien orientieren sich ja an den UIDs und GIDs und nicht an Benutzer- oder Gruppennamen.

Die Client-Konfiguration erfolgt auf einem externen System (hier “vms1″) übrigens völlig analog zu der Konfiguration der lokalen LDAP-Clients auf dem Serversystem “vms2″. Wenn wir die Inhalte dieses Beitrages hinter uns haben, haben wir uns also bereits eine schöne Schablone für das Vorgehen auf externen Systemen erarbeitet.

Kurzdarstellung von TLS / notwendige Zertifikate

TLS stellt ein Verfahren dar, bei dem ein Client mit einem Server zunächst ein asymmetrisches Verschlüsselungs-Verfahren (RSA, Diffie-Hellmann, andere) für eine verschlüsselte Vorkommunikation im Vorfeld eines verschlüsselten Datenaustausches nutzt. Danach ermitteln Client und Server auf Basis ausgetauschter Daten das Geheimnis eines weiteren, symmetrischen Verschlüsselungsverfahrens, welches schließlich für die eigentliche Datenaustausch-Session genutzt wird.

Der Client bietet im ersten Schritt eine Reihe von asymmetrischen Verfahren an und der Server nimmt davon das stärkste. Der Server übermittelt seinen öffentlichen Schlüssel und ein digitales Server-Zertifikat. Der Client überprüft die Identität des Servers gegen eine Certificate Authority (CA), der er vertraut. Mit Hilfe des Public Keys des Servers berechnet der Client je nach gegenseitig vorgesehenem Verschlüsselungsverfahren Schlüssel-(Vor)-Informationen, auf deren Basis dann Server und Client den endgültigen symmetrischen Schlüssel für die Sitzung berechnen und festlegen.

Das Schöne dabei ist, dass man dabei den ganz gewöhnlichen LDAP-Port für die abgesicherte Kommunikation einsetzen kann. Das ist auch als Start-TLS-Verfahren bekannt.

Welche verschlüsselungsrelevanten Daten müssen auf dem LDAP-Server und den LDAP-Clients vorliegen?

• Server: Der LDAP-Server benötigt im einfachsten Fall das Zertifikat der CA als sog. “pem”-Datei.
• Server: Der Server benötigt ferner sein eigenes TLS/SSL-Serverzertifikat, das ihm von der CA ausgestellt wurde.
• Server: Erforderlich sind ferner der zum Serverzertifikat gehörige private Schlüssel und natürlich auch der öffentliche Schlüssel.
• Server: Der private Schlüssel selbst muss unverschlüsselt in einer Datei vorliegen. Diese Datei muss gegen Zugriffe also über entsprechende Rechte des Filesystems abgesichert werden.
• Client: Der Client benötigt im einfachsten konfigurierbaren Fall (Bind-Zugang zum LDAP-Server und entsprechende Autorisierung) nur das CA-Zertifikat.

Einige weitere Hinweise sind hierzu angebracht:

1. Der erste Punkt müßte genauer eigentlich heißen: Es werden die Zertifikate der involvierten CA-Hierarchie von der für den Server zuständigen CA bis hin zur Root-CA benötigt. S. hierzu die Ausführungen weiter unten. In unserem Test-Fall wird es aber nur genau eine CA, nämlich die Root-CA, geben.
2. Bzgl. des letzten client-bezogenen Punktes sähe es übrigens dann anders aus, wenn man TLS nicht nur für die Verbindungsverschlüsselung, sondern auch für eine starke zertifikatsbasierte Authentifizierung des Clients gegenüber dem LDAP-Server nutzen wollte. Ein solches Vorgehen behandeln wir hier aber nicht.
3. Zertifikatsdateien beinhalten nur öffentliche Schlüssel und müssen daher nicht so stark abgesichert werden, wie die Datei mit dem privaten Server-Schlüssel.

Zertifikate sind für TLS in jedem Fall essentiell und müssen durch geeignete Tools generiert werden. Wir spielen in unserem Fall (internes Netzwerk) selbst die Root-CA, die Zertifikate und Schlüssel ausstellt. In unserem einfachen Fall soll die CA auch noch auf unserem Testsystem “vms2″ beheimatet sein, also auf dem System, das auch den LDAP-Server selbst beherbergt.

Schritt 1: Erstellung der erforderlichen Zertifikate mit YaST2

Um Zertifikate für SSL/TLS zu erstellen, muss auf dem Opensuse-System “OpenSSL” installiert sein. Zur Zertifikats-Erstellung nutzen wir unter Opensuse folgendes YaST2-Modul:

yast2-ca-management.

Die zugehörigen RPM-Pakete sollten unbedingt auf den neuesten Stand gebracht werden. Das YaST-CA-Management hatte zumindest im Release Candidate zu Opensuse 12.1 noch Fehler. Mit bestimmten neueren Versionen von openssl ließ es sich auch auf einem neu eingerichteten Systemen nicht starten. (Natürlich kann man alles auch über die Kommandozeile machen - aber ich bin überhaupt kein Feind grafischer Tools, wenn sie denn funktionieren).

Wir öffnen als User root unter Yast nun das CA-Management und drücken im Fenster auf “Create Root CA”:

Wir füllen auf den nächsten Dialogfeldern die Daten passend aus und erhalten schließlich unser Root-CA-Zertifikat. .

Hier handelt es sich nur um einen Test - in der Realität sollte man sich auch für kleinere Firmen die CA-Hierarchie gut überlegen. In einigen Fällen wird es unterhalb der Root CA für spezifische Bereich des Unternehmens weitere CA-Autoritäten geben.

Hat man bereits eine mehrstufige CA-Hierarchie oder erstellt man eine solche, so müssen für ein funktionierendes TLS unter LDAP auf dem Server alle Zertifikate der CAs oberhalb derjenigen Instanz vorhanden sein, die das Serverzertifikat ausgestellt hat. In unserem Fall ist nur genau eine Zertifikatsdatei, nämlich die der Root-CA, erforderlich.

Nun müssen wir als nächstes eine Datei für das CA-Root-Zertifikat erstellen. Im nachfolgenden Dialog drücken wir deshalb auf “Enter CA”:

Danach erkennen wir wieder uns Root-CA-Zertifikat. Wir exportieren dieses nun als Datei:

Als Ziel des Exports geben wir auf unserem Testsystem der Einfachheit halber das Verzeichnis “/etc/openldap/” an.

Man wird auf einem realen System möglicherweise einen anderen, zentraleren Ordner für die Unterbringung seines Zertifikats oder seiner Zertifikate wählen. Wichtig ist aber, dass man die hier besprochenen Zertifikate und Schlüssel für denjenigen User, unter dem der LDAP-Server (genauer der zugehörige Prozess) läuft, zugänglich macht. Siehe weiter unten. Auf das CA-Zertifikat dürfen übrigens auch andere User lesend zugreifen.

Nun wollen wir das “Serverzertifikat” für unseren LDAP-Server erstellen. Hierzu gehen wir auf den Reiter “Certificates” und wählen “Add Server Certificate”:

Wichtiger Hinweis: Auf der nächsten Seite ist dann der sogenannte “Common Name” von einiger Bedeutung:

Wie schon im ersten Teil zur LDAP-Einrichtung erwähnt, ist es hier sinnvoll bis notwendig, den FQDN des Servers anzugeben - also den Namen inklusive Domain-Anteil. Der “Fully Qualified Domain Name” muss natürlich konsistent zu den Einträgen auf dem DNS-Server des lokalen Netzwerkes sein.

Der Grund für die Angabe des FQDN ist der Umstand, dass bei den von Opensuse vorgenommenen Standardeinstellungen des LDAP-Servers und der LDAP-Clients während des TLS-Aufbaus der “Common Name” des Server-Zertifikats mit dem Peer-Namen, unter dem der Server geführt ist, verglichen wird.

Typischerweise schlägt Opensuse bei einer Einrichtung lokaler Clients, die also auf dem gleichen System wie der LDAP-Server selbst beheimatet sind, statt des FQDN die Netzwerkadresse 127.0.0.1 vor. Das verführt leider dazu, auch bei echten Remote Clients für den Server IP-Adressen einzutragen. Solche LDAP Client-Einstellungen funktionieren ohne spezielle Zusatzeinstellungen des LDAP-Systems nicht mit TLS-Zertifikaten.

Der natürliche kleinste gemeinsame Nenner ist vielmehr FQDN des Servers. In unserem Fall also: “vms2@anracona.de”.

Wir gehen dann weiter, geben das zu verwendende Passwort für den Schlüssel an und erhalten schließlich unser “Server-Zertifikat” für den LDAP-Server.

Dieses exportieren wir wieder als “pem”-File:

Die Dateibezeichnung ist dabei unerheblich. Abschließend exportieren wir zum gerade noch geöffneten Serverzertifikat auch noch eine “pem”-Datei mit dem “Private Key”. Dieser muss unverschlüsselt exportiert werden.

Wir wechseln nun in das Verzeichnis “/etc/openldap/” und ändern den Owner und die Rechte der eben exportierten Dateien auf vernünftige Werte ab:

Auf dem Opensuse-System ist defaultmäßig der User “ldap” ind der Gruppe “ldap” eingerichtet. Unter diesem User läuft der LDAP-Daemon-Prozess:

vms2:/etc/openldap # ls -l
total 40
-rw-r–r– 1 root root 1838 Mar 11 16:45 anracona_vms2.pem
-rw-r–r– 1 root root 283 Mar 10 18:21 ldap.conf
-rw-r–r– 1 root root 245 Oct 29 19:17 ldap.conf.default
drwxr-xr-x 2 root root 4096 Mar 10 15:22 schema
-rw-r—– 1 root ldap 979 Mar 10 18:21 slapd.conf
-rw-r—– 1 root root 2538 Mar 10 18:21 slapd.conf.YaSTsave
-rw-r—– 1 root ldap 2538 Oct 29 19:18 slapd.conf.default
drwxrwx— 3 ldap ldap 4096 Mar 10 18:20 slapd.d
-rw-r–r– 1 root root 1830 Mar 11 17:11 vms2_cert.pem
-rw-r–r– 1 root root 1675 Mar 11 17:16 vms2_key.pem
vms2:/etc/openldap # chown ldap.ldap anracona_vms2.pem vms2_*
vms2:/etc/openldap # chmod 640 vms2_cert.pem
vms2:/etc/openldap # chmod 640 anracona_vms2.pem
vms2:/etc/openldap # chmod 600 vms2_key.pem

Schritt 2: Umstellung des LDAP-Servers auf TLS mit Hilfe von YaST

Nun haben wir zwar Zertifikate, aber der LDAP-Server muss noch für den Einsatz von TLS konfiguriert werden.

Wir wählen im graphischen Auswahlmenü von YaST2 nun den Punkt “LDAP Server” und wechseln dort im linken Menü zu den

“Global Settings” > “TLS Settings”.

Der Punkte “Enable LDAP over SSL” wird automatisch angewählt. Für diese Art der SSL-Verbindung wird der Port “636″ verwendet.

Auf unserem Testsystem lassen wir diese Einstellung. Auf einem realen System sollte man sich allerdings die Öffnung eines weiteren Ports aus Sicherheitsgründen gut überlegen. Denn dies ist nicht zwingend erforderlich:

Moderne LDAP-Clients können in der Regel die “Start TLS”-Möglichkeit für den Standard-LDAP-Port 389 nutzen (siehe weiter unten). “ldaps” und Port 636 werden dann nicht benötigt.

Ferner geben wir in der obigen Maske die Informationen zu den Zertifikatsdateien ein. Danach drücken wir auf den “OK”-Button und starten zur Sicherheit unseren LDAP-Server per “rcldap restart” neu.

An dieser Stelle lohnt sich ein Blick in die Konfigurationsdatei “/etc/openldap/slapd.d/cn=config.ldif”:

Durch die Einträge

olcTLSCACertificateFile: /etc/openldap/anracona_vms2.pem
olcTLSCertificateFile: /etc/openldap/vms2_cert.pem
olcTLSCertificateKeyFile: /etc/openldap/vms2_key.pem

wird der Server auf den Einsatz von TLS eingestellt, wenn der jeweilige Client dies nutzen will.

Schritt 3: Einrichtung des YaST-LDAP-Clients für die TLS-Nutzung

Wir richten nun auf unserem Testsystem (im Moment noch der LDAP-Server) den YaST “LDAP-Client” für die Nutzung von TLS ein. Hierzu öffnen wir die entsprechend bezeichnete Maske aus dem graphischen Menü von YaST2 heraus:

Man mag nun in der Tat ein wenig darüber rätseln, welcher “Client” hier denn eigentlich gemeint ist. Nun ja, SuSE meint wohl in erster Linie den YaST2-Client zur User und Gruppenverwaltung. Denn derselbe Dialog ist auch über Submenüs und Reiter der Yast2-User und Gruppenverwaltung zugänglich.

Andererseits sind die Einstellungen aber doch allgemeinerer Natur, denn sie werden in beiden zentralen Konfigurationsdateien des Opensuse-Systems für LDAP-Clients

• /etc/ldap.conf
• /etc/openldap/ldap.conf

hinterlegt.

Es stellt sich nun die Frage: Warum benötigt man eigentlich 2 Konfigurationsdateien für die von uns einzurichtenden LDAP-Clients?

Die Antwort liegt darin begründet, dass die nachfolgende Einrichtung “des Clients” vor allem das User- und Gruppen-Management betrifft. Hier geht auf aktuellen Linux-Systemen nichts mehr ohne PAM und NSS.

PAM dient der Authentifizierung von Usern gegenüber bestimmten Systemkomponenten. Die meisten Systemdienste sind heute PAM-”aware”, also PAM-fähig. Bei den entsprechenden Auth-Prozessen spielen User-Accounts des Systems die wesentliche Rolle. Solche Accounts können in mehreren Daten-Backends hinterlegt werden. Das entsprechende Regelwerk, ob und wann einen Authentifizierung über ein bestimmtes Backend notwendig oder hinreichend ist, kann pro Service sehr modular und unter Einbindung mehrerer Authentifizierungs-Backends konfiguriert werden.

PAM und NSS können unter mehreren abzufragenden Quellen auch LDAP als Authentifizierungs-Backends verwenden. Hierfür benötigt man schon aus Sicherheitsgründen spezielle Regeln - u.a. muss definiert werden, über welche Methodik oder welchen Account die PAM-Prozesse Zugang zum LDAP-Server erhalten, in welcher Weise Passwörter abgefragt oder gesetzt werden dürfen. Das Regelwerk, wie PAM und NSS mit dem LDAP-System umgehen sollen, wird bei Opensuse für PAM und NSS in einer gemeinsamen Konfigurationsdatei “/etc/ldap.conf” festgelegt.

Der Unterschied zwischen den beiden unter Opensuse zu füllenden Konfigurationsdateien “/etc/ldap.conf” und “/etc/openldap/ldap.conf” lässt sich also wie folgt beschreiben:

• Die erste Datei “/etc/ldap.conf” wird von PAM/NSS im Rahmen der Autorisierung von Systemzugängen verwendet, um LDAP in geeigneter Weise als ein Authentifizierungs-Backend einzubinden.
• Die Datei “/etc/openldap/ldap.conf” ist dagegen die systemweite Einstellungsdatei, die für gewöhnliche Standard-OpenLDAP-Clients den Zugang und die Interaktion mit dem LDAP-Server regelt. U.a. wird diese letztere Datei von Tools wie “ldapadd, ldapmodify” etc. gelesen.

Die LDAP-Client-Konfiguration über YaST nimmt im Hintergrund parallel die notwendigen Einstellungen sowohl für PAM- und NSS als auch für die “normalen” LDAP-Clients der OpenLDAP-Installation vor.

Wir erkennen in der obigen Abbildung die grundsätzlichen Einstellungen aus dem ersten Teil “LDAP I” wieder. Im Bild haben wir bereits den neuen Haken bei der Checkbox für “LDAP TLS/SSL” gesetzt.

Nun gehen wir zum Punkt “Advanced Configuration”. Dort geben wir an, wo auf unserem Client-System (das bislang noch mit dem LDAP-Server identisch ist) das Zertifikat der Root-CA liegt.

Achtung : Das hat nichts mit den Einstellungen des Servers zu tun.

Nur weil wir hier auf ein und demselben Testsystem arbeiten, auf dem auch unser LDAP-Server untergebracht ist, können wir das “/etc/openldap”-Verzeichnis nehmen. Auf anderen echten Remote-Client-Systemen mag das Root-CA-Zertifikat der Cert. Authority, der wir vertrauen, an anderer Stelle (mit der notwendigen Leseberechtigung) hinterlegt sein. Dann muss man die Pfade, die auf dem betreffenden Client gültig sind, angeben.

Noch ein Hinweis: Eigentlich sind die Einträge des Verzeichnisses und der CA-Datei Alternativen.

Ist eine Zertifikatsdatei explizit angegeben, wird diese beim Aufbau der TLS-Verbindung zum Server für die Verifikation seines Server-Zertifikates auch benutzt. Dies lohnt sich für lokale Netze, bei denen es genau eine Root-CA gibt, die alle Zertifikate ausstellt. (In unserem Fall handelt es sich bei dem ausgestellten Zertifikat auch noch um ein selbst signiertes Zertifikat ein und desselben Servers, dem der Client vertrauen soll).

Wenn der Client jedoch mehrere CAs kennen muss, weil er mehrere TLS-Verbindungen zu unterschiedlichen LDAP-Servern aufbauen muss, so gibt man alternativ nur den Pfad zu einem Verzeichnis an. Alle benötigten Zertifikate der CAs, denen der Client vertraut, müssen in diesem Verzeichnis untergebracht werden. Ein solches Verzeichnis muss zur korrekten Verwendung aber speziell gemanaged werden. Siehe hierzu die LDAP-Dokumentation:

“The specified directory must be managed with the OpenSSL c_rehash utility as well”. In unserem Beispiel würde dies das Absetzen folgender Befehle bedeuten:

vms2:~ # cd /etc/openldap/
vms2:/etc/openldap # c_rehash .
Doing .
anracona_vms2.pem => da108506.0
anracona_vms2.pem => b2a65b68.0
vms2_cert.pem => 1379254f.0
vms2_cert.pem => 955c98c7.0
WARNING: vms2_key.pem does not contain a certificate or CRL: skipping
vms2:/etc/openldap #

Wir können im Moment jedoch gut mit einer Installation leben, bei der unser Root-CA-File direkt angegeben wird.

Die Einstellungen unter dem Reiter “Administration Settings” hatten wir im einleitenden Teil “LDAP I” ja schon gesetzt. Hier müssen wir nichts verändern.

Wie gesagt, konfiguriert Opensuse die LDAP-Clients - u.a. die Name-Service-Switch-Dienste und die LDAP-Module vom PAM - für den Einsatz von TLS (im Gegensatz zu Debian und Ubuntu) in ein und derselben Datei “/etc/ldap.config”. Es lohnt sich, diese Datei und die dortigen Kommentare zu den Optionen einmal vollständig durchzuarbeiten. Die wichtigsten Einstellungen für eine elementare Konfiguration unter Opensuse sind:

Wichtigste Inhalte der Datei “/etc/ldap.conf”:

base dc=anracona,dc=de
bind_policy    soft
pam_lookup_policy    yes
pam_password    exop
nss_initgroups_ignoreusers    root,ldap
nss_schema    rfc2307bis
nss_map_attribute    uniqueMember    member
 
ssl    start_tls
uri    ldap://vms2.anracona.de
ldap_version    3
pam_filter    objectClass=posixAccount
tls_cacertdir    /etc/openldap
tls_cacertfile    /etc/openldap/anracona_vms2.pem

Mit ein wenig Phantasie kann man einiges hiervon auch ohne Erläuterung einordnen. Bzgl. weiterer Optionen, ihrer Bedeutung und vieler Details muss man sich in der Fachliteratur und/oder im Internet kundig machen.

Die wichtigsten Einstellungen in der Datei “/etc/openldap/ldap.conf” sind:

Wichtigste Inhalte der Datei “/etc/openldap/ldap.conf”:

host    localhost
base    dc=anraona,dc=de
uri    ldap://vms2.anracona.de/
ldap_version    3
ssl    start_tls
tls_cacert    /etc/openldap/anracona_vms2.pem
TLS_REQCERT    allow
tls_checkpeer    yes

Man erkennt die Ähnlichkeit der Einträge zur PAM-bezogenen Datei unmittelbar.

Die Option “tls_checkpeer yes” ist übrigens auch für PAM verbindlich, wenn sie in “/etc/openldap/ldap.conf” gesetzt ist. Sie sorgt dafür, dass das Serverzertifikat durch eine vertrauenswürdige CA verifiziert und auch mit dem Peer-Namen verglichen wird.

Hinweis zur Konfiguration von PAM und NSS für LDAP auf Nicht-Opensuse-Systemen
Unter anderen Linuxsystemen - vor allem Debian-basierten - werden zur Konfiguration statt einer einzigen Datei “/etc/ldap.conf” mehrere getrennte Dateien eingesetzt, die dann separat mit den notwendigen Informationen zu füllen sind. Einen Überblick liefert http://wiki.ubuntuusers.de/LDAP_Client_Authentifizierung. Unter SuSE hat man es hier etwas einfacher.

Hinweis zu weiteren LDAP-Clients
Das Muster, dass wir oben für PAM/NSS und die Standard-LDAP-Clients gesehen haben, setzt sich natürlich fort. SW-Module wie SAMBA, POSTFIX, CYRUS, SASL, autonome E-Mail-Clients (z.B.Thunderbird), etc. bringen in der Regel eigene Konfigurationsdateien und/oder Konfigurationstools für die LDAP-Anbindung mit. Und natürlich haben auch die dortigen Konfigurationsparameter jeweils eigene Bezeichnungen und Bedeutungen. Eine Einstieg vermitteln etwa die Bücher “LDAP System Administration” von Gerald Carter (O’Reilly) oder “OpenLDAP 2.4 - Das Praxisbuch” von O. Liebel, J. M. Ungar (Galileo Computing).

Schritt 4: Test der funktionierenden Einrichtung des lokalen LDAP-Clients mit YaST

Wir starten nun für einen ersten lokalen (!) Test der TLS-Fähigkeit den Yast2-LDAP-Browser, haken dort die TLS/SSL-Anforderung ab und geben unser LDAP-Administrator-Passwort ein.

Dabei beherzigen wir auch den bereits im ersten Teil angesprochenen Punkt, dass die Default-Einstellungen für den Eintrag “olcTLSVerifyClient” in der modularen LDAP-Konfiguration, nämlich

olcTLSVerifyClient: allow

den “common name” des Servers in FQDN-Form erfordern kann und setzen testhalber nicht “localhost ” oder “127.0.0.1″ bei der Serveradresse ein, sondern den FQDN. (Die beiden anderen Varianten hätten auf dem lokalen System auch funktioniert; natürlich aber nicht auf echten Remote Clients. Auf einem Remote Client würde auch eine IP-Adress-Angabe zu einem Fehler führen.)

Danach öffnet sich das Browserfenster und gibt den Blick auf die bislang gering besetzte LDAP-Hierarchie mit zwei Testusern frei:

Kenner sehen, dass die User-Objekte Felder aus mehreren Schemata beinhalten. TLS funktioniert offenbar schon lokal.

Als zweiten Test bemühen wir die Kommandozeile und durchsuchen unser Directory:

vms2:~ # ldapsearch -x -b ‘dc=anracona,dc=de’ -D “cn=Administrator,dc=anracona,dc=de” ‘(objectclass=*)’ -Z -H ldap://vms2.anracona.de -W

Die Option “-Z” fordert eine TLS-gesicherte Verbindung an. Wir geben danach das Passwort ein und sollten schließlich einen Überblick über die Inhalte der LDAP-Datenbank erhalten.

vms2:~ # ldapsearch -x -b ‘dc=anracona,dc=de’ -D “cn=Administrator,dc=anracona,dc=de” ‘(objectclass=*)’ -Z -H ldap://vms2.anracona.de -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
 
# anracona.de
dn: dc=anracona,dc=de
dc: anracona
o: anracona
objectClass: organization
objectClass: dcObject
…
…

Zur Kontrolle:

vms2:~ # ldapsearch -x -b ‘dc=anracona,dc=de’ -D “cn=Administrator,dc=anracona,dc=de” ‘(objectclass=*)’ -Z -H ldaps://vms2.anracona.de -W
ldap_start_tls: Operations error (1)
       additional info: TLS already started
Enter LDAP Password:

Die Fehlermeldung beweist, dass der ldaps-Kanal nicht mehr benutzt wird, weil start_tls aufgrund der “-Z”-Option bereits wunschgemäß aktiviert ist.

Als letzten lokalen Test öffnen wir nun lokal die Yast-Benutzerverwaltung und geben als “Filter” das LDAP-Backend an:

Danach sollten wir angelegte LDAP-Testuser sehen - hier z.B. einen User namens “rmu”:

Parallel beobachten wir mit Wireshark den LDAP-bezogenen Traffic auf “vms2″:

Wir erkennen sehr deutlich, wie das TLS-Protokoll eingeschaltet wird.

Damit sind wir erstmal zufrieden. Im nächsten Teil “LDAP 3″ dieser Serie sehen wir uns die Sache aus der Perspektive eines externen Opensuse 12 Client-Systems namens “vms1″ an.

Interessanterweise habe ich für Opensuse 12 keine zusammenhängende Beschreibung im Internet gefunden, wie man ein elementares LDAP-Setup zu vollziehen hat. Im Gegenteil fand ich in Foren und Blogs etliche Warnungen davor, das überhaupt mit den SUSE-Tools zu versuchen. Es geht aber doch …

Deshalb beschreibe ich nachfolgend die Schritte, die ich auf einem Testserver durchgeführt habe (der virtuell unter KVM lief).

Vorweg sollte ich ein paar Einschränkungen klarstellen:

• Grundlagenkenntnisse zum Aufbau einer hierarchischen LDAP-Datenbank und zu LDAP-Schemata werden vorausgesetzt. So sollte bekannt sein, was “Distinguished Names” sind und was im besonderen eine Base-DN oder eine Root-DN ist. Eine Kurzseinführung bietet Wikipedia unter:
  http://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
• In diesem Beitrag geht es nicht um eine umfassende LDAP-Einrichtung und die Konfiguration aller möglichen Clients (z.B. Postfix, Samba) für die Benutzung von LDAP. Es geht nur darum, LDAP neben dem gewöhnlichen Passwort-Mechanismus als Authentifizierungsbackend für den Login auf unterschiedlichen Linux-Systemen (in meinem Fall weitere virtuelle Maschinen) zu nutzen.
• Die Pflege der User-Accounts, Passwörter etc. auf dem LDAP-Server möchte ich dabei mit den entsprechenden Yast2-Tools vornehmen.
• Die Verbindungskanäle der verschiedenen Linux-Systeme, die zur Authentisierung und zur Pflege ihrer User und Gruppen auf den zentralen LDAP-Server zugreifen, sollen mit Hilfe von TLS verschlüsselt werden.
• Es geht hier nicht darum, den Zugang zum LDAP-Server - außer für Rootprozesse - durch einen eigenen speziellen Authentifizierungsmechanismus wie z.B. SASL in Kombination mit Kerberos abzusichern. Wir begnügen uns hier mit einfachen, sog. Bind-Verfahren, die für ein einfaches Authentisierungsverfahren in Netzen mit geringen Sicherheitsansprüchen genügen. Bzgl. der Sicherheit vertrauen wir in unserem Beispiel lediglich auf die eben erwähnte TLS-Verschlüsselung der Verbindungen zum Server.
• Es geht zunächst auch nicht darum, den Zugang zu bestimmten Informationen auf der LDAP-Datenbank user- oder gruppenspezifisch (besser: bindspezifisch) abzusichern. Lediglich der Zugriff auf die Passwörter zu den Personenaccounts, die im LDAP vorgehalten werden, wird beschränkt.

Primäres Ziel ist es also, die Benutzerverwaltung auf dem LDAP-Server mit den YaST-Tools zur Userverwaltung abzuwickeln. Voraussetzung hierfür ist nicht nur eine passende LDAP-Server-Einrichtung, sondern auch die korrekte Einrichtung der YaST2-LDAP-Clients für die “YaST User- und Gruppenverwaltung”.

Das zweite Ziel ist es, testweise einen User-Login sowohl auf einem weiteren externen Testsystem als auch auf dem LDAP-Server selbst über eine Authentisierung gegenüber dem LDAP-Backend vorzunehmen. Hierbei sollen klassische Linux-Authentisierungsmechanismen (PAM in Kombination mit NSS; s.u.) eingesetzt werden.

Diese Module können als LDAP-Clients auf externen Systemen, die ganz unabhängig vom LDAP-Server sind, zum Tragen kommen. Der jeweilige Rechner muss dann mit dem LDAP-Server über eine TCP/IP-Verbindung kommunizieren (Ports: 389 und ggf. auch 636). Aber auch auf dem LDAP-Server selbst wird man diese Authentisierungsmechanismen über LDAP einsetzen; schließlich muss man sich auch dort authentisieren.

Voraussetzung ist, dass die entsprechenden Test-User-Accounts natürlich vorher mit den YAST2-Tools angelegt wurden. Also müssen wir die YAST2-Module zur User-Verwaltung auch auf dem externen Testsystem zur Verwendung von LDAP einrichten. Ferner müssen die notwendigen Authentisierungs-Module als LDAP-Clients auf dem externen Testsystem (und natürlich auch auf dem LDAP-Server selbst) richtig konfiguriert worden sein. Zudem sollte der Zugriff auf den LDAP-Server sowohl für den pflegenden Administrator als auch die Authentisierungsmodule der externen Systeme über eine TLS-gesicherte Verbindung erfolgen.

In diesem ersten Beitrag “LDAP I” beschreibe ich zunächst die Einrichtung des LDAP-Servers mit den YAST-Tools und ohne TLS. Der zweite Teil “LDAP II” beschreibt dann das Anlegen eines SSL-Zertifikats für den LDAP-Server und dessen Umstellung auf SSL/TLS. Im Teil “LDAP III” gehe ich dann auf die Client-Konfiguration der Linux-typischen Authentisierungsmechanismen (PAM/NSS, s.u.) zur Benutzung des eingerichteten LDAP-Servers ein.

1. Vorüberlegungen

Welche Verfahren/Module für die User-Authentisierung werden auf Linux-Systeme eingesetzt? Zu nennen sind hier in erster Linie PADL’s PAM (Plugable Authentication Modules) und NSS (Name Service Switch). [Neuere Entwicklungen wie SSSD lasse ich in diesem Artikel unter den Tisch fallen.]

Die genannten Module sind auf den meisten Linux-Systemen als Standard installiert. Sie steuern auch unter Opensuse 12 die Authentisierung gegenüber verschiedenen Backends. U.a. können sie als LDAP-Clients fungieren und auf externe (oder interne) LDAP-Systeme zugreifen. Die Interaktionskette zur Authentisierung eines Users gegenüber einem zentralen LDAP-Server sieht dabei etwa so aus:

Login-Versuch eines Users mit UID und Passwort auf einem (externen) Linux-System
>>
NSS/PAM entscheiden über den Authentisierungsweg und leiten den Authentisierungsvorgang ein
>>
PAM nimmt Kontakt zum LDAP-Server auf (über das Netzwerk oder - falls der Login-Versuch auf dem LDAP-Server selbst erfolgt - über ein lokales Socket-Protokoll)
>>
PAM erhält Zugang zum LDAP-Server und durchsucht die LDAP-Daten-Bank nach einem Eintrag für den User mit der angegebenen UID
>>
PAM versucht mit den LDAP-Informationen und dem vom User eingegebenen Passwort danach einen sog. BIND an den LDAP-Server
>>
Gelingt der BIND, so wird die LDAP-Authentifizierung als gelungen zurückgemeldet
>>
Ist diese Authentisierung gemäß der PAM-Einstellungen hinreichend, wird der Zugang zum (externen) Linux-System gewährt.
 

Was unter einem “BIND” zu verstehen ist, bespreche ich weiter unten. Wir kümmern uns in diesem LDAP-Artikel nicht um Details der PAM-Bedingungs-Kaskade für eine hinreichende Authentisierung auf einem Linux-System. Wir gehen hier vielmehr von den Opensuse-Standardeinstellungen aus, die bei der Einrichtung der YAST2-Benutzerverwaltung für eine hinreichende LDAP-Authentisierung auf dem betreffenden Linux-System vorgenommen werden.

Interessant sind in unserem Zusammenhang aber natürlich die Einstellungen von PAM-Login und NSS zur Ein- und Anbindung an einen LDAP-Server. Das Schöne dabei ist, dass uns YaST2 hierbei die grundlegenden Arbeitsschritte im Rahmen der Konfiguration der “Yast2-User und Gruppenverwaltung” für die LDAP-Nutzung bereits abnimmt.

Ein paar Hinweise noch zu gedanklichen Fehlern, die man beim Anlegen von LDAP unter Opensuse 12.1 machen kann :

Einsatz modularer LDAP-Konfigurationsdateien anstelle der klassischen Datei “slapd.conf”

Das YaST-Modul von Opensuse 12.1 zur Einrichtung eines LDAP-Servers verwendet die klassische Konfigurationsdatei “slapd.conf” nicht mehr. Das merkt man aber nicht unbedingt auf Anhieb. Vielmehr ist der optische Informationsstand zu diesem Thema auch noch vom Upgradestand des 12.1-Systems abhängig.

Auf einem voll aktualisierten System erhält man in der Datei “/etc/openldap/slapd.conf” keine regulären Einträge mehr, sondern nur noch Kommentare, in denen auf die neue dynamische und modulare Konfiguration verwiesen wird.

Auf einem frisch von CD installiertem oder upgegradeten System hingegen gibt es dagegen die Datei “/etc/openldap/slapd.conf” auch nach der Installation des Openldap2-RPMs noch. Sie weist Standard-Einträge auf, und sie bleibt auch noch nach der Konfiguration des LDAP-Servers mittels YaST unverändert bestehen. Das war für mich zunächst total verwirrend. Nach einigem Testen fand ich aber heraus, dass man die Einstellungen in der herkömmlichen “slapd.conf” vergessen kann. Die eigentlichen Konfigurationseinstellungen befinden sich in den Verzeichnissen

• /etc/openldap/slapd.d/
• /etc/openldap/schema/

Diese Dateien sind gemäß des LDIF-Formats aufgebaut. Weitere Informationen zum hierarchischen Aufbau der LDAP-Konfigurationsdateien erhält man durch die Installation des Paketes “openldap2-doc” und dann durch Lesen folgender HTML-Seite

/usr/share/doc/packages/openldap2/adminguide/guide.html#Configuring slapd

Modifikationen an den Dateien kann man über die Kommandos “ldapmodify”, “ldapadd” und “ldapdelete” durchführen, wenn man ein direktes Editieren scheuen sollte.

Benutzerauthentisierung auf einem Rechnersystem über LDAP ist etwas anderes als die Authentisierung eines Users oder Systems gegenüber dem LDAP-Server, um Zugang zu
den dort hinterlegten Informationen zu erhalten

Bei einem Loginversuch eines Users auf einem Linux-PC oder -Server werden die User-Credentials über PAM-Module mit entsprechenden Einträgen in der Datenbank des LDAP-Servers verglichen. LDAP wird hier als Mittel zur User-Authentisierung für den PC-Zugang eingesetzt.

Das LDAP-System selbst gewährt als sicherheitsrelevantes Datenbank-System aber natürlich nicht so ohne weiteres jedem Anwender oder jedem Programm lesenden oder schreibenden Zugang zu den Datenbank-Inhalten. Ein User oder ein Programm wie PAM, das einen solchen Zugang erlangen möchte, muss sich je nach den gesetzten Bedingungen also selbst erst einmal gegenüber dem LDAP-Server als berechtigt ausweisen oder authentisieren. Dieser Schritt wurde für PAM in der oben dargestellten Kette als “PAM erlangt Zugang zum LDAP-Server” gekennzeichnet. Der Zugang zum LDAP-System kann durch folgende Varianten ermöglicht werden:

• Es können zusätzliche Auth.-Mechanismen (wie SASL) und andere Sicherheitslayer eingesetzt werden,
• Es werden die Informationen, die im LDAP-System selbst zu Usern oder Systemen oder zugehörigen Passwörtern hinterlegt sind, verwendet, um den LDAP-Zugang zu gewähren.

Die zweite Variante wird als “Bind” gegenüber dem LDAP-System bezeichnet.

Die beim Bind verwendeten LDAP-Identität hat gemäß der Struktur der LDAP-Einträge eine spezifische Form, die die Baumstruktur der Information widerspiegelt (z.B. “cn=Administrator, dc=anracona,dc=de” oder cn=Ralph,ou=people,dc=anracona,dc=de).

Damit bei Binds nicht jeder alles zu sehen bekommt oder alles ändern darf, müssen “Bind”-spezifische, also Identitäts-spezifische Rechte für die LDAP-Datenbank-Informationen vorgegeben sein. Will man eine LDAP-Zugangsautorisierung über “Binds” überhaupt nicht zulassen, so muss man “Binds” explizit in der Konfiguration des LDAP-Servers ausschließen. Dies ist bei der Standardeinrichtung von Opensuse 12.1 jedoch nicht der Fall. Die Rechte bzgl. der im LDAP-System erfassten Linux-User- und Gruppen-Daten entscheiden u.a. darüber, ob Authentisierungs-Clients wie PAM sich über spezielle BINDs Zugang zum LDAP-System verschaffen müssen.

Die erste der oben genannten Varianten wird dagegen meist über das “SASL Authentisierungs- und Authorisierungs-Framework” und seine Untervarianten für die Authentisierung realisiert. Dabei werden ggf. SASL-eigene Datenbanken oder aber Zusatzsysteme wie Kerberos eingesetzt. Eine spezielle Variante für LDAP im Rahmen von SASL ist die sog. “External”-Variante, bei der SASL auf die Authentisierung durch andere externe Layer oder Protokolle zurückgreift.

Bei Opensuse 12.1 greift die “External”-Variante für Root-Prozesse, die über ihre Systemberechtigungen authentisiert und für den LDAP-Zugang autorisiert werden. Hierbei wird ein (lokales) IPC-Unix-Socket-basiertes Zugriffs-Protokoll namens “ldapi” eingesetzt, das auf der Unix-Interprozesskommunikation über Sockets basiert.

“SASL External” wird als Voreinstellung für die LDAP-Zugangs-Autorisierung von Prozessen eingesetzt, die mit Linux Root-Rechten laufen

Im Zuge einer initialen LDAP-Einrichtung sollte Root oder sollten Root-Prozesse mit Hilfe des ldapadd-Kommandos in der Lage sein, das LDAP-System und auch dessen modulare “cn=config”-Konfigurationsdateien mit Hilfe des “ldapadd”-Kommandos zu modifizieren.

Deshalb werden lokale Root-Prozesse auf dem LDAP-Server unter Opensuse 12 standardmäßig über den SASL External-Mechanismus im Zusammenspiel mit dem IPC-Unix-Socket-ldapi-Interface für den Zugriff auf den LDAP-Server autorisiert.

Erreicht wird dies einerseits durch Einträge für den Start des LDAP-”slapd”-Dämons, bei dem auch das IPC-LDAPI-Protokoll für den Zugriff auf den LDAP-Server initialisiert wird (s. die Datei /var/run/slapd/slapd.args). Andererseits muss in den LDAP-Konfigurationsdateien ein Mapping der folgenden Form

gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

vorgenommen werden. Wir kommen darauf zurück.

Unabhängig von diesem Sonderfall erfolgen andere Zugriffe - u.a. die Authentifizierungsversuche von PAM - in der Standardeinstellung von Opensuse 12.1 ohne weitere Vorkehrungen aber über Binds.

2. Elementare Server-Einrichtung

Nun die einzelnen Schritte zur initialen LDAP-Einrichtung unter Opensuse 12.1:

Schritt 1: Installieren bzw. Update der notwendigen Pakete

Als Kernpakete für die wichtigsten Einrichtungsschritte und später darüber hinausgehende Schritte sind empfehlenswert:

• openldap2
• libldap-2_4-2
• openldap2-client
• openldap2-doc
• pam-ldap
• nss_ldap
• perl-ldap
• yast2-ldap
• yast2-ldap-client
• yast2-ldap-server
• cyrus-sasl-ldap-auxprop

Will man die Pakete nicht einzeln holen, ist es unter der Yast-SW-Verwaltung sinnvoll, sich am Opensuse-SW-Pattern “Directory Server (LDAP) zu orientieren. Die oben genannten Pakete sollte man sich natürlich auf dem neuesten Stand besorgen.

Schritt 2: Aufsetzen des Servers mittels YaST2

Die nachfolgenden Abbildungen zeigen den Durchgang durch eine erste LDAP-Server-Konfiguration mittels des Yast2_Moduls “LDAP-Server”. Hierbei haben wir als Base-DN des LDAP-Servers “dc=anracona,dc=de” angenommen. Ferner wird noch keine TLS-Konfiguration vorgenommen.

Das hier eingegebene Passwort für den LDAP-Admin mit der DN

cn=Administrator,dc=anracona,dc=de

verwenden wir nachfolgend in einer Reihe von Einrichtungsschritten zur Authentisierung.

Schritt 3: Starten des LDAP-Servers und Test der Verbindung über den YaST2 LDAP Browser

Wir prüfen nun, ob der LDAP-Server läuft, und zwar mittels des Kommandos :

rcldap status

und versuchen ggf., ihn danach mit

rcldap restart

zu starten. Das sollte bereits einwandfrei funktionieren.

Ein Test zur Verbindungsaufnahme ist möglich mit

ldapsearch -x -b ” -s base ‘(objectclass=*)’ namingContexts

vms2:~ # ldapsearch -x -b ” -s base ‘(objectclass=*)’ namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=anracona,dc=de
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
vms2:~ #

Ein zusätzlicher Test ist auch möglich über den “Yast2 LDAP Browser”. Dort passen allerdings die generellen LDAP-Client-Einstellungen des Systems (noch) nicht. Deswegen fügt man über die Schaltfläche “Add” ein weiteres Zugriffsprofil mit einem beliebigen Namen (hier “X”) ein.

In unserem Testfall heißt der Server “vms2.anracona.de”. TLS ist abzuwählen.

Ein Drücken auf den OK-Button führt in unserem Fall zu folgendem Ergebnis:

Dass kaum etwas zu sehen ist, liegt natürlich daran, dass unsere LDAP-DB noch so gut wie leer ist.

An dieser Stelle lohnt sich ein Blick in zwei Konfigurationsdateien, die von YaST angelegt wurden. Die erste Datei “/etc/openldap/slapd.d/cn=config.ldif” zeigt den Eintrag

olcAuthzRegexp: {0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth dn
:cn=config

Dieser Eintrag ist typisch für das oben angesprochene “External Authentisierungs-Verfahren” für Prozesse mit Root-Rechten im Linux-System - hier über das IPC”-ldapi-Protokoll. Siehe zu Details die oben erwähnte Openldap2-Dokumentation.

Die zweite Datei “/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif” zeigt u.a. die Anlage des LDAP-Administrators und den Hash für das Passwort:

Weiter unten in dieser Konfigurationsdatei erkennt man übrigens die Vorgabe für die Anlage von Indices über bestimmte Felder der eingerichteten Account-Schemata.

Welche Standard-LDAP-Schemata für Objektklassen eingerichtet wurden, offenbart übrigens ein Blick in das Verzeichnis “/etc/openldap/slapd.d/”cn=config”/”cn=Schema”/. Es handelt sich um die Schemata

core, cosine, inetOrgPerson, rfc2307bis, yast

User werden später als Objekte, die die Eigenschaften einiger dieser Klassen kombinieren, angelegt. Dabei wird Konformität zu Posix-Accounts erreicht.

Die folgende Abbildung zeigt die Verzeichnisstruktur der Konfigurationsdateien und noch einmal die von Opensuse installierten Standardschemata:

Schritt 4: Einrichtung der Yast2 “User- und Gruppenverwaltung” auf dem LDAP-Server als LDAP-Client

In diesem Schritt binden wir das Yast2-Modul für die User- und Gruppen-Verwaltung an den LDAP-Server an. Hierbei wird ein wesentlicher Teil der LDAP-Client-Einrichtung auf unserem lokalen Opensuse 12.1-Testsystem vorweggenommen.

Natürlich greifen die YaST-Clients unseres LDAP-Servers eigentlich nur auf den “localhost” (127.0.0.1) zu.

Die dargestellten Prinzipien gelten aber analog auch für Opensuse-Systeme, deren YaST-Module Zugriffe auf Remote-LDAP-Server durchführen sollen. Die nachfolgenden Schritte lassen sich deshalb später auf andere, externe Opensuse-Systeme übertragen, von denen mit den dortigen YaST-Tools User- und Gruppen-Accounts auf unserem frisch eingerichteten LDAP-Server angelegt werden sollen.

Wir öffnen auf unserem LDAP-Server die Yast2-User-und Gruppenverwaltung und gehen dort auf den letzten Reiter.

Dort klicken wir nun auf den Link “LDAP” (oder gehen alternativ über den Configure-Dialog):

Hier klicken wir TLS im Moment weg. Auch mit SSSD und Kerberos wollen wir uns in diesem Beitrag nicht befassen.

Von relativ Bedeutung ist, dass man bereits jetzt die Adressangabe bzgl. des Servers unter Benutzung der FQD-Form machen sollte. In den von Opensuse vorgenommenen Standardeinstellungen werden später, wenn wir TLS benutzen, Vergleiche des LDAP-Peer-Namens mit der im Server-Zertifikat überlicherweise verwendeten FQD-Bezeichnung vorgenommen. Die Bezeichnungen müssen übereinstimmen, wenn man in den LDAP-Einstellungen keine besonderen Vorkehrungen treffen will.

Wir klicken nun auf die Schaltfläche “Advanced Configuration” und lassen dort die Einstellungen des Reiters “Client Settings” unverändert.

Nun wechseln wir zum Reiter “Administration Settings” und geben die Daten zur Administrator-DN ein.

Wir drücken den Button “Configure User Management Settings” und geben im erscheinenden Dialog das Passwort ein:

Wir bestätigen die nächste Frage:

Auf der folgenden Optionen-Seite legen wir nichts Neues an; wir drücken auf OK

Danach drücken wir in 2 weiteren Rücksprung-Dialogen ebenfalls auf OK und erhalten am Schluss einen konfigurierten LDAP-Client für die User- und Gruppen-Verwaltung von YaST :

Wir drücken erneut auf OK und wechseln zur Userverwaltung unseres Testsystems. Dort drücken wir auf den Button “Filter” und wählen “LDAP Users” und geben erneut das LDAP-Admin-Passwort ein:

Wir sind dann im (noch leeren) Bereich derjenigen User auf unserem System, die über unseren LDAP-Server verwaltet werden. Wir legen testweise einen neuen, ersten Useraccount im LDAP-System an:

Für diesen User testen wir abschließend und hoffentlich erfolgreich einen Login-Versuch auf unserem LDAP-Server-System und freuen uns, dass wir unsere User zumindest auf diesem System künftig mit YaST und LDAP verwalten können.

Im nächsten Teil stellen wir den LDAP-Server für die sichere (Remote-) Nutzung auf SSL/TLS um.

Meine Kollegin hatte versucht, eine neue Mail-Adresse auf dem OX 5 Server von Kontakt/Kmail eines Client-Rechners aus zu speichern. Dabei wird ein neuer Kontakt angelegt, dessen Daten bei meinem OX 5 sowohl in der Postgres-Datenbank als auch in einer LDAP-Datenbank hinterlegt werden.

Leider hatte die Kollegin die Mail von einem Outlook-Benutzer erhalten, der seine Adressangaben recht chaotisch gepflegt hatte. Seine “von”-Adresse wies eine Angabe der Form “mailto:xxx@yyy.com” auf. Unvorsichtigerweise hat meine Kollegin zur Übernahme der Mailadresse in das Kmail-Adressbuch (das eigentlich ein OX-Adressbuch ist) wie gewohnt mit der rechten Maustaste auf diesen “mailto-Link” im Adressbereich der an sie weitergeleiteten Mail geklickt. Dies hatte schlimme Folgen:

Der Speichervorgang für den neu anzulegenden “Kontakt” in den Kontakte- und Adressen-Verzeichnissen des OX5 Servers wurde leider nicht korrekt abgearbeitet. Als resultierende Symptome musste ich nach einiger Analyse von Log-Dateien des Servers leider einen traurigen Zustand feststellen:

• Absturz von Tomcat
• Korrumpierte LDAP-Datenbank
• Massive Performancereduktion des OX-Servers wegen hängendem LDAP

Für die, die hier evtl. schlimmere Dinge vermuten: Ein Virenscan der Mail mit unterschiedlichen Scannern hat nichts erbracht.

Wegen der korrupten LDAP-Datenbank war auf dem OX5-server natürlich auch keinerlei Login mehr für die OX-User möglich, da diese alle über LDAP verwaltet und über “pam-ldap” authentisiert werden. User auf externen Servern konnten daher weder Dienste des OX-IMAP-Servers, noch Samba- und NFS-Dienste nutzen. Hier war schnelle Abhilfe von Nöten.

Die Lösung brachte hier (SUSE-SLES-System) folgende Kommandosequenz :

cd /var/lib/ldap
rcldap stop
db_recover -v
slapindex
rcldap start

LDAP unter Opensuse und auf SLES-Systemen nutzt defaultmäßig die Berkely DB als Backend zur Datenhaltung. Damit ist das Kommando “db_recover” angesagt. ( Unter Red Hat ist übrigens statt “db_recover -v” das Kommando “/usr/sbin/slapd_db_recover -h /var/lib/ldap ” einzusetzen.)

Für “katastrophale” Fälle kann man auch - nach weiteren Sicherungsmaßnahmen (! siehe die Links unten !) - die Variante

db_recover -v -c

verwenden. “-c” steht hier für “catastrophic”.

Will man das Kommando von einem anderen Ort als dem Verzeichnis “/var/lib/ldap” ausführen, so ist die Option “-h” nützlich.

Weitere Informationen - auch für hartnäckige Fälle der Restaurierung der LDAP Backend Datenbank - liefert die Artikel unter folgenden Links:

http://sdb.open-xchange.com/node/29
http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

Zu den Optionen von “db_rcover” für die BDB siehe :

http://www.manpagez.com/man/1/db_recover/

Weitere Informationen zur Fehlerbehebung findet man unter:

http://techarold.blogspot.com/2006/07/more-openldap-recovery.html
http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
http://serverfault.com/questions/87889/ldap-database-recovery-after-server-crash
http://web.archiveorange.com/archive/v/TDuKz11zCkpKFJNjBppH
http://www.bynari.net/support/users/kb.php?id=236

Generelle LDAP-Admin-Informationen findet man unter :

http://www.openldap.org/doc/admin24/

Zum Einsatz der BDB als LDAP-Backen siehe:

http://www.zytrax.com/books/ldap/ch6/bdb.html

Kmail 1.13.7 wies hierfür einen voll funktionsfähigen eigenen Such-Dialog auf. Auf einem unserer Rechner ist die alte Version noch unter KDE 4.6.4 installiert. Da läuft alles noch prima - auch im Zusammenspiel mit IMAP-Servern.

Wie ist der Zustand seit KDE 4.7 und auch jetzt noch unter KDE 4.8 ?

• Weder unter Kmail 4.7.4 noch unter Kmail 4.8 gibt der Suchdialog einem eine Möglichkeit zur Eingabe eines Mailverzeichnisses, den man durchsuchen will.
• Wenn gesucht wird, so wird (manchmal) in allen Mailverzeichnissen gesucht.
• Unter KDE 4.7.4 liefern viele Suchvorgänge Ergebnislisten mit leeren Zeilen am Anfang.
• Unter KDE 4.8 liefert eine Suche mit mehreren kombinierten Such-Kriterien leere Resultsets, obwohl es viele Mails gibt, die die Kriterien erfüllen.
• Manche Suchen nach Begriffen im vollständigen Mailtext liefern Resultsets - aber auch die nicht immer zuverlässig. Die Suchergebnisse sind nicht immer vollständig.

Das Ganze ist so fehlerhaft, dass man den Suchdialog unter Kmail im Moment als nicht benutzbar ansehen muss. Im Grunde ein Desaster! Hingewiesen hat mich darauf übrigens Martin Lüchem. Ich wollte es ihm zunächst gar nicht glauben, aber leider hat er recht.

Die einzige Suche, die bei mir z.Z. noch funktioniert, ist die über die Eingabezeile im normalen Kmail-Fenster. Das ist eine Volltext-Suche. Die scheint zu klappen. Aber wie gesagt, das reicht für den professionellen Einsatz überhaupt nicht.

Da fragt sich der KDE-Anwender erneut: Wie kann es sein, dass sich solche Mängel über zwei größere Releases von KDE 4 hinweg halten können?

Bei mir hat folgendes geholfen:

• Stoppen von Nepomuk über die KDE-Systemeinstellungen.
• Stoppen von Akonadi (man benutze das Kommando “kcmshell4 kcm_akonadi”,
  gehe dann im sich öffenenden Fenster auf den 2-ten Reiter für die “Einrichtung des Akonadi-Servers”
  und stoppe dort den Akonadi-Server).
• Zur Sicherheit : Herunterfahren in den Runlevel 3
• Löschen des Verzeichnisses ~/.kde4/share/apps/nepomuk
• Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/nepomuk*
• Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/akonadi_nepomuk_*
• Hochfahren in den Runlevel 5 und Log in in den KDE-Desktop.

Danach wurden bei mir neue Konfigurationsdateien angelegt und auch das Nepomuk-Verzeichnis wurde erneuert.

Nepomuk begann dann mit einer Reindizierung aller möglichen Ressourcen, aber beanspruchte die CPU dabei viel, viel weniger als zuvor. Ferner verhält sich Nepomuk jetzt bei mir sogar adaptiv und begrenzt die CPU-Belastung auf Zeiten, in denen ich mit anderen Programmen nicht so viel macht.

Siehe hierzu auch https://bugs.kde.org/show_bug.cgi?id=289932, Kommentar #3 und weitere Kommentare.

Schade, dass die KDE-Entwickler immer wieder solche Schnitzer produzieren. Es muss doch möglich sein, die Programme neuer Versionen so zu gestalten, dass es möglich wird KDE-Updates durchzuführen, ohne Konfigurationsdateien von Schlüsselkomponenten löschen und neu anlegen zu müssen.

Nachtrag 15.02.2012:

Ich habe ein anderes System, auf dem folgende Voraussetzungen gegeben waren:

1) Opensuse 12.1 wurde von scratch neu installiert - und zwar zunächst ohne KDE, aber mit XFCE.
2) Danach habe ich direkt KDE 4.8 aus dem Repository http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/ installiert. Es gab also kein Update von KDE 4.7.2.

Nach der Anbindung an einen IMAP-Server begann der Nepomuk-Indexer zu arbeiten und zwar ziemlich lange. Als nach ca. 30 Minuten kein Ende absehbar war, bin ich in die KDE-Systemeinstellungen (”systemsettings”) gegangen und dort in die Einstellungen zur “Desktopsuche”. Dort habe ich in der angegebenen reihenfolge folgende schritte durchgeführt:

• Deaktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
• Deaktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden”
• Deaktivierung des Punktes “Nepomuk-Semantik-Dienste aktivieren” -> Button “Anwenden”

Danach geht die CPU-Belastung durch Nepomuk auf 0. U.a. ist der Email-Indexer gestoppt. Dann habe ich folgendes gemacht:

• Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
• Aktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden” und Durchlaufen lassen ! Ggf. über “Erweiterte Einstellungen” den verzeichnisbereich, der indiziert wird, einschränken.
• Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”

Danach war Ruhe und die hohe CPU-Belastung durch virtuoso-t / nepomuk ging auf fast 0! Vermutlich wurde der erstmalige Neuindizierungsprozess von Nepomuk (kontrolliert?) abgebrochen. Danach scheint es aber leider so, dass der Email-Indexer gar nicht mehr läuft - zumindest werden bei Suchvorgängen nach Begriffen im Text von Emails keine Treffer mehr unter neuen Emails gefunden.

Quadcore CPU Intel Q9550, 8GB RAM, 3ware Raid-Controller mit 4 2TB-Platten im Raid 10 Modus, Nvidia Grafikkarte EVGA 9800GTX+ an einem 1920×1200 Schirm.

Ich möchte hier das System nur soweit installieren, dass mindest die Grafikkarte läuft, die Anbindung ans Netz erfolgt ist und ich in der Lage bin, einen Vergleich der Startup-Zeiten zwischen “systemd” und dem konventionellen “System V Init”-Verfahren durchzuführen.

Potentiell problematisch sind für eine Opensuse-Installation sind an der Hardwareliste zwei Dinge:

Einerseits das Raid 10-System - das Raid-Array entspricht netto einer Platte mit einem Plattenplatz oberhalb von 3,8 TB . D.h. “fdisk” fällt als Formatierungstool aus; es wird “GPT” benötigt. Hier ist aber Optimismus angesagt, denn der Opensuse-Installer bindet mindestens seit Opensuse 11.3 automatisch GPT ein, wenn er eine entsprechend große Platte erkennt. Das Gleiche gilt natürlich auch für den “Partitionierer” unter Yast. Aber man wiss ja nie …

Schwierigkeiten kann ebenfalls die EVGA-Grafikkarte machen. Bei früheren Installationen hatte ich mit dieser Karte regelmäßig Probleme mit dem 1600×1200-Framebuffer-Modus. Dieser wird von Opensuse aber als Modus mit der maximalen Auflösung angeboten - im besonderen für die Konsolen-Darstellung. Den hochauflösenden Modus möchte man natürlich auch gerne ausnutzen - oft genug mußte ich früher aber schon auf den 1280×1024-Modus ausweichen. Hier war ich gespannt, wie sich der “Opensuse 12.1″-Installer verhält und wie man den Nvidia-Treiber zum Laufen bringt.

Positive Punkte während der Installation

Der 1600×1200 Modus wird während der Installation auch bei der EVGA-Karte weitgehend akzeptiert

Ich konnte im graphischen Installer die Auflösung 1600×1200 wählen. Dies machte bis zum Neustart des installierten Systems über “kexec” auch keine Probleme - weder in zwischenzeitlichen Konsol-Ansichten noch im grafischen Modus selbst.

Die Formatierung des netto 3.8 TB umfassenden zusammenhängenden Raid-Arrays gelang ohne jegliche Probleme

Das Raid 10-System ist bei einer Frmwareversion “FE9X 4.10.00.007″ des 3ware-Raid-Controllers recht performant - die schreibraten liegen um die 220 - 250 MB/sec, die Leseraten sind noch höher. Mehr kann man bei den eingesetzten Samsung “2TB F4 HD204UI”-Platten einfach nicht erwarten. Es wäre schade gewesen, wenn das SuSE-System damit nicht hätte umgehen können. Aber weder der Installer noch der “YAST-Partitioner” hatten damit Probleme - wie erwartet benutzen beide automatisch GPT. Ich habe meiner Standardpolitik folgend, mehrere (genauer 4) 80 GB-umfassende Standrad-Partitionen am Anfang des Arrays und danach einen großen LVM-Bereich zur Aufnahme flexibel erweiterbarer Partitionen für Daten und spätere virtuelle KVM-Maschinen anlegen können. Es gab dabei keinerlei Schwierigkeiten.

Falls sich jemand fragt, woher die “Politik” mit den 4 Standardpartionen stammt:

Ich bringe hier bootfähige Fallbacksysteme unter, die in Notfällen in der Lage sein müssen, auch Daten in einem bestimmten Umfang aufzunehmen. Die Fallback-Systeme bestehen meist aus Abbildern bewährter Versionen auf einem bestimmten Update-Stand in Kombination mit bewährten KDE-Versionsständen. So komme ich bei größeren Problemen - wie sie im besonderen relativ häufig bei KDE-Upgrades auftreten - oder auch bei Schwierigkeiten mit LVM-Partitionen relativ schnell wieder zu laufenden Systemen, ohne komplette Neuinstallationen oder eine vollständige Restauration von Backups durchführen zu müssen. Hat man Sicherungen seiner Datenpartitionen auf Platten separater externer Systeme untergebracht, oder sind die Datenpartitionen selbst unbeschadet, so erledigt sich die Arbeit meist schon durch Einbinden der Datenpartitionen (ggf. über NFS). Abbilder der Systeme (z.B. per dd) haben sich in der Praxis schon mehrfach bewährt, wenn ein KDE-Upgrade das aktuelle System fast in die Unbenutzbarkeit getrieben hat.

Die Installation geht reativ zügig vonstatten

Aufgrund der hohen Performance des Raid 10-Arrays wird die Installation auch beim Laden vieler Serverkomponenten etc. zuügig abgewickelt. Bei der vorgenommenen Installation habe ich praktisch alle relevanten Serverkomponenten sowei eine große Zahl von Entwicklungskomponenten mit installieren lassen. Insgesamt 3,6 GByte an Paketen. Das ging wirklich zügig. Ist aber kein spezielles Verdienst von SuSE.

Probleme während der Installation

Die Weiterführung der grafischen Installation nach Ausführung von “kexec” bringt das System zum Sillstand

Nach der Installation aller Pakete versucht der Installer den neuen Kernel mit “kexec” zu laden und danach das neue System hochzufahren. Hierzu wird temporär auf die Konsolenansicht gewechselt. Danach sollte eigentlich die grafische Installationsoberfläche im aktualisierten System erneut gestartet werden; im Anschluß daran sollte die Konfiguration des neuen Systems (Geräteerkennung und Treiberimplementierung) erfolgen.

Der Wechsel des Installers auf die Konsole für die Durchführung von “kexec” funktionierte. Der Kernel wurde ordnungsgemäß mit “kexec” geladen. Danach werkelte das System noch fleissig im Verborgenen (aha - die erste Anzeichen von systemd - keine Meldungen mehr auf der Konsole!) - und dann wurde der erneute Start der grafischen Installer-Oberfläche eingeleitet. Bei mir endete das aber leider mit eine hübsch bunten Schirm aus Fragmenten und einem Einfrieren des Systems. Das System (besser X-Window) reagierte auch nicht mehr auf Tastatureingaben - ein “Ctrl-Alt-D” für ein geordnetes Herunterfahren blieb wirkungslos. Ich war also gezwungen, die Installation abzubrechen und einen Warmstart durchzuführen.

Ich möchte an dieser Stelle klarstellen, dass dieses Problem meiner Meinung nach vor allem durch die EVGA Grafikkarte meines Testsystems bedingt ist. Denn auf anderen Systemen mit moderneren Nvidia-Karten trat das hier beschriebene Problem bei einer Neuinstallation vom Opensuse 12.1 nicht auf. Je nach Treibermodul hat die Karte halt doch immer mal wieder Probleme beim Wechseln zwischen dem 1600×1200-Framebuffermodus für die Konsole und dem grafischen Installationsmodus.

Warmstart und erneutes Booten nach System V-Manier ermöglichen nach ein paar Maßnahmen die Fortführung der grafischen Installation

Was macht man in einer solchen Situation, in der man zu Beginn der automatischen Konfiguration zum Warmstart gezwungen wird? Das danach möglicherweise inkonsistente Filesystem macht einem wenig Sorge; das schafft ext4 schon. Ein fsck-Vorgang geht auf dem Raid-System zudem sehr, sehr schnell. Aber wie geht man mit dem dem offenbar problematischen Standard-Grafiktreiber (Noveau) für die Graka um?

Meine Schritte waren folgende:

Schritt 1:
Nach dem Warmstart boote ich nur in den Runlevel 3 und zur Elimination von Unwägbarkeiten zusätzlich auf “systemd” verzichten. Ersteres erreicht man durch Eingabe des Parameters “linux 3″ in die Parameterzeile des Grub-Startup-Schirms. Und für das zweite hat SuSE dankenswerterweise eine Option angeboten. Man kann auf dem Startbildschirm “F5″ betätigen und danach “System V” auswählen. Alternativ gibt man als Parameteroption

init=/sbin/sysvinit

ein. Dann wird der Startvorgang nach alter “System V”-Manier durchgeführt.

Der “System V”-Bootvorgang in den Runlevel 3 erfolgte dann problemlos. Das war auch fast zu erwarten, da die Darstellung der Konsole schon während des ersten Installationsanlaufes keine echten Probleme bereitet hatte. Der grafische Installationsvorgang wurde aber nicht sofort fortgesetzt.

Schritt 2:
Im nun erreichten Runlevel 3 habe ich als ersten geprüft, welches Grafikkartenmodul geladen war. Es war - wie vermutet - das “nouveau”-Treiber-Modul, das SuSE ja seit 11.4 als Default einsetzt. Dieses Treibermodul ließ sich auch nicht entladen - es wurde bei einem “rmmod”-Versuch als “in use” deklariert. Mit einer solchen Situation kann auch der Nvidia-Treiber-Installer nicht umgehen. Deshalb war ein erneuter Bootvorgang von vornherein unausweichlich. Als beste Methode, das System von einer Fortführung der Installation zu überzeugen, erschien es mir nach früheren Erfahrungen, KMS abzuschalten und auch die Pakete für den “Nouveau”-Treiber zu entfernen. Also habe ich mit

“Yast >> /ect/sysconfig-Editor >> System >> Kernel”

den SuSE-Konfigurationsparameter

“NO_KMS_IN_INITRD” auf “Yes”

gesetzt. Ferner habe ich über das Yast-Softwaremanagement das Paket

xorg-x11-driver-video-nouveau”

deinstalliert. Alles in der Hoffnung, dass das System nun erkennen würde, dass die automatische Konfiguration noch nicht durchgeführt oder abgeschlossen wurde. Typischerweise erkennt das SuSE-System das nämlich (wo immer SuSE diese Info hinterlegt wird).

Schritt 3:
Ich habe dann neu gebootet - wiederum mit den Parametern “linx 3 init=/sbin/sysvinit”. Und tatsächlich: Diesmal wurde direkt nach dem Hochfahren eine Meldung angezeigt, dass der Installationsvorgang wegen eines Fehlers nicht abgeschlossen wurde. Danach erfolgte direkt der Wechsel in den grafischen Modus zur Fortsetzung der automatischen Konfiguration. Die wurde auch ohne Fehlermeldungen abgeschlossen. Ein weiterer Bootvorgang in den Runlevel 3 verlief dann ohne Fehler.

Auf diese Weise hatte ich wenigstes die Installation ordnungsgemäß abgeschlossen. Ein “lsmod | grep nouveau” zeigte aber, dass nun immer noch (oder erneut?) der “nouveau”-Treiber geladen war. Dies war insofern überraschend als wir ja zumindest einen entsprechenden Kernelparameter gesetzt hatten, der zu einer Deaktivierung von KMS führen sollte. Ich habe die Einstellungen erneut mit dem sysconfig-Editor geprüft. Auch “/sbin/mkinitrd” wurde am Ende der Einstellungen im sysconfig-Editor korrekt aufgerufen.

Dennoch wird also der Nouveau-Treiber geladen. Diese Ungereimtheiten kannte ich schon von Opensuse 11.4; siehe auch:

http://www.linuxforen.de/forums/archive/index.php/t-269600.html
und
http://de.opensuse.org/SDB:Probleml%C3%B6sungen-Grafiktreiber

Aus meiner Sicht reicht das Abstellen von KMS nicht; man muss den Treiber zusätzlich “blacklisten”. Dafür gibt es mehrere Möglichkeiten - man findet einige in den Beiträgen unter folgendem Link :

http://www.linuxforen.de/forums/showthread.php?t=269600

Man kann das “Blackliste” aber auch der Nvidia-Installationsroutine für den proprietären Treiber überlassen. Die setzt nämlich bei entdecktem “Nouveau”-Treiber auf Rückfrage beim User ebenfalls einen Blacklisting-Eintrag.

Das nächste größere Ziel war nun die Ersetzung des “nouveau”-Treibers durch den proprietären Treiber. Hierzu musste das neu installierte System erst einmal netzwerkfähg werden. In meinem Fall wollte ich den benötigten Treiber nämlich einfach per “scp” von einem anderen System kopieren. Hierzu muss man neben den Netzwerkeinstellungen auch den sshd-Daemon zum Laufen bringen. (Ein Treiberdownload per Browser kam erstmal nicht in Frage, da ja nicht klar war, ob der Nouveau nicht erneut Probleme machen würde.)

Netzwerk, sshd, IPV6 und Probleme mit dem dsa-key

In meiner Testinstallation schlägt die standardmäßige DHCP-Konfiguration fehl, weil sowohl auf unserem Router als auch dem Standard-DHCP-Server des Netzes unsere “iptables”-basierten Firewalls nur uns bekannte MAC-Adressen zulassen. Für den Nvidia-Test trage ich deshalb die IP(V4)-Adresse auf dem neuen System zunächst von Hand, und zwar mittels “Yast >> Netzwerkeinstellungen” ein - und gleich auch noch das Standardgateway sowie einen DNS-Server. Alles wie von früheren Opensuse-Installationen her gewohnt - das Setzen der Parameter funktionierte einwandfrei. (Nach der Freigabe der MAC-Adresse der Netzwerkkarte auf dem Router (Standard-Gateway) kann der PC dann auch auf das Internet zugreifen.)

Noch ein wichtiger Hinweis zu IPV6: