Im ersten Teil “SASL mit PAM, SSSD, LDAP unter Opensuse – I” dieser kleinen Beitragsserie zur Nutzung von SASL, PAM, SSSD im Zusammenhang mit einem (einfachen) LDAP-System hatte ich dargestellt, was man grundsätzlich tun muss, um eine Authentifizierung im Rahmen der Kette

SASLAUTHD => PAM => SSSD => LDAP

zu realisieren.

Den Host, auf dem ein Service “saslauthd” nutzt, nennen wir nachfolgend “c-serv“; der LDAP-Server im Netz heiße dagegen “ldap-serv“. Beide liegen in einer Domaine “anraconx.de“.

So schön das verkettete Auth-Verfahren auch sein mag – es hat in der bisher dargestellten Form einen gravierenden Nachteil:

Nach der beschriebenen Einrichtung von PAM, SSSD und LDAP als Auth-Backend ist es jedem User, der einen gültigen Eintrag auf dem LDAP-Server hat, möglich, sich auf jedem Host, auf dem die PAM-SSSD-LDAP-Kette eingerichtet wurde, einzuloggen und eine Shell zu nutzen. Dabei würde sogar ein Home-Verzeichnis eingerichtet werden. Dieses Verhalten ist für dedizierte Server, die nur einen bestimmten Dienst – wie etwa einen Mail-Dienst – anbieten, aber gar nicht wünschenswert. Der Grund liegt natürlich in Sicherheitsaspekten: Man sollte keine Rechte einräumen, wenn dies zur Nutzung eines bestimmten Serverdienstes gar nicht erforderlich ist.

Wir müssen uns daher bzgl. des Zugangs zum Serverhost etwas andere Ziele stecken und diese mit möglichst geringem Aufwand realisieren.
Wir diskutieren eine Vorgehensvariante nachfolgend am Beispiel eines IMAP-Dienstes, der auf “c-serv” angeboten wird.

Ziele der Authentifizierungskette auf dem Server-Host “c-serv”

• Die User, die auf dem LDAP-System hinterlegt sind, sollen nicht autorisiert werden, sich auf dem Host “c-serv” normal einzuloggen. Sie dürfen keinen Shell-Zugang erhalten.
• Die im LDAP verwalteten User sollen sich aber sehr wohl für die Nutzung eines bestimmten Serverdienstes – wie etwa eines IMAP-Dienstes – authentifizieren können und zwar letztlich durch einen sog. “Simple Bind” auf dem LDAP-System.
• Dabei soll die Verbindung zwischen “c-serv” und “ldap-serv” wie bereits früher beschrieben mit TLS abgesichert aufgebaut werden.
• Über spezielle Einträge auf dem LDAP-Server soll der Zugang zum Host “c-serv” für bestimmte User auch generell ausgeschlossen werden können.

Auf unserem “c-serv”-Server sollen ein Login und eine Shell-Nutzung nur für den User “root” und ggf. für dedizierte, lokal angelegte User (wie etwa “cyrus”, den Admin des Cyrus IMAP-Dienstes) möglich sein. Verdeutlicht wird dies durch folgende beispielhafte Abbildung:

Aus der Skizze wird bereits der Lösungsansatz erkennbar, den wir nun schrittweise umsetzen. Zwei explizite Warnungen sind angebracht:

Warnung 1:
Die vorgeschlagenen Konfigurationsänderungen können bei Fehlern dazu führen, dass sich auch root nicht mehr auf “c-serv” einloggen kann. Also bitte Vorsicht walten lassen und das ganze Verfahren zunächst auf einem Spielsystem testen, bevor man es auf produktive Systeme
anwendet !

Warnung 2:
Wir werden LDAP als Authentifizierungs-Backend abschalten und dann etliche grundlegende Konfigurationsdateien ändern. Danach darf man die YaST-Konfigurationstools für den LDAP-Client oder für die Backend-Einrichtung zur User-Authentifizierung nicht ohne Wissen um die Konsequenzen nutzen – denn YaST stellt u.a. bei einem Aktivieren des LDAP-Clients zu viele Dinge parallel und automatisch um und würde unsere vorgenommenen Einstellungen ggf. wieder zunichte machen. Also Backups der eigenen Konfigurationsdateien anlegen.

Schritt 1: LDAP-Backend für die User-Authentifizierung abstellen

Als erstes stellen wir mittels “YaST2 => User und Group Administration => Reiter “Authentication Settings” => LDAP” und durch den entsprechenden Radiobutton im Dialogfenster die Benutzung von LDAP als Auth-Backend für das System ab. YaST stoppt dann u.a. den sog. “LDAP-Client”, indem es SSS (besser den SSSD-Dämon) deaktiviert; dies entspricht einem

systemctl stop sssd.service;   systemctl disable sssd.service    .

Die Einstellungen der Datei “/etc/sssd/sssd.conf” bleiben dabei aber erhalten. Das ist aber nicht ganz das, was wir uns wünschen:
Wir wollen ja, dass der Cyrus IMAP-Service später den “SSSD-Service” nutzen soll. Aber im Zuge einer “normalen” Login-Authentifizierung soll sich PAM auf die Prüfung lokaler Informationsquellen beschränken. Deshalb müssen wir noch weitere Schritte durchführen, bevor wir SSSD wieder aktivieren.

Schritt 2 – SSS aus der “Name Service Switch-Konfiguration” entfernen

Wir entfernen die “sss”-Einträge in der Datei “/etc/nsswitch.conf”. Also:

#passwd: compat sss
#group: compat sss
passwd: compat
group: compat

Diese Einstellung entspricht dem blockierenden roten Längsstrich im NSS-Block der Skizze.

Schritt 3 – “pam_sss.so”-Modul aus den PAM “common”-Dateien entfernen

Dann entfernen wir zusätzlich alle “pam_sssd.so“- Referenzen in den Dateien

