Hätte nie gedacht, dass es tricky sein kann, unter Opensuse 12.1 OpenLDAP für SSL/TLS mit YaST2 einzurichten. Ist es aber – und mir ist es in einem ersten naiven Anlauf sogar gelungen, die Yast2-Umgebung so zu ruinieren, dass die YaST2-LDAP-Clients nicht mehr zur Kooperation mit mir und dem LDAP-Server zu bewegen waren.

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, so etwas in einem produktiven Netzwerk überhaupt mit den SUSE-Tools zu versuchen. Es geht aber doch … Na ja, ich sollte besser sagen: Zumindest kommt man mit den Bordmitteln von Opensuse und YaST2 ganz schön weit.

Deshalb beschreibe ich nachfolgend in einer 5-teiligen Serie von Blog-Beiträgen einfach mal die Konfigurationsschritte, die ich zum Aufbau eines einfachen LDAP-Einsatzszenarios auf einem Testserver und Test-Hosts durchgeführt habe. Alle Systeme liefen dabei unter Opensuse 12 und befanden sich in einem kleinen Netzwerk. (Faktisch war die ganze Testumgebung unter KVM virtualisiert.)

Interessant fand ich dabei die Frage, ob wir mit YaST2 allein und auf einfache Weise einen LDAP-Server und Opensuse-Hosts so aufsetzen können, dass es danach möglich ist,

• User-Account-Daten auf dem LDAP-Server von jedem anderen System aus anzulegen und zu verwalten,
• User über den LDAP-Server zu authentifizieren,
• Logins auf Hosts über das LDAP-System autorisieren zu lassen und
• für spezifische User den Zugang auf bestimmte Hosts einzuschränken.

Meine Erfahrungen bei diesem Vorhaben erwiesen sich erwartungsgemäß als gemischt. YaST2 hilft gut über die anfänglichen Hürden hinweg, denen ein LDAP-Neuling begegnet. Früher oder später muss man aber über den Tellerand der Opensuse-Tools hinausblicken und sich ein tieferes Verständnis der Zusammenhänge erarbeiten.

Mit meiner kleinen Serie von Artikeln zum Einsatz von LDAP unter Opensuse 12 möchte ich hierzu ein paar Hilfestellungen geben. An passender Stelle werde ich dabei auf Artikel im Internet verweisen, die einige spezielle Themen tiefer behandeln, als ich das in einem Blog tun kann.

Vorweg sollte ich ein paar Einschränkungen klarstellen:

• Grundlagenkenntnisse zum Aufbau eines LDAP-Verzeichnisses, der zugrunde liegenden (hierarchischen) LDAP-Datenbank und zu LDAP-Schemata werden vorausgesetzt. So sollte dem Leser bekannt sein, was “Distinguished Names” sind und was im besonderen eine “Base-DN” oder eine “Root-DN” ist. Eine Kurzeinführung bietet z.B. Wikipedia unter:
  http://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
  Ausführliche Informationen zu OpenLDAP erhält man z.B. unter
  http://www.openldap.org/doc/admin24/
• In diesem Beitrag geht es nicht um eine umfassende LDAP-Einrichtung und die Konfiguration aller möglichen Clients (z.B. Postfix, Samba) auf Netzwerk-Hosts für die effiziente Nutzung eines zentralen LDAP-Verzeichnis-Dienstes. Es geht nur darum, LDAP neben dem gewöhnlichen Passwort-Mechanismus eines Linux-Systems als Authentifizierungsbackend für den Login auf unterschiedlichen Linux-Hosts zu nutzen.
• Die Pflege der User-Accounts, Passwörter etc. auf dem LDAP-Server möchte ich – soweit möglich – mit den entsprechenden Yast2-Tools vornehmen.
• Die Verbindungskanäle der verschiedenen Linux-Hosts, die zur Authentifizierung, aber auch 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 vielmehr mit einfachen LDAP-Zugriffsvarianten, die auf sog. “Bind”-Verfahren beruhen (s. die Diskussion weiter unten). In Netzen mit geringen Sicherheitsansprüchen ist dies aus meiner Sicht ausreichend, um Authentifizierungsverfahren mit Hilfe eines zentralen LDAP-Backends durchzuführen, wenn die betreffenden Hosts im Netzwerk mit dem LDAP-Server über TLS-gesicherte Verbindungen kommunizieren.
• 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-Verzeichnis vorgehalten werden, wird beschränkt.
• Bzgl. der Sicherheit vertrauen wir in unseren Beispiel-Szenarien lediglich auf die eben erwähnte TLS-Verschlüsselung der Verbindungen zum Server, eine zeitgemäße Verschlüsselung der auf dem LDAP-System hinterlegten Passwörter sowie elementare Zugriffsbeschränkungen auf Zweige des LDAP-Verzeichnisses.

