opensuse 12.3, LDAP, sssd – III

In den vorigen Beiträgen

opensuse 12.3, LDAP, sssd – I
opensuse 12.3, LDAP, sssd – II

zu meiner kleinen LDAP-Reihe für OS 12.3 bin ich darauf eingegangen, dass der OpenLDAP-Server seit OS 12.2 wegen sssd TLS/SSL-fähig ausgelegt werden muss. In diesem Beitrag treffe ich mittels YaST2 die Vorbereitungen, um die TLS-Fähigkeit zu erreichen und lege dafür Zertifikate an.

Im weiteren Verlauf des Textes bezeichne ich als “LDAP-Server” dasjenige Server-System unter Opensuse 12.3, das eine OpenLDAP-Implementierung beinhaltet. Im LDAP-Baum werden später gemäß suse-spezifischer Regeln Standardobjekte für die Beherbergung von User- und Gruppen-Informationen angelegt. Der LDAP-Baum beinhaltet dann auch die Credentials für eine User-Authentifizierung.

Ein anderer Opensuse 12.3-basierter PC oder Server, auf dem ein User, dessen Daten im LDAP hinterlegt sind, sich einloggen will, bezeichnen wir nachfolgend dagegen als Linux- “Host” unseres Netzwerkes. Ziel ist es, den User mit Hilfe des LDAP_Servers zu authentifizieren und ihm bzw. anderen Programmen auf dem Host das Arbeiten mit dem LDAP-Server zu ermöglichen.

CA und Common Server Certificate für einen LDAP-Server

Verschlüsselte Verbindungen wie TLS/SSL basieren u.a. auf Zertifikaten. Ein asymmetrisches Sicherheitsverfahren leitet die Client/Server-Kommunikation ein. Dabei werden der private wie der öffentliche Schlüssel eines Servers eingesetzt: Der Erhalt des Server-Zertifikats dient dem Client zur Prüfung der Identität des Servers. Nach erfolgreicher Authentizitätsprüfung sendet der Client dem Server eine Zufallssequenz (pre-master-secret). Dieser Austausch erfolgt verschlüsselt unter Zuhilfenahme des öffentlichen Server-Keys (aus dem Zertifikat). Server und Client berechnen dann auf Basis definierter Verfahren einen gemeinsamen Schlüssel für das anschließend eingesetzte symmetrische (und deshalb schnelle) Verschlüsselungsverfahren für den eigentlichen Datenaustausch. Weitere detailliertere Infos erhält man hier :

http://de.wikipedia.org/wiki/Transport_Layer_Security

Zertikate – im besonderen Server-Zertifikate – werden über eine übergeordnete Instanz ausgestellt. Diese Instanz ist ein sog. “Certificate Authority”, kurz CA. Bei der Kommunikation von Clients mit Servern, die sich über Zertifikate ausweisen, muss das Serverzertifikat und damit die Identität des Servers mittels Informationen der CA als unabhängiger dritter Instanz verifiziert werden.

Hatte man für sein eigenes Netzwerk bislang keine CA generiert, so wird dies nun zwingend erforderlich, wenn Netzwerk-Hosts mit ihrem SSSD den zentralen LDAP-Server zur User-Authentifizierung nutzen sollen.

Es ist wahrscheinlich, dass auf dem zentralen LDAP-Server weitere Server-Dienste laufen werden. Daher kann es sinnvoll sein, auf diesem Server ein von SuSE so genanntes “Common Server Certificate” [CSC] zu implementieren. Ich zeige kurz für zwei Fälle, wie das geht.

Neu im Vergleich zu meinem früheren Artikel Opensuse 12.1 – LDAP -II ist hier lediglich der Einsatz des CSC.

Fall 1: LDAP-Server und CA-Server sind identisch

In unserem Fall setze ich aus Testzwecken neben einer vorhandenen Root-CA eine weitere namens “anraconb” für meine Tests auf. Dies geschieht mittels des YaST2-Moduls >> “CA-Management”. Im sich öffnenden Fenster drücken wir den Button “Create CA” und
füllen im nächsten Dialogfenster die erforderlichen Informationen aus:

LDAP_OS123_2

Die CA soll logisch später für eine virtuelle Spieldomaine namens “anraconb.de” zuständig sein und Zertifikate für Server und ggf. auch Clients in dieser Domaine ausstellen. Nachdem die CA erzeugt ist, können wir diese über den entsprechenden Button in der Grundmaske des YaST2-CA-Managements “betreten”:

LDAP_OS123_3

LDAP_OS123_4

