# Fun with PAM-Substack

## schmidicom

Wegen der wiederholten Anbindung von Gentoo an eine AD-Domäne und einigen Experimenten mit LDAP, SSSD oder auch "Google Authenticator" habe ich mich notwendiger Weise immer mal wieder ziemlich intensiv mit der Konfiguration von PAM auseinander gesetzt. Daraus ist inzwischen eine "/etc/pam.d/system-auth" hervor gegangen welche es meiner Meinung nach wert ist geteilt und ggf. diskutiert zu werden.

Zuerst mal das Original von meinem "sys-auth/pambase":

```
auth       required   pam_env.so 

auth       required   pam_unix.so try_first_pass likeauth nullok 

auth       optional   pam_permit.so

account    required   pam_unix.so 

account    optional   pam_permit.so

password   required   pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 

password   required   pam_unix.so try_first_pass use_authtok nullok sha512 shadow 

password   optional   pam_permit.so

session    required   pam_limits.so 

session    required   pam_env.so 

session    required   pam_unix.so 

session    optional   pam_permit.so

-session   optional   pam_systemd.so
```

Hier nun eine weitere Authentifizierungsquelle hinzuzufügen scheint auf den ersten Blick trivial zu sein, ist es aber nicht. In vielen Anleitungen wird geschrieben man könnte Beispielweise einfach ein "auth   required   pam_winbind.so use_first_pass" direkt nach pam_unix.so rein setzen um Domänenanmeldungen zu ermöglichen, doch da meistens nur eine Authentifizierungsquelle (in diesem Fall pam_unix.so oder pam_winbind.so) ein erfolgreiches Ergebnis zurück liefert gilt somit eigentlich immer die ganze PAM-Kette als Fehlgeschlagen. Und ein "auth   sufficient   pam_winbind.so use_first_pass" nach oder vor pam_unix.so führt unter Umständen dazu das die PAM-Kette an einer Stelle abgebrochen wird wo so etwas besser nicht passieren sollte. Man könnte natürlich auch versuchen die Modulsteuerung wie "required" oder "sufficient" durch ein eigenes Regelwerk zu ersetzen (RedHat macht/empfiehlt das stellenweise so) aber das verkompliziert im Endeffekt alles nur noch mehr und macht spätere Anpassungen auch nicht gerade einfacher. Bei einer solchen Lösung läuft es dann recht schnell auf "einmal schreiben und nie wieder verstehen" hinaus.

Also eine ziemlich knifflige Angelegenheit.

Meine bis jetzt beste Lösung dafür: Ein PAM-Substack.

 *"man pam.conf" wrote:*   

> substack 
> 
>  include all lines of given type from the configuration file specified as an argument to this control. This differs from include in that evaluation of the done and die actions in a substack does not cause skipping the rest of the complete module stack, but only of the substack. Jumps in a substack also can not make evaluation jump out of it, and the whole substack is counted as one module when the jump is done in a parent stack. The reset action will reset the state of a module stack to the state it was in as of beginning of the substack evaluation.

 

So ist es mir Beispielweise gelungen mehrere Authentifizierungsquellen wie ein einziges Modul in den Ablauf von "/etc/pam.d/system-auth" einzubinden. Dafür musste ich die "/etc/pam.d/system-auth" in zwei Dateien aufteilen und das sieht bei mir aktuell folgendermaßen aus:

```
auth       required     pam_env.so

auth       required     pam_group.so

auth       substack     system-auth-sources

account    substack     system-auth-sources

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3

password   substack     system-auth-sources

session    required     pam_limits.so

session    required     pam_env.so

session    required     pam_mkhomedir.so umask=0027

session    required     pam_unix.so

-session   optional     pam_systemd.so

-session   optional     pam_winbind.so
```

```
auth       sufficient   pam_unix.so try_first_pass likeauth nullok

-auth      sufficient   pam_winbind.so use_first_pass

auth       required     pam_deny.so

account    sufficient   pam_unix.so

-account   sufficient   pam_winbind.so

account    required     pam_deny.so

password   sufficient   pam_unix.so use_authtok nullok sha512 shadow

-password  sufficient   pam_winbind.so use_authtok

password   required     pam_deny.so
```

Diese Konfiguration habe ich inzwischen sehr intensiv durchgetestet und bis jetzt ist mir nicht der geringste Fehler aufgefallen, auch ist eine spätere Anpassung (zum Beispiel das hinzufügen einer dritten Authentifizierungsquelle) einfacher als bei anderen Lösungen. Mich persönlich wundert es inzwischen sogar warum solche Substack's nicht viel häufiger genutzt werden, immerhin steht diese Möglichkeit nicht erst seit gestern zur Verfügung.

Was habt ihr für eine Meinung dazu?

----------

## musv

 *schmidicom wrote:*   

> Wegen der wiederholten Anbindung von Gentoo an eine AD-Domäne und einigen Experimenten mit LDAP, SSSD oder auch "Google Authenticator" habe ich mich notwendiger Weise immer mal wieder ziemlich intensiv mit der Konfiguration von PAM auseinander gesetzt. Daraus ist inzwischen eine "/etc/pam.d/system-auth" hervor gegangen welche es meiner Meinung nach wert ist geteilt und ggf. diskutiert zu werden.

 