Ich versuche nun kurz, den Inhalt der kommenden Beiträge abzustecken. Unter einem “Host” verstehe ich nachfolgend ein beliebiges Linux-System in unserem Netzwerk, das vom LDAP-Server verschieden ist.

• Voraussetzung eines einfachen LDAP-basierten Authentifizierungs-Szenarios in einem Netzwerk ist in jedem Fall, dass die entsprechenden Test-User-Accounts auf dem zentralen LDAP-Server angelegt werden können. Hierzu muss man zunächst den LDAP-Server selbst aufsetzen. Wir wollen dies mit den Mitteln von YaST2 versuchen.
• Ein zweite Ziel unserer Auseinandersetzung mit LDAP unter Opensuse ist es, die Benutzer- und Gruppenverwaltung auf dem LDAP-Server mit YaST2-Tools abzuwickeln. Voraussetzung hierfür ist die korrekte Einrichtung der YaST2-LDAP-Clients für die “YaST User- und Gruppenverwaltung”. Und dies nicht nur auf dem LDAP-Server selbst sondern auch auf anderen Netzwerk-Hosts.
• Ein weiteres Ziel ist es, einen User-Login sowohl auf einem weiteren Host als auch auf dem LDAP-Server selbst über eine Authentifizierung durch das LDAP-Backend autorisieren zu lassen. Zur Überwachung von Login-Vorgängen sollen klassische Linux-Tools (PAM in Kombination mit NSS; s.u.) eingesetzt werden, die LDAP neben möglichen anderen Authentifizierungsverfahren nutzen sollen. Diese Tools müssen dazu als Linux-Clients konfiguriert werden – auf unseren Netzwork-Hosts und natürlich auch auf dem LDAP-Server selbst. Insgesamt müssen wir also sowohl PAM/NSS als auch die YAST2-Module zur User-Verwaltung auf unseren Netzwerk-Hosts zur Verwendung von LDAP und zur Kommunikation mit dem LDAP-Server einrichten. Interessant ist die Frage wie diese unterschiedlichen LDAP-Clients auf unseren Netzwerk-Hosts miteinander interagieren.
• Alle erforderlichen “LDAP-Clients” kommen nicht nur auf dem LDAP-Server, sondern vor allem auf Netzwerk-Hosts, die ganz unabhängig vom LDAP-Server sind, zum Einsatz. Der jeweilige Host muss dann mit dem LDAP-Server über eine TCP/IP-Verbindung kommunizieren (Ports: 389 und ggf. auch 636). Die Verbindung soll dabei durch Verschlüsselung geschützt werden. Der Schutz des Zugriffs auf den LDAP-Server soll sowohl für den pflegenden Administrator, der YaST2 nutzt, als auch für PAM/NSS sowie andere LDAP-Clients (u.a. Kommandozeilentools) über eine TLS-gesicherte Verbindung gewährleistet sein. Hierfür müssen der Server wie auch die LDAP-Clients auf den Netzwerk-Hosts passend eingerichtet werden.
• PAM kann über bestimmte Module sog. “Policies” etablieren, denen die
  Qualität von Passwörtern gehorchen muss. Das wirft die Frage auf, ob man mittels LDAP statt einer lokalen auch eine zentrale Passwort-Politik für die User eines Netzwerkes etablieren kann. Wenn ja: Wie unterstützt einen YaST2 in diesem Zusammenhang?
• Auch auf dem LDAP-Server selbst wird man ggf. LDAP-basierte Authentifizierungsmechanismen einsetzen wollen; schließlich muss man sich als User auch dort authentisieren. In diesem Zusammenhang stellt sich dann aber die klassische Frage eines Netzwerk-Administrators, welche User eigentlich auf den LDAP-Server oder andere Hosts und Server zugreifen können sollen. Dies führt zu der sicherheitsrelevanten Problemstellung, wie man mit Hilfe von LDAP für einzelne User Zugriffseinschränkungen auf spezifische Hosts verwalten und im Netzwerk durchsetzen kann.

Damit ist der Themenkreis der kommenden Beiträgsserie “LDAP I” bis “LDAP V” gut umrissen.