Um ein kopierbares Zertifikatsfile der CA verfügbar zu haben, exportieren wir unser Zertifikat in eine PEM-Datei. Ich lege diese in einem Verzeichnis “/etc/certs” unter dem Namen “anraconb_CA.pem” ab.

Nun legen wir dann für unseren LDAP-Server ein “Server-Zertifikat” an. Nachdem dieses später auf dem gleichen System wie die CA zum Einsatz kommen wird, handelt es sich aus Sicht der späteren Client-Hosts um ein “Self Signed Cerificate”. Aber das kümmert uns im Moment noch nicht.

LDAP_OS123_5

Bei der Bezeichnung “common name” sollte der FQDN des Servers eingetragen werden. Dies ist wichtig ! Wir werden an verschiedenen Stellen eine exakte Übereinstimmung des Zertifikatsnamens mit dem FQDN des Servers benötigen.

LDAP_OS123_6

Nachdem das Zertifikat angelegt ist, exportieren wir dieses und den zugehörigen Key in unverschlüsselter Form erneut als Dateien:

LDAP_OS123_7

Etwas scrollen hätte übrigens zeigt, dass YaST hier RSA-basierte Zertifikate und Schlüssel erzeugt:

LDAP_OS123_18

Nun zum Export als File:

LDAP_OS123_8

LDAP_OS123_9

Das Key-File enthält den “Private Key” für künftige Verschlüsselungen! Key-Files, die aus dem Certificate Management exportiert wurden, müssen daher in besonderer Weise geschützt werden und sollten zunächst nur root zum Lesen zur Verfügung stehen.

Abschließend wählen wir als weitere Exportfunktion den “Export als Common Server Certificate”.

LDAP_OS123_10

Opensuse legt dann die Dateien erneut an – allerdings an definierter Stelle, die dann später von allen möglichen YaST2-Modulen genutzt wird. Man findet die erforderlichen Zertifikats- und Key-Dateien unter

  • /etc/ssl/servercerts/servercert.pem
  • /etc/
    ssl/servercerts/serverkey.pem

Die Zertifikatsdatei der CA wird unter

  • /etc/ssl/certs/YaST-CA.pem

angelegt

Fall 2: LDAP-Server und CA-Server sind nicht identisch

Natürlich müssen wir auf dem CA-Server ein Zertifikat für den LDAP-Server ausstellen. Dieser wird dann natürlich einen anderen Namen haben – z.B. “xlamp.anraconb.de”.

Alles läuft auf dem CA-Server praktisch identisch zum oben beschriebenen Vorgehen ab, bis wir das erstellte Server-Zertifikat exportieren. Wir müssen hier einen zusätzlichen Export als “p12”-Datei vornehmen.

LDAP_OS123_17

Man beachte, dass man hier neben dem Zertifikatsnamen ein weiteres Passwort angeben muss.

Dieses File kopieren wir dann per scp auf den Zielserver – also den LDAP-Server. Am besten in das gleiche Verzeichnis “/etc/certs”. Dort schützen wir es, indem wir Lese- und Schreibrechte nur an root vergeben ! Diesen Schritt bitte nicht vergessen !

Auf dem LDAP-Server importieren wir dann das p12-File über “Yast2 >> Common Server Certificate” über die Taste “Import/Replace”. Als Ergebnis werden auf dem LDAP-Server dann in den gleichen Verzeichnissen wie oben beschrieben die notwendigen Files angelegt – u.a. auch das der CA.

Fazit

Eine CA für das eigene Netzwerk ist schnell angelegt. Für seine Server – hier den LDAP-Server – erzeugt man ebenso schnell ein RSA-basiertes Zertifikat und importiert dieses dann auf dem Zielserver mittels YaST als “Common Server Zertifikat”. Das so erhaltene Zertifikat und der private Schlüssel des Servers können dann bei der TLS-Absicherung des LDAP-Servers eingesetzt werden.

Natürlich können aber auch andere Serverdienste die Zertifikatsfiles und die generierten Schlüssel für eine SSL/TLS-Absicherung verwenden – z.B. vsftp, Apache, Cyrus IMAP.

Im nächsten Beitrag dieser Serie legen wir einen LDAP-Server unter Opensuse 12.3 an. Damit wir im Gegensatz zu früheren Artikeln bzgl. LDAP unter Opensuse 12.1 auch was neues lernen, werde ich dabei auch kurz zeigen, was man tun muss, um den LDAP-Server monitoring- und munin-fähig aufzusetzen.

Opensuse 12.3, LDAP, sssd – II