“/etc/pam.d/common-auth”,
“/etc/pam.d/common-account”,
“/etc/pam.d/common-password”,
“/etc/pam.d/common-session”.

Betroffen ist pro Datei jeweils eine der folgenden Zeilen:

auth required pam_sss.so try_first_pass
account required pam_sss.so use_first_pass
password required pam_sss.so use_authtok
session optional pam_sss.so

Diese Einstellung sorgt dafür, dass PAM für viele vorgegebene Dienste auf einem Standard Opensuse-System nurmehr lokale Informationsquellen prüft.

Schritt 4 – “pam_sss.so”-Modul in die PAM-Datei für die Dienste eintragen, die per SSSD eien LDAP-Prüfung durchführen sollen

Wir demonstrieren dieses Vorgehen am Beispiel der service-spezifischen Datei “/etc/pam.d/imap” für den IMAP-Dienst und ersetzen deren Inhalt durch folgenden:

c-serv:/etc/pam.d # cat imap
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass
auth required pam_sss.so use_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account sufficient pam_localuser.so
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_sss.so
c-serv:/etc/pam.d #

Oder
alternativ:

#%PAM-1.0
auth sufficient pam_sss.so
auth required pam_env.so
auth required pam_unix.so try_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account required pam_localuser.so
session optional pam_sss.so
session required pam_limits.so
session required pam_unix.so try_first_pass

Wichtig ist in jedem Fall die Reihenfolge der Statements. Warum die komplizierte Abfolge aus “required”- und “sufficient”-Bedingungen?

Weil wir wollen, dass neben den LDAP-Usern auch lokale User auf den angebotenen Dienst zugreifen dürfen. Dieser Bedarf besteht im falle von IMAP mindestens mal für den User “cyrus“; dieser muss ja den IMAP-Dienst und im Besonderen auch die Mailboxen verwalten dürfen. Dazu muss er eine Zugriffsberechtigung erhalten.
Es bleibt dem geneigten Leser überlassen zu überlegen und ggf. zu testen (ein Blick in “/var/log/messages” lohnt sich), warum man dann die vorgegebene Reihenfolge für die PAM-Module einhalten muss.

Schritt 5 – den “sssd.service” wieder aktivieren und Zugriffe testen

Nun enablen wir erneut den “SSSD-Dämon” und starten ihn:

systemctl enable sssd.service
systemctl start sssd.service

Wir können nun durch z.B. einen ssh-Zugriff prüfen, dass für die Testuserin “tarja” (s. den erste Beitrag der Serie) kein Login mehr möglich ist:

c-serv:~ # testsaslauthd -s login -u tarja -p TARJAPWD
0: NO “authentication failed”

und :

c-serv:~ # su – tarja
su: user tarja does not exist
c-serv:~ #

bzw. remote:

user@tux:~> ssh tarja@c-serv
Permission denied (publickey,keyboard-interactive).
user@tux:~>

Dagegen:

c-serv:~ # testsaslauthd -s imap -u tarja -p TARJAPWD
0: OK “Success.”

Wir löschen nun das Verzeichnis “/home/tarja” (soweit vorhanden). Sicherstellen müssen wir noch, dass “root” handlungsfähig ist und ins System kommt :

user@tux:~> ssh root@c-serv
Password:
Last login: Wed Mar 12 17:50:39 2014 from tux.anraconx.de
Have a lot of fun…
c-serv:~ #

und

c-serv:~ # testsaslauthd -u cyrus -p CYRUSPW
0: OK “Success.”

Sieht alles OK aus. 🙂 Was haben wir erreicht ?

Die im LDAP vorhandene “tarja” wie jeder andere im LDAP hinterlegte User kann sich nicht mehr auf dem System “c-serv” einloggen, aber “saslauthd” authentifiziert potentielle Benutzer des IMAP-Dienstes trotzdem über den LDAP-Server! Zudem kann auch der lokale User “cyrus” auf den IMAP-Dienst zugreifen.

Unterbinden des Zugriffs auf den Server-Host für bestimmte User

Die oben verfolgte Politik ist bislang immer noch eine, die allen Nutzern, die im LDAP hinterlegt sind, auch einen Zugriff auf IMAP-Dienste zugesteht. Dennoch will man i.d.R. einige Benutzer explizit nicht an unsern Server-Host “c-serv” (oder zumindest nicht an spezielle Dienste wie IMAP) heranlassen. Welche Möglichkeiten hat man dazu?

Variante 1: “host”-Attribut in den LDAP-User-Einträgen setzen und auswerten
Alternativ kann man bei den User-Einträgen, die man ausschließen will, auf dem LDAP-System das Attribut “host” hinzufügen und SSSD so konfigurieren, dass dieses Feld abgefragt wird. Siehe zu Letzterem:
https://access.redhat.com/site/
documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/config-sssd-domain-access.html

Wie man das Attribut “host” dem User-Eintrg hinzufügt, wenn man den Zweig “ou=people,dc=anraconx,dc=de” ursprünglich mit YaST angelegt hatte, habe ich unter
Opensuse 12.1 – LDAP V
beschrieben. (anraconx ist hier nur eine Beispielname und durch die eigene Domain zu ersetzen).

Wir nehmen mal einen User “rmu”, der auf dem LDAP-System vorhanden sei. Ich ergänze mit Hilfe des Tools “gq” wie in Opensuse 12.1 – LDAP V beschrieben, seine ObjectClasses um “extensibleObject” und füge dann das Attribut “host” zum Satz hinzu:

Als Wert des Feldes gebe ich dann – im Gegensatz zur Abbildung! – zunächst “c-serv.anraconx.de” an. Der FQDN muss natürlich auf dem netzwerkeigenen DNS-Server bekannt sein. (In der Praxis würde man statt mit “gq” natürlich mit LDIF-Dateien für alle betroffenen User arbeiten.)
Dann ändern wir auf “c-serv” die Standard-SSSD-Konfiguration, die wir gem. SASL mit PAM, SSSD, LDAP unter Opensuse – I angelegt hatten:

