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 !

WordPress und Anführungszeichen

Jetzt war ich so froh, die 1&1-Wordpress-Packungen hinter mir gelassen zu haben. Aber gestern hat mich dann ein Negativ-“Feature” aktueller WordPress-Versionen kalt erwischt:

Englische Zollzeichen (SHIFT+2) und einfache Anführungszeichen (SHIFT+#) werden standardmäßig in typographische Anführungszeichen umgewandelt. Dies erkennt man u.a. auch, wenn man den Quellcode der generierten Webseiten betrachtet. Dort sind die normal eingegebenen Anführungszeichen dann durch definierte Charactercodes ersetzt – und zwar doppelte wie einfache Anführungszeichen. Darüber mögen sich nun Freunde normgerechter deutscher Schriftsprachen-Zeichen sicher sehr freuen. Obwohl die Umwandlung nicht mal für alle Fonts sauber umgesetzt ist und keineswegs immer die ’66 99′-Abfolge dargestellt wird. Ich finde das ganze Theater für technisch orientierte Blogs aber geradezu als Belastung! Wegen der standardmäßig vorgenommenen Umwandlung lassen sich nämlich Informationen zu Kommando- oder Programmzeilen nicht mehr einfach aus WordPress-Beiträgen herauskopieren.

Das typographische Umsetzen von Anführungszeichen sollten die WordPress-Entwickler deshalb künftig unbedingt als abschaltbare Option definieren! Wer in Blogs unbedingt schön und normgerecht gesetzte Texte unterbringen will oder muss, mag eine solche Norm gerne nutzen. Als Standard sollte das aber nicht eingestellt sein.

Gott sei Dank gibt es hierfür aber eine Korrektur der entsprechenden PHP-Filtereinstellungen – also einen einfachen Workaround. Den entsprechenden Tipp habe ich unter

http://www.meinubuntu.de/2011/09/05/normale-anfuhrungszeichen-verwenden-in-wordpress/

gefunden! Gemäß dieses Artikels muss man die Datei “functions.php” unter dem WordPress-Menüpunkt “Design >> Editor” aufrufen und am Ende durch die Zeile

remove_filter(‘the_content’, ‘wptexturize’);

ergänzen. Das hat bei mir einwandfrei funktioniert.

Man sollte sich von der Datei “functions.php” seines Themes eine Kopie anlegen und die vorgenommene Änerung im Code deutlich durch einen Kommentar kennzeichnen – beim nächsten Update von WordPress wird diese Datei sicher überschrieben.

Weitere nette oder lesenswerte Artikel in diesem Zusammenhang sind :

http://www.interaktionsdesigner.de/2009/01/08/weg-mit-den-verdammten-anfuhrungszeichen-von-wordpress/
http://www.flomei.de/2012/04/29/deutsche-anfuhrungszeichen-in-wordpress-ohne-plugin-2/
http://www.reussmedia.de/wordpress-deutsche-anfuehrungszeichen/
http://www.elmastudio.de/wordpress/schrift-in-wordpress-optimieren-mit-dem-wp-typography-plugin/