In diesem ersten Beitrag “LDAP I” beschreibe ich zunächst die Einrichtung des LDAP-Servers mit YAST2-Tools – allerdings noch ohne TLS-Fähigkeiten. Wir werden dabei für erste Tests bereits die YaST2-Tools zur “User- und Gruppenverwaltung” auf dem Server nutzen.

Der zweite Teil “LDAP II” beschreibt dann das Anlegen eines SSL-Zertifikats für den LDAP-Server und dessen Konfiguration für die Unterstützung von SSL/TLS-Verbindungen.

Im Teil “LDAP III” gehe ich dann auf die Konfiguration der YaST2 “User- und Gruppen-Verwaltung”, von PAM/NSS als auch von klassischen LDAP-Kommandozeilen-Tools als LDAP-Clients auf beliebigen Netzwerk-Hosts ein. Die Konfiguration dieser Clients berücksichtigt dabei die Anforderung nach einer TLS-Verschlüsselung. Wir betrachten im Beitrag “LDAP III” zudem das Zusammenspiel von PAM und LDAP etwas genauer; geleitet werden wir dabei von den erforderlichen Einträgen in den PAM-Konfigurationsdateien.

Im Beitrag “LDAP IV” befasse ich mich schließlich mit der Etablierung einer zentralen Password-Politik über den LDAP-Server. Dabei werden wir unser Verständnis der Wechselwirkung zwischen PAM und dem LDAP-Server zwangsläufig vertiefen. Es wird sich zeigen, dass die LDAP-basierte Password-Politik eine lokale PAM-basierte Politik nicht ersetzen sondern nur ergänzen kann.

Im Beitrag “LDAP V” zeige ich abschließend anhand zweier einfacher Verfahren, wie man mit LDAP Zugriffsbeschränkungen für spezifische Hosts realisiert. Dabei werden wir erstmalig auf andere Werkzeuge als YaST2-Tools zurückgreifen müssen.

Hinweis:
Es empfiehlt sich übrigens, alle Experimente in einer z.B. mit KVM virtualiserten Test-Umgebung vorzunehmen, bevor man sich an die produktiven Systeme seines Netzwerkes heranwagt. Ich habe beim Test von Serverkonfigurationen generell sehr gute Erfahrungen mit virtualisierten Servern in einem separaten, ggf. ebenfalls virtualiserten Netzwerksegment gemacht.

Punkt 1: Einige Vorüberlegungen vor der Serverinstallation

Welche Verfahren/Module für die User-Authentisierung bzw. -Authentifizierung 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 dieser Artikelserie mal unter den Tisch fallen.]

Die genannten Module sind auf den meisten Linux-Systemen als Standard installiert. Sie steuern und überwachen auch unter Opensuse 12 die Authentifizierung eines Users mit Hilfe verschiedener Backends. U.a. können sie als LDAP-Clients fungieren und auf externe (oder interne) LDAP-Systeme zugreifen. Die Interaktionskette, mit der ein User sich gegenüber einem zentralen LDAP-Server zu authentisieren versucht und mit der die Authentifizierung vom LDAP-Server vorgenommen wird, sieht dabei etwa so aus:

Login- und Authentisierungs-Versuch eines Users mit UID und Passwort auf einem Linux-Host im Netzwerk
>>
NSS/PAM entscheidet auf dem Host über den Authentifizierungsweg und stößt verschiedene Authentifizierungsvorgänge an
>>
PAM nimmt bei Versagen anderer Mechanismen schließlich 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 zum 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 Linux-Host gewährt.
 

Was unter einem “BIND” genauer zu verstehen ist, bespreche ich weiter unten.

Wir kümmern uns in diesem ersten LDAP-Artikel noch nicht um Details der PAM-Bedingungs-Kaskade für eine hinreichende Authentifizierung auf einem Linux-Host (siehe aber “LDAP III”). Das Schöne an Opensuse ist nämlich, dass uns YaST2 sowohl auf dem Server als auch auf anderen Hosts die grundlegenden Arbeitsschritte im Rahmen der Konfiguration der “Yast2-User und Gruppenverwaltung” für die LDAP-Nutzung abnimmt. Wir akzeptieren zunächst einfach, dass Opensuse bei der Einrichtung der YAST2-Benutzerverwaltung Standardeinstellungen für eine hinreichende User-Authentifizierung vornimmt. Welche Konfigurationsdateien welcher potentiellen LDAP-Clients von YaST2 wie beeinflusst werden, sehen wir uns später aber noch im Detail an.