[sssd]
config_file_version = 2
services = nss,pam
domains = default
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
 
# Section created by YaST
[domain/default]
ldap_uri = ldap://ldap-serv.anraconx.de
ldap_search_base = dc=anraconx,dc=de
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls = False
enumerate = True
cache_credentials = False
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/YaST-CA.pem
chpass_provider = ldap
auth_provider = ldap
 
access_provider = ldap
ldap_access_order = host

Wichtig und neu sind lediglich die zwei letzten Zeilen. Infos zur Bedeutung der Parameter findet man hier:
http://manpages.ubuntu.com/manpages/precise/en/man5/sssd-ldap.5.html

Neustarten des sssd.service nicht vergessen:

c-serv:~ # systemctl restart sssd.service

Dann versuchen wir einen Login auf c-serv

tux:~ # ssh -X rmu@c-serv
Password:
Last login: Sat Mar 15 16:06:56 2014 from tux.anraconx.de
Have a lot of fun…
rmu@c-serv:~>

Nun ändern wir den Wert des LDAP-Attributs “host” auf “!c-serv.anraconx.de” ab !
Das führt zu:

tux:~ # ssh -X rmu@c-serv
Password:
Permission denied (publickey,keyboard-interactive).
tux:~ #

Aha ! Hosts schließen wir explizit mit einem “!” aus, das dem FQDN im “host”-Attribut auf dem LDAP-Server vorangestellt wird. SSSD prüft erst auf solche Einträge, danach auf explizit freigegebene Hosts.

Lassen wir unsere “sssd.conf” nun aber so, wie sie ist, kommt allerdings auch unsere Testuserin “tarja” nicht mehr aufs System, wenn wir nicht auch bei ihr das “host”-Attribute mit “c-serv.anraconx.de” füllen. Analog für alle anderen User. Es wird also Zeit, dies mit passenden LDIF-Dateien anzugehen. Eine mögliche Einstellung im “host”-Attribut ist übrigens auch “allow_all“.

Erweiterte Variante 2 : Zusätzlich das Attribut “ldap_user_authorized_service” abfragen
Man kann mit SSSD aber offenbar noch feingranularer arbeiten und den Host zulasssen, nicht aber den Zugriff eine bestimmten Service wie “imap”. Hierzu dient
die Abfrage eines Attributs “ldap_user_authorized_service”. Hierzu muss allerdings auf dem LDAP-Server zusätzlich das “ldapns”-Schema geladen werden. Wie man dafür auf einem Openldap-System 2.4 vorgeht, findet man hier:
http://grungelabs.com/guides/2012/06/08/ha-openldap-debian/
http://wiki.ubuntuusers.de/OpenLDAP_ab_Precise

Ich habe das aber selbst nicht für LDAP-Server getestet, die mit YaST eingerichtet wurden. Es mag daher Inkompatibilitäten geben. Wenn ich Zeit finde, behandle ich das mal in einem separaten Beitrag.

Auf den meisten Linux-Systemen ist von Haus aus ja das generische Framework PAM zur Login- und Berechtigungskontrolle im Einsatz. PAM kann über entsprechende Module mit mehreren Backends – wie z.B. ein LDAP-System – Kontakt aufnehmen und dortige Authentifizierungsdaten abfragen. Etliche Serverdienste – wie z.B. Cyrus IMAP – nutzen dagegen das “Cyrus SASL“-Framework und seine Sub-Services zur Authentifizierung von Anwendern. Auch SASL kann über Submodule – ähnlich wie PAM – verschiedene Authentifizierungs-Backends direkt ansprechen. Eine dritte Klasse von Services wiederum nutzt SASL nur als Zwischenschicht und delegiert die Authentifizierung an andere Verfahren wie PAM.

Insgesamt ergibt sich so eine große Bandbreite an Authentifizierungsverfahren, mit denen sich der Linux-Admin potentiell herumschlagen muss. Hat man ein Opensuse-Server-System vorliegen, bei dem die

• die per SASL zu authentifizierenden User identisch mit Systembenutzern sind,
• die zu authentifzierenden User gleichzeitig auf einem zentralen OpenLDAP-Server verwaltet werden,
• der SSSD-Dämon zum Einsatz kommt, um TLS-Verbindungen um LDAP-Server zu erzwingen

so möchte man zur Vereinfachung ggf. gerne folgende Authentifizierungskette nutzen:

SASL => PAM => SSSD => LDAP

• SASL nutzt als erstes PAM,
• PAM wiederum greift auf SSSD (sss.so-Module) zu,
• SSSD nutzt über einen erzwungenen, verschlüsselten TLS-Kanal schließlich LDAP als Authentication-Backend.

Der letzte Aspekt erlaubt dann auch die Nutzung von “PLAIN”-Mechanismen – also die Weitergabe unverschlüsselter Passwörter an ein Backend-System – ohne zu große Sicherheitslücken zu reißen. Ich beschreibe in diesem Beitrag kurz, wie man die genannte Sequenz für die Authentifizierung unter Opensuse zum Laufen bringt. Dabei betrachte ich nur die einfachst mögliche Konfigurationsvariante, die man allein mit Bordmitteln von Opensuse bewerkstelligen kann.

Voraussetzung: TLS-fähiger LDAP-Server

Wie man mit Hilfe von Opensuse 12.1 eine einfache, zentrale und LDAP-basierte User-Authentifizierung im Netzwerk ermöglicht, habe ich in einer Sequenz von Beiträgen zu OpenLDAP in diesem Blog bereits erläutert.