Gentoo hab ich nicht im Einsatz mit der AD getestet. Fedora und RHEL nutzen für die AD-Authentifizierung ausschließlich den SSSD. Bei SLES12 hab ich's jetzt auch zum Laufen bekommen. Klappt soweit eigentlich auch ganz gut. Und da fehlen mir eigentlich in Deiner Config die pam_sss.so-Module. 

Allerdings muss ich sagen, dass ich bei Pam bisher noch nicht wirklich durchgeblickt hab.

----------

## schmidicom

 *musv wrote:*   

> Gentoo hab ich nicht im Einsatz mit der AD getestet. Fedora und RHEL nutzen für die AD-Authentifizierung ausschließlich den SSSD. Bei SLES12 hab ich's jetzt auch zum Laufen bekommen. Klappt soweit eigentlich auch ganz gut. Und da fehlen mir eigentlich in Deiner Config die pam_sss.so-Module.

 

SSSD hab ich auch schon von RedHat, oder seinen Ablegern, kennengelernt und es hat durchaus so seine Vorteile. Zum einen kann SSSD im Gegensatz zu Winbind mit UPN's umgehen und auch der Cache soll wohl besser sein. Aber es erhöht dadurch auch massiv den Konfigurationsaufwand weil es dann eben nicht nur Samba ist, trotzdem überlege ich hin und wieder auch unter Gentoo darauf zu wechseln.

 *musv wrote:*   

> Allerdings muss ich sagen, dass ich bei Pam bisher noch nicht wirklich durchgeblickt hab.

 

PAM ist meiner Meinung nach auch nicht einfach zu verstehen und die kaum vorhandene Dokumentation (außer einer englischsprachigen Manpage) macht es nicht wirklich besser. Vielleicht wird "sys-auth/pambase" deshalb seit mehreren Jahren nicht mehr allzu aktiv weiterentwickelt.

----------

## musv

 *schmidicom wrote:*   

> SSSD […] erhöht dadurch auch massiv den Konfigurationsaufwand weil es dann eben nicht nur Samba ist…

 

Nicht ganz korrekt. Bei CentOS7 benötigst du aus irgendeinem Grund die samba-common-tools (net ads), bei RHEL7 nicht. Ansonsten brauchst du keinerlei Komponenten von Samba. SSSD hat auch noch den weiteren Vorteil, dass das Maschinenpasswort des Rechners automatisch in bestimmten Zeiträumen gewechselt wird. 

Auf redhatbasierten Systemen hast du dann 2 Möglichkeiten zur AD-Integration:

addcli join

realm join

Letzteres überschreibt aber die sssd.conf. Danach ist dann der Login mit AD-Authetifizierung nicht mehr möglich. 

Übrigens, zumindest unter redhatbasierten Systemen kann man eine Default-Pam-Config relativ schön mit authconfig (authconfig-gtk) generieren lassen. Bei SLES funktionierte dieselbe Config nicht. Da werden die Dateien im PAM-Verzeichnis teilweise anders benamt.

----------

## schmidicom

 *musv wrote:*   

>  *schmidicom wrote:*   SSSD […] erhöht dadurch auch massiv den Konfigurationsaufwand weil es dann eben nicht nur Samba ist… 
> 
> Nicht ganz korrekt. Bei CentOS7 benötigst du aus irgendeinem Grund die samba-common-tools (net ads), bei RHEL7 nicht. Ansonsten brauchst du keinerlei Komponenten von Samba. SSSD hat auch noch den weiteren Vorteil, dass das Maschinenpasswort des Rechners automatisch in bestimmten Zeiträumen gewechselt wird.

 

Wenn es möglich sein soll lokale Verzeichnisse über SMB freizugeben (siehe zum Beispiel "net usershare") dann braucht es mindestens noch den smbd und schon ist es nötig zwei Dinge zu konfigurieren, Samba und SSSD. Ich hoffe sehr das die Samba-Devs irgendwann mal den winbind funktionell auf Augenhöhe mit dem SSSD bringen und sei es auch nur im Umgang mit einer AD.

 *musv wrote:*   

> Übrigens, zumindest unter redhatbasierten Systemen kann man eine Default-Pam-Config relativ schön mit authconfig (authconfig-gtk) generieren lassen. Bei SLES funktionierte dieselbe Config nicht. Da werden die Dateien im PAM-Verzeichnis teilweise anders benamt.

 

Ja Redhat macht es den Admins da einfacher und auch Debian müsste so etwas haben (wenn ich nicht komplett daneben liege mit "dpkg --configure" und dem entsprechenden Paket).

----------

## musv

 *schmidicom wrote:*   

> Wenn es möglich sein soll lokale Verzeichnisse über SMB freizugeben 

 

Ok, wir haben die Homeverzeichnisse auf NFS liegen.

----------