Bevor wir den LDAP-Server mittels YaST2 einrichten, noch ein paar Hinweise zu gedanklichen Fehlern, die man beim Einsatz 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 davon abhängig, auf welchem aktuellen Update-Zustand sich das Opensuse 12.1-System befindet und wie man diesen Zustand erreicht hat – über eine Neuinstallation oder aber über Upgrades von früheren Opensuse 11-Systemen aus.

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 YaST2 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 CLI-Kommandos “ldapmodify”,
“ldapadd” und “ldapdelete” durchführen, wenn man ein direktes Editieren scheuen sollte.

Benutzerauthentifizierung auf einem Host unter Nutzung eines zentralen LDAP-Verzeichnisses ist logisch etwas anderes als die konkrete Authentisierung eines Users oder Systems gegenüber dem LDAP-Server, um Zugang zu den dort hinterlegten Informationen zu erhalten

Im Zuge eines Loginversuch eines Users auf einem Linux-Host werden die User-Credentials über PAM-Module mit entsprechenden Einträgen in der Datenbank des LDAP-Servers verglichen. Der LDAP-Verzeichnisdienst und seine Einträge werden dabei also als Mittel zur User-Authentifizierung für den Host-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 sekundäre, also LDAP-externe Auth.-Mechanismen (wie SASL) und andere Sicherheitslayer eingesetzt werden,
• Es werden diejenigen Informationen, die im LDAP-System selbst zu Usern, Systemen und 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 verwendete “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. Ein LDAP-Server bietet hierfür ein ausgeklügeltes System zur Rechteverwaltung für Zugriffe auf spezifische LDAP-Inhalte – z.B. in einem bestimmten Zweig des Verzeichnisbaumes – an. Die Zugriffsrechte werden in einer bestimmten Konfigurationsdatei des LDAP-Servers hinterlegt. Siehe hierzu etwa http://www.openldap.org/doc/admin24/access-control.html.

Will man eine LDAP-Zugangsautorisierung über “Binds” generell 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 von YaST2 gesetzten Standardrechte bzgl. der im LDAP-System erfassten Linux-User- und Gruppen-Daten entscheiden letztlich darüber, ob Authentisierungs-Clients wie PAM sich über spezielle LDAP-Identitäten und zugehörige Binds Zugang zum LDAP-System verschaffen müssen. Bei Opensuse 12.1 ist ein lesendes Durchsuchen des gesamten LDAP-Baumes jedoch auch bei anonymen Zugriffen durchaus gestattet.

Die erste der oben genannten LDAP-Zugriffsvarianten wird in professionellen Umgebungen 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 eine User-Authentifizierung 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”-CLI-Kommandos in der Lage sein, das LDAP-System und auch dessen modulare “cn=config”-Konfigurationsdateien 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 weiter unten noch einmal explizit zurück.

Unabhängig von diesem Sonderfall erfolgen andere Zugriffe – u.a. auch die durch PAM ausgelösten Authentifizierungsanfragen von einem beliebigen Host aus – in der Standardeinstellung von Opensuse 12.1 aber lediglich über klassische “Binds”.

Punkt 2: Elementare Einrichtung und Konfiguration eines LDAP-Servers mittels YaST2

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 YaST2-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.

Nachtrag 17.06.2012 zum LDAP-Backend für die Datenhaltung:

Bei Opensuse 12.1 ist das Standard-Backend für das OpenLDAP-System die BDB [Berkeley Database]. Zu den heute möglichen Backend-Varianten siehe etwa http://linux.die.net/man/5/slapd.backends.

Auf der letzten der dargestellten Masken kann man zwischen speziellen Varianten der BDB wählen (“bdb” oder “hdb”). Zu der Backend-Variante HDB, die als echte hierarchische Datenbank realisiert ist und bei der man bei Bedarf auch ganze Zweige der späteren LDAP-Datenhierarchie umbenennen kann, siehe z.B. die Hinweise unter
http://www.highlandsun.com/hyc/ldapguide/backends.html,
http://onlamp.com/onlamp/2007/09/13/an-openldap-update.html und
http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=slapd-hdb.
Man beachte insbesondere den Hinweis zur “idlecachesize” beim Performancetuning im ersten Link.

Direktiven zur Einrichtung der BDB-Backends findet man hier:
http://www.zytrax.com/books/ldap/ch6/bdb.html,
speziell für die “bdb” hier: http://linux.die.net/man/5/slapd-bdb
und für die “hdb” hier: http://linux.die.net/man/5/slapd-hdb.

Ich habe im oberen Beispiel die “hdb” gewählt. Lesern, die im ersten Schritt keine Experimente machen wollen, sei aber die “bdb” ans Herz gelegt.

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 unser LDAP-
Verzeichnis 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.