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!