In dem letzten Beitrag zu LDAP und SSSD unter Opensuse 12.3

Opensuse 12.3, LDAP, sssd – I

habe ich ein wenig über die zwangsweise, aber unkommentierte Einführung von SSSD unter Opensuse 12.2/12.3 lamentiert. Nun ist es allerdings an der Zeit, sich produktiv mit dieser Neuerung auseinander zu setzen. In diesem kurzen Artikel fasse ich kurz einige wissenswerte Punkte zu SSSD zusammen, bevor wir uns in weiteren Artikeln mit der Konfiguration eines LDAP-Servers und von LDAP-Clients unter Opensuse 12.3 auseinandersetzen.

Ich bin allerdings kein SSSD-Spezialist. Die nachfolgenden Infos stellen lediglich eine kurze Zusammenfassung dessen dar, was ich auf die Schnelle an Infos durchgesehen habe. Ferner gebe ich einige Links an für diejenigen, die sich in SSSD und seine die Konfiguration selbst einlesen wollen.

SSSD

Vereinfachte Konfiguration für die Nutzung zentraler Informationsspeicher für die Authentisierung im Netzwerk

SSSD ist von Red Hat entwickelt worden, um Authentifizierungen gegenüber verschiedenen zentralen Authentifizierungsquellen eines Netzwerkes einfacher konfigurierbar und sicherer zu machen. Soweit ich die Dokumentation verstehe, gab es zwei wichtige Ziele:

  • Verschiedene Auth-Domainen wie LDAP, Kerberos, AD, IPA, Lokale Passwd etc. sollen in einer gemeinsamen Konfiguration behandelt werden können.
  • PAM soll bei User-Authentifizierung durch ein zentrales SSSD-PAM-Module für verschiedene Auth-Quellen unterstützt werden.

Damit sollte der Wirrwarr an unterschiedlichen Konfigurationsdateien für PAM-Module pam_ldap und pam_nss zugunsten eines zentralen Mechanismus ausgedünnt werden. Dies ist aus meiner Sicht auch ganz erfolgreich geschehen. Ich zitiere aus http://linux.die.net/man/8/sssd:

SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources as well as D-Bus interface. It is also the basis to provide client auditing and policy services for projects like FreeIPA. It provides a more robust database to store local users as well as extended user data.

Weitere einführende Links:

http://www.linuxalt.cz/files/stazeni/2012/2012-11-03-LA-206-05-Jakub_Hrozek-FreeIPA.pdf
https://fedorahosted.org/sssd/

http://www.linuxtopia.org/online_books/rhel6/rhel_6_deployment/rhel_6_deployment_sect-SSSD_User_Guide-Introduction-SSSD_Features.html
http://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/sect-SSSD_User_Guide-Introduction-SSSD_Features.html
http://lwn.net/Articles/457415/
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Introduction.html

Offline Authentication

SSSD bringt zudem “Vorteile” mit sich bzgl. der Möglichkeit einer “Offline Authentication”. “Offline Authentication” bedeutet hier, dass die Authentifizierung eines Users, dessen Credentials eigentlich auf einem LDAP-Server oder in einem anderen System liegen, auch dann noch funktionieren soll, wenn der LDAP-Server mal nicht erreichbar ist.

Das setzt eine Art lokales Caching von User-Informationen und Credentials der Auth-Quellen in einem geeigneten Format auf dem Host voraus, auf dem der Login erfolgt. PAM stützt sich dann auf die gecachte Information und erlaubt den Zugang von Nutzern durch Vergleich der eingegebenen Passwörter mit den gecachten Credentials. Klar ist, dass ein solches Caching den LDAP-Server in großen Netzwerken entlasten hilft. Wichtig kann es auch für Laptops und Notebooks sein, die zeitweise Offline gehen müssen.

Wer sich für das SSSD-Caching und dessen Konfiguration interessiert, findet Informationen hier:

http://www.linuxalt.cz/files/stazeni/2012/2012-11-03-LA-206-05-Jakub_Hrozek-FreeIPA.pdf

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Introduction.html
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html
http://dsilas.fedorapeople.org/deployment-guide/html/ch-Authentication_Configuration.html
http://linux.die.net/man/8/sss_cache

Eine interessante Anwendung für das Caching von Sudo-Regeln ist hier diskutiert.
http://jhrozek.livejournal.com/2065.html

Caching von Auth-Infos und Credentials kann aus meiner Sicht allerdings selbst wieder ein Risiko darstellen und zwar in folgender Hinsicht:

Das PAM-System des Hostes ist für den Zeitraum, in dem der SSSD-Credential-Cache gültig ist, quasi blind gegenüber Änderungen auf dem LDAP-Server. Somit muss es also Zeitlimits für das Credential-Caching der SSSD-PAM-Module geben, um die Blindheit des Hosts gegenüber zwischenzeitlichen Änderungen der Account- und Berechtigungsinformationen auf dem LDAP-Server zu begrenzen. Hierfür gibt es einen Reihe von Parametern zur SSSD-Konfiguration.

Generell ist aber keine begrenzte “expiration time” des Caches voreingestellt. Siehe:
http://forums.fedoraforum.org/showthread.php?t=277270

Andererseits mag es aber – wie im Falle von offline genutzten Laptops – sogar problematisch sein, die Caching-Zeit zu begrenzen. Ist der Laptop nach Ablauf des Zeitintervalls nicht online, ist ggf. kein Login mehr möglich.

Natürlich ist ein wie immer gearteter Cache von Credentials ein Datencontainer mit interessanten Informationen – vergleichbar einer /etc/passwd oder /etc/shadow. Das gilt auch, wenn die Credentials auf dem LDAP-System hoffentlich mit Hashes verschlüsselt abgelegt und auch in verschlüsselter Form im Cache selbst hinterlegt wurden.

Leser meiner früheren Artikel zu LDAP werden sich hier an den Einsatz des NSCD-Dämons erinnert fühlen. Tatsächlich verstehe ich die Caching-Fähigkeiten von SSSD als Ersatz für NSCD. NSCD soll zudem in großen Installation mit zentralen LDAP-Servern für viele Personen, Gruppen, Samba-Account-Infos, etc. erhebliche Stabilitäts-Probleme gehabt haben. Ich kann das nicht wirklich beurteilen. Interessierte User finden Informationen zu diesem Punkt unter
http://swik.net/opensuse/Planet+SuSE/openSUSE+TV%3A+Deploying+sssd+%28Marcus+Moeller%29/e5l4h

Links zu den verfügbaren Parametern der Konfigurationsdatei /etc/sssd/sssd.conf

http://linux.die.net/man/5/sssd.conf
http://linux.die.net/man/5/sssd-ldap
http://manpages.ubuntu.com/manpages/natty/man5/sssd.conf.5.html
http://manpages.ubuntu.com/manpages/natty/man5/sssd-ldap.5.html

In den kommenden Artikeln werden wir uns bei der Konfiguration von LDAP-Clients zumindest teilweise mit den Einstellmöglichkeiten der ssd.conf auseinandersetzen.

Opensuse 12.3, LDAP-Client, sssd erfordert TLS/SSL – I

Vor ca. einem Jahr habe ich 5 Artikel zur Implementierung von LDAP mit Hilfe von YaST2-Tools auf Opensuse 12.1-Systemen verfasst. Die einleitenden Artikel waren:

Opensuse 12.1 -LDAP I/
Opensuse 12.1 – LDAP II
Opensuse 12.1 – LDAP III

Gestern hat sich leider bei Einrichtung eines neuen Opensuse-12.3-LDAP-Servers und zugehöriger OS12.3-Client-Systeme erwiesen, dass die Übertragbarkeit dieser Artikel auf Opensuse 12.3 nicht mehr uneingeschränkt gegeben ist. YaST2’s LDAP-Client-Einrichtung erzwingt offenbar seit Opensuse 12.2 den Einsatz von SSSD und führt dadurch potentiell zu einer Reihe von Problemen. In diesem und nachfolgenden Beiträgen gehe ich auf einige dieser Punkte und ein paar damit zusammenhängende Ungereimtheiten der YaST2-LDAP-Module ein.

Background-Infos: Ankündigung der SSSD-Umstellung durch SuSE für Opensuse 12.2

Nachdem ich Probleme mit der LDAP-User-Authentifizierung bekam und diese auf SSSD zurückführen konnte, war es gestern interessant für mich, zumindest ansatzweise herauszufinden, wann und wie der Umstieg auf SSSD bei Opensuse eigentlich herbeigeführt wurde. SSSD bedeutet “System Security Services Daemon”, ist meines Wissens eine Erfindung von Red Hat und soll gerade die Interaktion mit Remote-Auth-Diensten über geeignete PAM-Module vereinfachen und sicherer machen.

Begonnen wurde mit der Diskussion und Bereitstellung von SSSD offenbar schon im Vorfeld von OS 11.4 und des SLES 11. Im Opensuse-Bereich wurde der finale Umstieg dann offenbar mit Opensuse 12.2 beschlossen. Siehe hierzu:

http://swik.net/opensuse/Planet+SuSE/openSUSE+TV%3A+Deploying+sssd+%28Marcus+Moeller%29/e5l4h
https://features.opensuse.org/308902
https://features.opensuse.org/313142
http://lists.opensuse.org/opensuse-factory/2012-02/msg00167.html

Das Video unter dem ersten Link (von der FOSDEM 2011) zeigt, dass ein wichtiges Motiv für die Einführung von SSSD neben einer Vereinfachung der Konfigurationsdateien wohl die Beseitigung von Problemen mit dem NSCD-Offline-Caching in großen Installationen war. Vielleicht nicht unbedingt ein Problem, das die Masse der OS 12.3-User, sondern wohl eher SLES-Admins betrifft. Aber vielleicht täusche ich mich da.

Nun ist eine Umstellung von Remote-Authentisierungs-Modulen aus meiner Sicht doch eine größere Änderung an einem Linux-System. Man würde daher erwarten, dazu etwas in den Release Notes von Opensuse 12.2 oder Opensuse 12.3 zu finden. Fehlanzeige !

https://www.suse.com/releasenotes/i386/openSUSE/12.2/RELEASE-NOTES.en.html
https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html

Geradezu amüsant mutet angesichts mancher Folgen dann die Diskussion der Umstellungs-Ankündigung im Opensuse Factory-Bereich an:

http://lists.opensuse.org/opensuse-factory/2012-02/msg00167.html
http://opensuse.14.
x6.nabble.com/Removing-support-for-nss-ldap-pam-ldap-from-YaST-LDAP-client-td4373062.html

Da wird lapidar das Ende von “nss_ldap” und “pam_ldap” zugunsten von sssd angekündigt. Zitat:

" According to feature #313142 (“YaST support only SSSD for LDAP based authentication”) we want to remove current nss_ldap/pam_ldap support from YaST modules and leave only support for SSSD. Target is next openSUSE realease (12.2). SSSD is there already now (12.1), but still only as an option. With new approach, we should of course provide a migration from current setups.
 
However, this also means that we will stop supporting non-encrypted connections to LDAP server, because SSL/TLS is a requirement for SSSD. So you have to prepare your LDAP servers so they are able to provide TLS."

Die Hervorhebung erfolgte durch mich. Interessant ist hier ja aber vor allem der letzte Satz, der natürlich Auswirkungen auf laufende LDAP-Installationen impliziert! Als Reaktion meinte dann einer der SuSE-Entwickler sehr zu Recht, dass das wohl Eingang in die Release Notes finden sollte. Darauf warteten wir aber leider vergeblich ….

YaST2 erzwingt die Nutzung von SSSD auf LDAP-Clients

Unter Opensuse 12.1 bot das YaST2-Modul “LDAP-Client” die Möglichkeit zur Nutzung von SSSD und zugehöriger PAM-Module bei der Interaktion mit einem LDAP-Server noch als wählbare Option an. Hier der entsprechende Screenshot von einem OS 12.1-System:

ldap_36

Ich hatte diese Option in meinen Artikeln zur LDAP-Konfiguration mittels YaST2 außen vor gelassen, da mir eine konventionelle Einrichtung des Servers und der Clients mit anschließender, kontrollierter Etablierung einer TLS-Kommunikation zwischen LDAP-Clients und LDAP-Server besser und verständlicher erschien.

Die Linux-Götter bei SuSE mögen wissen, wieso diese Option seit Opensuse 12.2 ersatzlos gestrichen wurde und “sssd” nun zwangsverordnet wird ! Ich fühle mich dadurch – trotz aller unbestrittenen Vorteile von SSSD – ungewarnt überfahren bis bevormundet. Und wie man sehen wird, gefährdet eine solches radikales Vorgehen laufende produktive Opensuse-Installationen, bei denen LDAP als Authentifizierungsmittel genutzt wird, zumindest potentiell.

Liegt es daran, dass die SuSE-Verantwortlichen Opensuse-Releases sowieso nur noch als Testplattform für den (inzwischen bei Einsatz von Virtualisierung überteuerten) SLES-Enterprise Server sehen und dass Ihnen eine Kontinuität beim Betrieb von Opensuse-Systemen herzlich egal ist? Alles unter dem wohlfeilen Deckmantel einer erzwungenen verbesserten Systemsicherheit? Die dann seltsamerweise gerade beim Einsatz von YaST2 zur Benutzerverwaltung doch nicht eingehalten wird (s.u.!) ?