Opensuse 12.1 – LDAP I – Opensuse 12.1 – LDAP II – Opensuse 12.1 – LDAP III – Opensuse 12.1 – LDAP IV – Opensuse 12.1 – LDAP V

Hinweis zur LDAP-Einrichtung unter Opensuse 12.3 und 13.1:

Unter Opensuse 12.3 funktioniert die LDAP-Einrichtung leider nur fast genauso wie für Opensuse 12.1 beschrieben. Man wird bei der LDAP-Client-Einrichtung gezwungen, SSSD einzusetzen und TLS als Verschlüsselungsmechanismus für die Verbindung zum LDAP-Server zu aktivieren. Das bedeutet,

1. dass die SSS-Pakete installiert werden müssen,
2. dass auch auf dem LDAP-Server SSSD aktiv sein muss und der LDAP-Server TLS-fähig einzurichten ist.

Die Einrichtung von TLS ist in meinen LDAP-Artikeln ausführlich erläutert. Ich habe zum Setup eine zentrale CA im Netz genutzt.
Sowohl auf dem LDAP-Serversystem als auch auf den LDAP-Client-Hosts sind SSL-Zertifikate bereitgestellt worden. Wie man die erstellt, ist ebenfalls im Rahmen der Artikel zu LDAP beschrieben. Wir gehen in diesem Beitrag nur kurz darauf ein.

In der Beschreibung der LDAP-Client-Kommunikation mit dem LDAP-Server fehlten in meinen Blog-Artikeln bislang allerdings Ausführungen dazu, wie man dabei SSSD im Zusammenhang mit PAM nutzt. Wir erledigen dies in diesem Artikel mit. Es lohnt sich also, erst den vorliegenden Artikel bzgl. der SSSD-Einrichtung zu lesen, wenn man noch vor der LDAP-Server-Einrichtung mit Opensuse 12.2/12.3/13.x stehen sollte.

Ansonsten setzen wir für diesen Artikel voraus, dass es im Netz einen TLS-fähigen LDAP-Server gibt, dessen Baum mit klassischen Objekten für die User- und Gruppenverwaltung unter Opensuse bestückt ist. Die Objekt-Struktur kann man (einmalig) bei der LDAP-Client-Einrichtung auf dem LDAP-Server mittels “YaST2 >> LDAP-Client” anlegen lassen. Das sollte man aber wirklich nur genau einmal tun – nämlich bei der LDAP-Client-Einrichtung per YaST2 auf dem LDAP-Server selbst. Bei der Einrichtung weiterer Systeme als LDAP-Client muss man die erneute LDAP-Struktureinrichtung per YaST tunlichst unterlassen! S. hierzu meine LDAP-Artikel.

Weiter setzen wir voraus, dass es im LDAP-Baum einen User “tarja” gibt, den wir für Tests benutzen können. In der sehr einfachen Konfiguration dieses Artikels verwenden wir keine Host- und User-spezifischen Zugangsregeln. Dafür muss ein späterer Artikel herhalten.

Server- und Domain-Bezeichnungen für unser Konfigurationsbeispiel

Der LDAP-Server heiße nachfolgend “ldap-serv“, der Server auf dem SASL und PAM in Verbindung mit dem LDAP-Server Nutzer im Netz authentifizieren sollen, heiße “c-serv“. Beide seien in einer Domaine “anraconx.de” beheimatet:

• ldap-serv.anraconx.de
• c-serv.anraconx.de

Diese Domaine sei auch charakteristisch für den zu durchsuchenden Zweig des LDAP-Baums:

dc=anraconx,dc=de

bzw.

ou=people,dc=anraconx,dc=de
ou=group,dc=anraconx,dc=de

Bzgl. der SSL-Zertifikate gilt, dass diese für die Hosts mit FQDN ausgestellt wurden.

Server-Zertifikat und Übertragung des öffentlichen CA-Keys auf den LDAP-Client-Host

Unser Server “c-serv” (= LDAP-Client), auf dem SASL, PAM und LDAP genutzt werden sollen, erhält ein Serverzertifikat der zentralen CA (die z.B. auf dem zentralen LDAP-Server eingerichtet sein kann). Das Ausstellen eines “Common Server Certificates” für den c-serv ist für unser Thema nicht unbedingt erforderlich; es ist aber nützlich, wenn man beim Import des “Common Server Certificate” gleich den öffentlichen Teil des CA-Zertifikats mit importiert.

Letzteres wird im Falle von self signed Zertifikaten (Die CA liegt ggf. auf dem zentralen LDAP-Server) zwingend für eine erfolgreiche TLS-Verbindung zum LDAP-Server benötigt.

Zur Ausstellung des Serverzertifikats nutzt man die zentrale CA. Unter Opensuse erstellt und verwaltet man die CA am einfachsten mit Hilfe des YaST2 CA-Modul auf dem CA-Server. Wie man damit ein solches Zertifikat ausstellt, habe ich in den LDAP-Artikeln beschrieben. Am Ende der Zertifikatserstellung exportiert man das Zertifikat (inkl. der CA-Hierarchie !) als *.p12-Datei (z.B. als “c-serv.anraconx.p12”) in ein Verzeichnis seiner Wahl auf dem CA-Server. Die Auswahl des richtigen Dateityps erkennt man in einem entsprechenden Dialog von YaST-CA.

Ich nutze als Ablageort für solche Zertifikats-Dateien “/etc/certs”; das Verzeichnis erhält nur Lese- und Schreibrechte für root. Von dort kopiert man die Datei
per “scp” in ein analoges Verzeichnis auf dem Zielserver “c-serv”. Also z.B.:

c-serv:~# mkdir /etc/certs

c-serv:~# chmod 600 /etc/certs

und

ldap-serv:/etc/certs # scp ./c-serv.anraconx.p12 root@c-serv:/etc/certs
Password:
c-serv.anraconx.p12
100% 4237 4.1KB/s 00:00
ldap-serv:/etc/certs #

