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:

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.

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 !