Ich finde, man sollte den Opensuse-Usern die Chance geben, sich systematisch in Neuerungen/Verbesserungen einzuarbeiten, diese auszuprobieren und vor dem produktiven Einsatz verstehen zu lernen. In Sicherheitsfragen muss Überzeugung und Verständnis der Ausgangspunkt erforderlicher Maßnahmen sein. Da muss und sollte den Opensuse-Freunden eine Lernkurve zugestanden werden. Und nicht jeder baut sich mit Opensuse gleich ein Hochsicherheitsnetz auf. Für viele ist LDAP selbst ja schon eine gewaltige Herausforderung!

Wohlgemerkt:
Ich beklage nicht die Existenz oder den möglichen Einsatz von SSSD unter Opensuse 12.3 und erst recht nicht unter SLES. Ganz im Gegenteil !
Ich kritisiere aber die unkommentierte Einschränkung der Admin-Tools von YaST2 in dem Sinne, dass hier bislang fast problemfrei funktionierende Optionen zu einer sssd-freien Installation des LDAP-Dienstes
entfernt wurden. Und ich beklage zudem den eklatanten Mangel an einer Integration von entsprechenden Informationen zu SSSD und seinen Voraussetzungen in Yast2 oder aber den Release-Notes ! Letzteres vor allem im Interesse von Opensuse-Nutzern, die sich nicht dauernd und professionell mit allen Änderungen auseinandersetzen können.

Den Zwang zur Nutzung von SSSD würde man nömlich wirklich verstehen, wenn es dem unbedarften Nutzer dadurch tatsächlich leichter fallen würde, zu einem laufenden LDAP-Dienst oder clientseitig zu einer laufenden Verbindung mit einem bereits vorhandenen LDAP-Server zu kommen. Ohne bereits laufende Installation in ihrer Funktionstüchtigkeit zu gefährden. Das ist unter YaST2 aber leider nicht der Fall !

Davon zeugen hinreichend viele Artikel im Internet und Linuxforen. Man google mal zu “Opensuse 12.2 12.3 LDAP sssd TLS getent Problem” oder “Opensuse sssd PAM TLS LDAP Problem”.

Typische Probleme, die sich nach der Umstellung auf sssd ergeben können

In verschiedenen Beiträgen im Internet findet man folgende Schwierigkeiten beschrieben:

  1. User eines “Opensuse 12.3”-Client-Systems, das mit YaST2’s Modul “LDAP Client” für die User-Authentifizierung per LDAP konfiguriert wurde, werden sich gegenüber einem vorhandenen LDAP-Server, der keine TLS/SSL-Absicherung bereitstellt, nicht mehr authentifizieren können. Mit allen Folgen für produktive Opensuse-basierte Netzwerke ….
  2. “getent passwd” zeigt (ohne besondere Maßnahmen) nur noch die Liste der User an, die in der lokalen “/etc/passwd”- bzw. “shadow”-Datei erfasst sind, und nicht mehr die zusätzliche Liste der LDAP-User.
  3. Nach dem Versuch, den LDAP-Server mit einem “Self-signed Certificate” für TLS auszustatten, ergeben sich möglicherweise Probleme beim Einsatz von SSSD.
  4. Auch wenn man parallel zur LDAP-Client-Einrichtung einen neuen LDAP-Server unter Opensuse 12.3 aufsetzt, kann man eine TLS-Konfiguration umgehen und läuft dann in einem reinen OS 12.3-Netz in die oben beschriebenen Schwierigkeiten.

Das erste und wichtigste der genannten Probleme betrifft diejenigen, die ihren LDAP-Server ohne TLS/SSL-Fähigkeit betreiben. Zwar sollten zwei meiner früheren Artikel zu LDAP ja gerade zeigen, wie man TLS aufsetzt. Aber ich habe durchaus Verständnis für Leute, die einen solchen Schritt in kleineren, privaten Netzwerken erstmal gescheut haben und damit vielleicht sogar gut leben konnten. Die müssen künftig was tun.

Erkenntnisse aus eigenen LDAP-Tests unter OS 12.3

