View previous topic :: View next topic |
Author |
Message |
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz
|
Posted: Mon Oct 23, 2017 2:23 pm Post subject: Fun with PAM-Substack |
|
|
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":
sys-auth/pambase-20150213 (cracklib nullok sha512 systemd): | 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:
/etc/pam.d/system-auth: | 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 |
/etc/pam.d/system-auth-sources: | 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? _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Tue Oct 24, 2017 8:57 am Post subject: Re: Fun with PAM-Substack |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz
|
Posted: Tue Oct 24, 2017 5:21 pm Post subject: Re: Fun with PAM-Substack |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Tue Oct 24, 2017 7:00 pm Post subject: Re: Fun with PAM-Substack |
|
|
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:
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz
|
Posted: Wed Oct 25, 2017 9:56 am Post subject: Re: Fun with PAM-Substack |
|
|
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). _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Wed Oct 25, 2017 5:44 pm Post subject: Re: Fun with PAM-Substack |
|
|
schmidicom wrote: | Wenn es möglich sein soll lokale Verzeichnisse über SMB freizugeben |
Ok, wir haben die Homeverzeichnisse auf NFS liegen. |
|
Back to top |
|
|
|