Aufgabenstellung

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 <dc=anracona,dc=de> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
&
nbsp;
# 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.

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.