Nach mehreren Experimenten auf verschiedenen virtuellen Systemen halte ich folgende Erkenntnisse fest, die die oben dargestellten Schwierigkeiten bestätigen:

  1. YaST2 erzwingt bei der Anlage und Konfiguration eines LDAP-Clients per YaST den Einsatz von SSSD.
     
    Dies schließt aber eine Deinstallation von SSSD und ein manuelles konventionelles Setup der LDAP-Verbindungen auf Opensuse 12.3 Clients (ohne Benutzung von YaST2) nicht aus.
  2. SSSD erfordert im Zusammenhang mit einer lokalen oder einer Remote Authentifizierung über LDAP zwingend den Einsatz von TLS/SSL für die Verbindung zum LDAP-Server. Voraussetzung sind natürlich entsprechende OpenSSL-Zertifikate einer CA für den Server und entweder eine “starttls”-Fähigkeit des LDAP-Servers oder aber der Einsatz von “ldaps”. “gssapi” geht als Sicherheits-layer angeblich auch – habe ich aber nicht getestet.
  3. YaST2 erzwingt aber das Aufsetzen einer TLS/SSL-fähigen LDAP-Server-Installation unter Opensuse 12.3 nicht. Man kann die TLS-bezogenen Angaben auch einfach leer lassen und Warnungen des YasST2-LDAP-Server-Moduls
    übergehen!
  4. Auch bei der Konfiguration des YaST2-LDAP-Clients für die Anlage von User- und Gruppen-Accounts auf dem LDAP-Server wird das Initiieren einer TLS-Verbindung nicht wirklich erzwungen. Auch hier kann man Zertifikatsangaben einfach leer lassen.
  5. Die Anlage von Usern und Gruppen auf einem LDAP-Server funktioniert mit dem YasT2-LDAP-Client in der YaST2-Userverwaltung auf Rückfrage gemeinerweise auch ohne TLS. Bei Setzen einer bestimmten Option in der “/etc/sssd/sssd.conf” muss man nicht einmal eine Rückfrage beantworten. Das wirkt unter Sicherheitsgesichtspunkten eher schizophren und ist mindestens mal verwirrend. Denn man kann ja neue User ordnungsgemäß mit YaST auf einem TLS/SSL-freien dem LDAP-Server anlegen – nur kommen diese User nie zu einem erfolgreichen Login.
  6. Ein Login von vorhandenen oder neuen Usern, die über den LDAP-Server authentifiziet werden müssen, wird nach dem per YaST erzwungenen Einsatz der SSSD-PAM-Module auf einem OS 12.3-System aber ohne TLS-Fähigkeit des Servers nicht funktionieren. Und dies erwies sich in meinen Tests als sehr unabhängig von den Einstellungen in der “sssd.conf”. Ganz im Sinne der SSSD-Erfinder!
  7. Weitere Schwierigkeiten bereiten ggf. Self-Signed-TLS-Zertifikate des LDAP-Servers, wenn die entsprechenden Serverzertifikate der CA nicht auf den Client kopiert wurden und eine bestimmte Option in “etc/sssd/sssd.conf” nicht gesetzt wurde.

Die nachfolgende Abbildung zeigt, dass bei der LDAP-Client-Installation mittels YaST2 auf Opensuse 12.3-Systemen SSSD gezwungenermaßen installiert und aktiviert wird.

ldap_client_OS123_sssd_small

Bei mir sorgten die Tests für ein wenig Verwirrung bzgl. der YaST-LDAP-Module:

Bei der Abänderung der YaST2-Module hat man einerseits bei der Installation des LDAP-Clients eine Option weggenommen und SSSD auf den Clients erzwungen. Andererseits kann man bei der LDAP-Client-Einrichtung per YaST die eigentlich erforderlichen Zertifikatseingaben bzgl. des LDAP-Servers umgehen. Das wirkt irgendwie inkonsequent – Sinn würde das höchstens für andere Auth-Domainen machen, aber hier geht es ja gerade um die Einrichtung eines LDAP-Clients mit SSSD.

In der YaST2-Benutzerverwaltung kann man ferner entgegen den Sicherheitsbestrebungen von SSSD eine verschlüsselte Verbindung als LDAP-Admin beim Zugriff auf den LDAP-Server explizit vermeiden! Man kann dann beliebig und ungesichert User und Gruppen anlegen – die entsprechenden armen Anwender werden sich aber von einem Opensuse 12.3-Client aus nie mittels dem LDAP-Server ohne TLS authentifizeren können, wenn auf dem OS12.2/12.3 Client-System SSSD’s PAM-Module laufen.

Auch bei der LDAP-Serverinstallation unter OS 12.2/OS12.3 sind die Dinge nur halbherzig abgeändert – auch hier kann man auch TLS vermeiden, obwohl der Server dann nicht mit Opensuse 12.3-Clients zusammenarbeiten wird.