Danach öffnet man auf “c-serv” das YaST2-Tool “Common Server Certificate”. Mit dessen Hilfe importieren wir das Zertifikat aus der lokalen Datei “/etc/certs/c-serv.anraconx.p12”. Die Zertifikatsinformationen landet dann mit den richtigen Rechten in den richtigen Verzeichnissen – u.a. in “/etc/ssl/servercerts” (u.a. der private Serverkey in der Datei “serverkey.pem” mit Rechten 600) und in “/etc/ssl/certs”. In letzterem Verzeichnis befindet sich dann die öffentliche “YaST-CA.pem” der mit YaST verwalteten CA im Netz. Diese Datei benötigen wir für den korrekten Aufbau der LDAP-Verbindung mittels SSSD.

Natürlich hätte man sich die Datei auch einfach vom CA-Server holen können. Aber so haben wir nun gleichzeitig ein Serverzertifikat, das auf “c-serv” von allen Serverdiensten benutzt werden kann, die mit OpenSSL TLS/SSL-Verschlüsselungen anbieten wollen. Z.B. Apache, Postfix (SMTP), Cyrus Imap, vsftp….

Konfiguration von “c-serv” als “LDAP-Client”

Jeder Host, auf dem eine Authentifizierung über LDAP erfolgen soll, sollte als LDAP-Client eingerichtet werden. Die erforderlichen Konfigurationsschritte habe ich bereits ausführlich in den oben genannten LDAP-Artikeln beschrieben. Siehe im besonderen:
Opensuse 12.1 – LDAP III

Das Yast2-Modul “LDAP-Clint” erzwingt ab Opensuse 12.2 allerdings die Installation erforderlicher SSS-RPMs. In meinem Fall (Opensuse 13.1) sind das folgende Pakete:

libnsssharedhelper0, libsss_idmap0, sssd, sssd-32bit, sssd-tools.

DieYaST2-Einrichtungsroutine nimmt während der Installation Einstellungen in mehreren Dateien vor, u.a. in

• /etc/ldap.conf,
• /etc/openldap/ldap.conf,
• /etc/sssd/sssd.conf,
• /etc/nsswitch.conf,
• diversen Dateien unter /etc/pam.d,
• Konfigurationsvorgaben für den YaST2-eigenen LDAP-Browser,
• Konfigurationsvorgaben für die YaST2-eigene User- und Gruppen-Verwaltung.

Wir betrachten zunächst den Input in die Masken der YaST2-basierten LDAP-Client-Konfiguration auf “c-serv” – hier anhand der späteren Ergebnismasken, aber der notwendige Input in die Dialoge geht auch daraus hervor. Danach zeige ich die korrespondierenden Inhalte einiger lokaler Konfigurationsdateien, damit man deren Inhalte auch unabhängig von YaST prüfen oder manipulieren kann.

Masken zur LDAP-Client-Konfiguration

Zunächst die einleitende Maske der LDAP-Client-Konfiguration:

Das Erzeugen des Home-Directories beim ersten Login-Versuch auf “c-serv” habe ich dabei zugelassen.

Die Maske zu dem Zertifikaten, die man über den Klick des Buttons “SSL/TLS Configuration” erreicht, sieht wie folgt aus:

Nachfolgend der Inhalt spezieller Angaben zum LDAP-Schema, die in die
Konfigurationsdatei “/etc/sssd/sssd.conf” einfließen:

Hier ist die von mir gewählte sssd-offline-Einstellung durchaus diskussionswürdig. Es werden in meinem Fall keine Offline-Credentials vom SSSD-Dämon gespeichert. Das geht für Hosts, die fest in ein Netzwerk eingebunden sind, in dem der LDAP-Server oder ein Backup-System (Slave) immer als erreichbar vorausgesetzt werden können. Für Laptops wäre ein Offline-Caching von Credentials aber durchaus interessant, weil sonst bei Nicht-Erreichbarkeit des LDAP-Servers kein Login in das System möglich wäre. Das Caching von Credentials kann aber auch Nachteile haben. U.a. muss man wie bei Caches üblich Update-Intervalle oder – Bedingungen festlegen. Hierauf kann ich in diesem Artikel nicht eingehen.

Abschließend Festlegungen, die für den LDAP-Browser und die Konfiguration für die User- und Gruppenverwaltung mit Opensuse-spezifischen Baumstrukturen erforderlich sind:

Wie bereits erwähnt, würden wir die Checkbox zu “Create Default Configuration Objects” nur einmal (!) bei der Einrichtung des LDAP-Clients auf dem Server selbst setzen, denn dadurch manipulieren wir den LDAP-Baum auf den Server – und das wollen wir später nicht mehr, wenn wir bereits User angelegt haben. Also: Checkbox nicht (!) markieren.

Die Konfigurationen, die man über den Button “Configure User Management Settings” erreichen würde, betreffen eben die eingerichteten LDAP-Strukturen zur User- und Gruppen-Verwaltung und deren Feintuning. Hierzu verweise ich wieder auf die früheren LDAP-Artikel.

LDAP-Client-Konfigurationsdateien

Nun zum Inhalt der LDAP-Konfigurationsdateien. Hier sind zwei Dateien für verschiedene Klassen von Clients relevant (siehe hierzu Opensuse 12.1 – LDAP III):

/etc/openldap/ldap.conf

#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
uri ldap://ldap-serv.anraconx.de
base dc=anraconx,dc=de
TLS_CACERTDIR /etc/ssl/certs
TLS_CACERT /etc/ssl/certs/YaST-CA.pem

/etc/ldap.conf

uri ldap://ldap-serv.anraconx.de
base dc=anraconx,dc=de
nss_map_attribute uniqueMember member
ssl no
tls_cacertdir /etc/ssl/certs
tls_cacertfile /etc/ssl/certs/YaST-CA.pem
pam_password exop
pam_filter objectClass=posixAccount

