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