Ich finde: Gerade wegen fehlender Alternativen zu SSSD und des Fehlens deutliche und klarer Warnhinweise bzgl. der Konsequenzen ist das Verhalten der YaST2-LDAP-Module unter Opensuse 12.3 wirklich verwirrend. Ganz schlimm und wahrscheinlich überraschend trifft es als Konsequenz diejenigen, die neue Opensuse 12.3-Systeme einführen oder vorhandene Opensuse 12.2-Client-Systeme auf Opensuse 12.3 upgedated haben, dort die Yast2-Client-Einrichtung durchlaufen haben und die sich dann wie gewohnt gegenüber einem älteren Opensuse SLES oder Opensuse 12.1-System ohne TLS-Konfiguration authentifizieren wollen. In einem solchen Fall wird wohl gar nichts mehr gehen.

Fazit:
Das Schlimmste an den LDAP-Auth-Mechanismen von Opensuse 12.3 ist nicht der Einsatz von SSSD
sondern, dass der unbedarfte User über die Ursachen seiner resultierenden Probleme im Unklaren gelassen wird. Schon kleine zarte Hinweise auf der Startseite im YaST2 LDAP Client Modul darauf,

  • dass sssd seit Opensue 12.2 für die LDAP-Authentifizierung zwangsweise eingesetzt wird,
  • dass die Authentifizierung nicht wie gewohnt über pam_ldap ("pam_ldap.so") und nss_ldap ("libnss_ldap.so.2") erfolgt, sondern über pam_sss ("pam_sss.so"),
  • dass nur noch verschlüsselte TLS/SSL-Verbindungen zum LDAP-Server erlaubt werden,
  • dass ein vorhandener LDAP-Server ggf. entsprechend ertüchtigt werden muss,

wären wirklich hilfreich gewesen. Ganz nett wären dann noch Links zu Webseiten für eine sssd-Beschreibung und Konfigurationsoptionen gewesen. Aber da habe ich wohl zuviel erwartet.

TLS/SSL-freie Autentifizierung gegenüber einem LDAP-System trotz laufendem SSSD ?

Ganz verwirrend wird es für die verzweifelt nach einer Abhilfe suchenden OS 12.2/12.3-Anwender dann, wenn man im Internet von “Lösungen” zu einer TLS/SSL-freien Authentifizierung mit SSSD liest, wie etwa im Beitrag von “gsancome” unter

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/478283-how-do-i-disable-tls-ldap-2.html

oder hier:
http://lists.opensuse.org/opensuse-de/2013-03/msg00528.html

oder hier:
http://www.susethailand.com/suseforum/how-tofaq-%28beginner-skill%29-43/disable-tlsssl-for-ldap-on-opensuse-12-2/

Bei meinen Tests waren all diese Tipps zumindest unter Opensuse 12.3 nicht in dem Sinne wirksam, dass danach ein Login auf einem SSSD-basierten System nun plötzlich ohne SSL/TLS-Absicherung der Kommunikation zu einem LDAP-Server für die User-Authentifizierung funktioniert hätte. Nochmal im Klartext:

Ein Login von Usern mit LDAP-Authentifizierung funktioniert auf einem durch PAM und SSSD-PAM-Module geschützten Client grundsätzlich nicht, wenn der Client keine TLS/SSL-geschützte Verbindung zum authentifizierenden LDAP-Server aufbauen kann. Der LDAP-Server muss verschlüsselte Verbindungen unterstützen.

Dies gilt selbst dann, wenn es wie unter OS 12.3 auf einem Client-System als root möglich ist, die Userverwaltung unter YaST2 mit Login auf dem LDAP-Server über eine ungeschützte (!) Verbindung zu benutzen! Dass das möglich ist, liegt aber daran, dass YaST für den Kommunikationsaufbau mit dem LDAP-Server SSSD-Einstellungen über Py-LDAP-Connectivity-Module umgehen kann. Und solange der LDAP-Server auf dem normalen LDAP-Port offen sein sollte, ist ein Bind dorthin gar kein Problem. Dass hat aber mit der PAM-geschützten User-Authentifizierung und dem Login am OS12.3-Client leider gar nichts zu tun.

In den nächsten Beiträgen werde ich ein wenig näher auf ein paar Einstellungen in der “/etc/sssd.conf” eingehen und nochmal die Erzeugung von TLS/SSL-Zertifikate mittels YaST2 ansprechen. Ein sinnvoller Ausweg aus dem SSSD-Dilemma ist ja wohl der, seinen ungeschützten LDAP-Server endlich über “starttls” TLS/SSL-fähig zu machen !