Vergleicht man diese letzte Datei mit der entsprechenden Konfigurationsdatei unter Opensuse 12.1, so erkennt man doch deutliche Vereinfachungen, die mit dem Einsatz von SSSD zusammenhängen. Natürlich erwartet man, dass in der Konfigurationsdatei von sssd dann Dinge auftauchen, die früher in “/etc/ldap.conf” zu finden waren.

Die Inhalte weiterer Konfigurationsdateien folgen unter den nächsten Abschnitten.

PAM mit SSSD auf den Hosts lauffähig machen

Zu SSSD habe ich Links mit weiterführenden Informationen in folgendem Blog-Beitrag zusammengestellt:
Opensuse 12.3, LDAP, sssd – II

SSSD erscheint als weiterer Sicherheits-Layer, der z.B. im Rahmen von PAM genutzt werden kann und selbst sog.
Security Domainen verwaltet. PAM soll durch SSSD beim Zugriff auf verschiedene Backend-Authentifizierungsquellen unterstützt werden. Unterschiedliche Konfigurationsdateien und PAM-Plugin-Module sollen so vermieden werden.

Ob die Welt durch diesen Ansatz wirklich einfacher und standardisierter wird, bleibt abzuwarten. Konfigurationsseitig ist der zusätzliche Layer zunächst eine Hürde – vor allem dann, wenn man bereits eine funktionierende Einrichtung von PAM für LDAP hatte. Siehe etwa :
Opensuse 12.1 – LDAP III

SSSD muss auf dem LDAP-Server und auch auf allen anderen Systemen, die über SSSD miteinander oder mit dem LDAP-Server sprechen sollen, installiert und konfiguriert werden. Das meiste wird bei der LDAP-Client-Einstellung per YaST zwar bereits erledigt. Natürlich kann man die Einträge aber auch unabhängig von YaST pflegen oder prüfen.

SSSD-Konfiguration

Schritt 1: “NSS”-Konfiguration anpassen
Hierzu muss man die Datei “/etc/nsswitch.conf editieren und die Einträge für “passwd” und “group” ergänzen:

passwd:    compat sss
group:    files sss

Dies gilt für die Hosts “ldap-serv” und “c-serv” gleichermaßen.

Schritt 2: SSSD auf “ldap-serv” konfigurieren
Zuständig ist hier die Datei “/etc/sssd/sssd.conf”. Die sieht komprimiert bei mir “ldap-serv” wie folgt aus:

[sssd]
config_file_version = 2
services = nss,pam
domains = default
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
 
# Section created by YaST
[domain/default]
ldap_uri = ldap://ldap-serv.anraconx.de
ldap_search_base = dc=anraconx,dc=de
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
;ldap_id_use_start_tls = True
ldap_id_use_start_tls = False
enumerate = True
;cache_credentials = True
chpass_provider = ldap
auth_provider = ldap
;ldap_tls_reqcert = never
ldap_user_search_base = ou=people,dc=anraconx,dc=de
ldap_group_search_base = ou=group,dc=anraconx,dc=de
cache_credentials = False
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/YaST-CA.pem

Zur Bedeutung der für das LDAP-Backend zu treffenden Domain-Einträge muss ich auf die im oben genannten Artikel angegebenen Quellen – insbesondere auf jene von Red Hat – verweisen. U.a.:
https://fedorahosted.org/sssd/

Die LDAP-Konfiguration könnte natürlich etwas anders aussehen, da der LDAP-Host hier ja der lokale Host ist. Man könnte die Verbindung möglicherweise auch über einen Socket aufnehmen; habe ich aber nicht probiert. Die Search Base und das angegebene Schema im LDAP-Baum rühren in meinem Fall natürlich daher, dass die User- und Gruppen-Daten auf dem LDAP-System über eine opensuse-spezifische YaST-LDAP-Konfiguration erzeugt wurde. Auf einem selbst eingerichteten LDAP-Server sind natürlich Anpassungen erforderlich.

Schritt 3: SSSD auf dem Host “c-serv” konfigurieren
Auch hier ist die “/etc/nsswitch.conf” wie oben beschrieben abzuändern. Die Datei “/etc/sssd/sssd.conf” ist mit der des “ldap-serv” praktisch identisch:

[sssd]
config_file_version = 2
services = nss,pam
domains = default
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
&nbsp:
# Section
created by YaST
[domain/default]
ldap_uri = ldap://ldap_serv.anraconx.de
ldap_search_base = dc=anraconx,dc=de
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls = False
enumerate = True
cache_credentials = False
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/YaST-CA.pem
chpass_provider = ldap
auth_provider = ldap

Hier war ich aus bestimmten Gründen nur scheinbar schlampig; es wird offenbar der ganze Baum durchsucht. Dies liegt an für “c-serv” zusätzlich wichtigen Einträgen im LDAP-Baum, die auf dem LDAP-Server selbst keine Rolle spielen sollen. Gibt es User- und Gruppen-Einträge in einer Standard-Installation nur im Ast “ou=people” kann man die user- und group-search-base analog zur Konfiguration auf dem LDAP-Server auch auf “ou=people,dc=anracona,dc=de” eingrenzen.

Anpassen der PAM-Standard-Dateien

Nun muss man natürlich auch PAM für die Nutzung des SSSD-Service konfigurieren und dabei im Gegensatz zu der in
Opensuse 12.1 – LDAP III
beschriebenen PAM-Einrichtung, Moduleinträge wie “pam_ldap.so” eliminieren. Die nachfolgende Konfiguration gilt sowohl für den Server “ldap-serv” als auch den Host “c-serv”.

Wir betrachten hier nur die wichtigsten zentralen PAM-Dateien unter Opensuse, die bei Bedarf in service-spezifische PAM-Konfigurationsdateien per “include”-Anweisung eingebunden werden können. Für die klassischen Auth-Mechanismen “Login”, Session”, “Password” etc. ist das unter Opensuse bereits der Fall. Daher hilft die Modifikation der nachfolgenden Dateien dort auch schon direkt weiter. Bei eigenen, mehr service-spezifische Konfigurationen (z.B. für “cyrus imapd”) bleibt einem zusätzliche Arbeit natürlich nicht erspart.

Die anzupassenden Dateien findet man im Verzeichnis “/etc/pam.d“. Wir gehen sie hier der Reihe nach durch. Man beachte jeweils den Eintrag des Moduls “pam_sss.so“.

Files “common-account” und “common-account-pc”
——————————————————

account requisite pam_unix.so try_first_pass
account sufficient pam_localuser.so
account required pam_sss.so use_first_pass

Files “common-auth” und “common-auth-pc”
———————————————–

auth required pam_env.so
auth optional pam_gnome_keyring.so
auth sufficient pam_unix.so try_first_pass
auth required pam_sss.so use_first_pass

File common-password
———————

password requisite pam_cracklib.so
password optional pam_gnome_keyring.so use_authtok
password sufficient pam_unix.so use_authtok nullok shadow try_first_pass
password required pam_sss.so use_authtok

File common-password-pc
——————————

password requisite pam_cracklib.so
password optional pam_gnome_keyring.so use_authtok
password sufficient pam_unix.so use_authtok nullok shadow try_first_pass
password required pam_sss.so use_authtok

File common-session
————————-

session optional pam_mkhomedir.so
session required
pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_sss.so
session optional pam_umask.so
session optional pam_systemd.so
session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
session optional pam_env.so

File common-session-pc
————————-

session optional pam_mkhomedir.so
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_sss.so
session optional pam_umask.so
session optional pam_systemd.so
session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
session optional pam_env.so

Im Vergleich zu Opensuse 12.1 – LDAP III erkennt man, dass das Modul “pam_ldap.so” eigentlich nur gegen “pam_sssd.so” ausgetauscht wurde. Die wirklichen Vorteile von SSSD kommen in den hier besprochenen einfachen Beispielen also noch nicht zum Tragen.

Test, ob LDAP als Auth-Backend eingestellt ist und genutzt wird

Das Gröbste an der Konfiguration ist bereits geschafft. Wir checken nun auf “c-serv”, dass uns die User- und Gruppen-Verwaltung unter YaST2 dort Zugang zu dem LDAP-Server ermöglicht und dass LDAP als Backend aktiviert ist. Dazu öffnen wir “YaST2 >> User and Group Management” und gehen auf den Reiter “Authentication Settings”. Dort sollten alle erforderlichen LDAP-Einstellungen bereits vorgenommen sein. Also etwa:

LDAP
Servers:ldap-serv.anraconx.de
Base DN:dc=anraconx,dc=de
Client Enabled:Yes
System Security Services Daemon (SSSD) Set

Danach kann man an einem Terminal einen ersten Login-Versuch des Users “tarja” auf “c-serv” testen. (“tarja” darf auf c-serv bislang natürlich nicht als User angelegt sein.) Ist alles OK, so erfolgt die Authentifizierung über “ldap-serv” und es wird auf “c-serv” das Home-Verzeichnis für “tarja” auf c-serv angelegt und man kann arbeiten. Siehe hierzu die genannten LDAP-Artikel. Über ssh von einem System “mylinux” aus, sieht das wie folgt aus:

mylinux:~ # ssh -X tarja@c-serv
Password:
Creating directory ‘/home/tarja’.
Have a lot of fun…
/usr/bin/xauth: file /home/tarja/.Xauthority does not exist
tarja@c-serv:~>

Damit haben wir das Zusammenspiel von sssd und LDAP verifiziert.

SASL – genauer saslauthd – und PAM

Voraussetzung der Verwendung von “sasl” als Authentication Layer für bestimmte Services ist die Installation von SASL-RPM-Paketen (hier auf c-serv). SASL bietet mehrere maßgeschneiderte Module/Dienste für die Nutzung von anderen Authentication-Layern oder den direkten Zugriff auf bestimmte Backends an. Wichtig für die Nutzung von PAM ist der SASL-Dienst “saslauthd“. Ich installiere mir aber gleich auch die Pakete für weitere Dienste dazu, um bei Bedarf darauf zugreifen zu können. Die wichtigsten SASL-RPMs sind:

cyrus-sasl, cyrus-sasl-32bit, cyrus-sasl-devel,
cyrus-sasl-crammd5, cyrus-sasl-digestmd5, cyrus-sasl-plain,
cyrus-sasl-gssapi, cyrus-sasl-ldap-auxprop, cyrus-sasl-saslauthd

Die 2-te Zeile enthält Verfahren zur Passwort-Verschlüsselung. Da wir die Verbindung zum LDAP-Server über TLS aufbauen, interessieren uns hier starke Verfahren wie crammd5 oder digestmd5 im Moment nicht. Die 3-te Zeile zeigt verschiedene Bibliotheken, die für verschiedene Backends benutzt werden können. Wir benutzen davon im Moment aber nur “saslauthd“;
dieses Module erlaubt die Nutzung von PAM als nächstem Authentifizierungslayer. Dies kann man auf einem Host z.B. dadurch erreichen, in dem man den “saslauthd”-Daemon explizit wie folgt startet:

c-serv:/etc/sasl2 # cd /etc/init.d

c-serv:/etc/init.d # ./saslauthd start -a pam

Wie bei Opensuse üblich, kann der Startup von “saslauthd” aber auch über eine Datei unter /etc/sysconfig – nämlich /etc/sysconfig/saslauthd – konfiguriert werden. Die sieht bei mir wie folgt aus:

## Path: System/Security/SASL
## Type: list(getpwent,kerberos5,pam,rimap,shadow,ldap)
## Default: pam
## ServiceRestart: saslauthd
#
# Authentication mechanism to use by saslauthd.
# See man 8 saslauthd for available mechanisms.
#
SASLAUTHD_AUTHMECH=pam
#
## Path: System/Security/SASL
## Type: integer(0:)
## Default: 5
## ServiceRestart: saslauthd
#
# Number of processes that saslauthd should fork to responding to
# authentication queries. A value of zero will indicate that saslauthd
# should fork an individual process for each connection.
#
SASLAUTHD_THREADS=5
#
## Path: System/Security/SASL
## Type: string
## Default: “”
## ServiceRestart: saslauthd
#
# Additional parameters to use by saslauthd.
# See the saslauthd(8) manpage for available parameters.
#
SASLAUTHD_PARAMS=””

Diese Parameter werden in das Startup-Skript für saslauthd unter /etc/init.d – nämlich /etc/init.d/sasauthd – eingebunden. Nach einem

c-serv:/etc/init.d #systemctl enable saslauthd.service

wird der saslauthd-Dämon dann regelmäßig beim Systemstart von “systemd” gestartet.

Test der Funktionstüchtigkeit von saslauthd mit PAM

Jetzt wird es Zeit für einen Test, ob “saslauthd” auch seinen Dienst tut und PAM nutzt. Hierfür gibt es das CLI-Testtool “testsaslauthd“. Für unsere auf dem LDAP-Server eingetragene Testuserin “tarja” verwenden wir es wie folgt; die Option “-p” erfordert dabei die Angabe des Passwords für “tarja”.

c-serv:/etc/init.d # testsaslauthd -u tarja -p TARJAPWD
0: OK “Success.”
c-serv::/etc/init.d #

Damit haben wir im Prinzip die gewünschte Kette geschlossen:

Man kann den “saslauthd”-Dienst als Brückenglied zu PAM benutzen. PAM greift dann – wie gewünscht über SSSD TLS-gesichert auf den LDAP-Server zu.

Konfiguration von Services zur Nutzung von SASL und “saslauthd” – Beispiel Postfix

Natürlich muss jeder Services auf die Nutzung von SASL und im besonderen auf die Nutzung des Subservices “saslauthd” ausgerichtet werden. Was man dafür zu tun hat, ist natürlich dienste-abhängig. Ich gehe hier beispielhaft, kurz und oberflächlich auf den Dienst Postfix ein.

Postfix und der zugehörige SMTP-Dienst erfordern auf einem aktuellen Opensuse-System u.a. eine Konfigurationsdatei “/etc/sasl2/smtp.conf“.

c-serv:/etc/sasl2 # cat smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login
c-serv:/etc/sasl2 #

Die obigen Zeilen sagen nur, wie sasl benutzt wird – nämlich über saslauthd .

Im Fall des Postfix-Service sind auch SASL-bezogene Zeilen in der “/etc/main.cf”
erforderlich. Z.B. (neben vielen anderen Optionen) :

Ausschnitt aus der /etc/main.cf:

# Auth-Mechanism for clients of the local SMTP-Server
# ———————–
——————————-
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
# Postfix > 2.3
smtpd_sasl_path = smtpd
broken_sasl_auth_clients = yes
#
# Local SMTP server as a client for Relay servers
# ————————————————
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps =
smtp_sasl_security_options = noanonymous

Postfix sucht unter neueren Opensuse-Systemen die SASL-Konfiguration für SMTP-Authentifizierung automatisch unter “/etc/sasl2/smtp.conf“. Wie man das explizit beeinflussen kann, erläutert für verschiedene Postfix-Versionen u.a. der folgende Artikel:
http://www.postfix.org/SASL_README.html

Dass “saslauthd” wiederum PAM als Backend auch für Postfix benutzt, wird – wie bereits gesagt – über die Startoptionen von “saslauthd” geregelt.

Ausblick

Host-spezifische Beschränkungen
Die oben beschriebene Konfiguration resultiert darin, dass sich jeder User, für den es einen LDAP-Eintrag gibt, auf dem Host, auf dem die obige SSSD-Konfiguration vorgenommen wurde, einloggen darf. In einer ausgefeilteren Netzwerk-Umgebung soll sich aber natürlich nicht jeder User, der auf dem LDAP-System registriert ist, auch auf jedem Host des Netzes einloggen oder dessen Dienste nutzen dürfen. Dann muss man mehr Aufwand in die Konfiguration sowohl des LDAP-Server-Baums als auch in die Konfiguration der Hosts und ihrer Services investieren.

Wie man einen normalen Login-Prozess auf einem Host unterbindet, aber dennoch SASL, PAM, SSSD und LDAP für eine Authentifizierung zur Benutzung eines Services nutzen kann, stelle ich beispielhaft in einem kommenden Artikel dar. Siehe:
SASL mit PAM, SSSD, LDAP unter Opensuse – II

Wie man zusätzlich user- und server-bezogene Zugangsberechtigungen auf einfache Weise im LDAP-System hinterlegen kann, habe ich ursprünglich mal unter
Opensuse 12.1 – LDAP V
besprochen. Beide dort besprochenen Verfahren eignen sich im Prinzip auch für eine Kombination mit SSSD. Stichworte sind Filter bzw. Attribut-Untersuchungen, die sich über Einträge “ldap_access_filter“, “ldap_access_provider” und “ldap_access_order” in der “sssd.conf” einstellen lassen. Auch hierauf gehe ich kurz im Beitrag “SASL mit PAM, SSSD, LDAP unter Opensuse – II” ein.

Neugierigen sei ferner folgender Link empfohlen; der zugehörige Artikel gibt schon die wichtigsten Hinweise:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/config-sssd-domain-access.html

Viel Spaß nun beim Einsatz von PAM, SSSD und LDAP im eigenen Netz!