SUSE LINUX 9.3

Teil II. System / Kapitel 21. Authentifizierung mit PAM
	20.5. Weitere Informationen		21.2. Die PAM-Konfiguration für sshd

Kapitel 21. Authentifizierung mit PAM

Inhaltsverzeichnis

21.1. Aufbau einer PAM-Konfigurationsdatei
21.2. Die PAM-Konfiguration für sshd
21.3. Konfiguration der PAM-Module
21.4. Weitere Informationen

Zusammenfassung

PAM (engl. Pluggable Authentication Modules) wird unter Linux verwendet, um bei der Authentifizierung zwischen Benutzer und Anwendung zu vermitteln. PAM-Module stehen zentral zur Verfügung und können von jeder Applikation aufgerufen werden. Wie diese modulare Authentifizierung konfiguriert wird und wie sie arbeitet, ist Inhalt dieses Kapitels.

Systemadministratoren und Entwickler möchten den Zugriff auf bestimmte Systembereiche oder die Nutzung bestimmter Funktionalitäten einer Anwendung beschränken. Ohne PAM würde dies bedeuten, dass alle Anwendungen immer wieder an neue Authentifizierungsschemen wie LDAP oder Samba angepasst werden müssten. Dieses Vorgehen ist zeitraubend und fehleranfällig. Löst man hingegen die Authentifizierung von der Anwendung und delegiert sie an zentrale Module, entfallen diese Nachteile. Soll ein neues Authentifizierungsschema angewandt werden, muss lediglich ein PAM-Modul angepasst/entwickelt werden, auf das die Anwendung zurückgreifen kann.

Für jedes Programm, das PAM nutzt, liegt eine eigene Konfigurationsdatei unter /etc/pam.d/<Programmname>. In diesen Dateien ist festgelegt, welche PAM-Module zur Benutzerauthentifizierung verwendet werden sollen. Globale Konfigurationsdateien der meisten PAM-Module unter /etc/security legen das genaue Verhalten dieser Module fest (Beispiele: pam_env.conf, pam_pwcheck.conf, pam_unix2.conf, time.conf). Eine Anwendung, die ein PAM-Modul nutzt, ruft einen bestimmten Satz an PAM-Funktionen auf, die die Informationen aus den verschiedenen Konfigurationsdateien verarbeiten und das Ergebnis an die aufrufende Anwendung weiterleiten.

21.1. Aufbau einer PAM-Konfigurationsdatei

Eine Zeile einer PAM-Konfigurationsdatei baut sich aus maximal vier Spalten auf:

<Modultyp> <Kontroll-Flag> <Modulpfad> <Optionen>

PAM-Module werden stapelweise abgearbeitet. Die verschiedenen Module haben unterschiedliche Aufgaben. Ein Modul übernimmt die Passwortprüfung, ein anderes prüft, von woher der Zugriff erfolgt und ein weiteres fragt benutzerspezifische Systemeinstellungen ab.

PAM kennt vier verschiedene Typen von Modulen:

auth: Module dieses Typs dienen der Überprüfung, ob der Benutzer authentisch ist. Diese Überprüfung geschieht traditionell durch Passwortabfrage, kann aber auch per Chipkarte oder über Prüfung eines biometrischen Merkmals (Fingerabdruck, Irisscan) erfolgen.
account: Module dieses Typs überprüfen, ob der Benutzer berechtigt ist, den angefragten Dienst überhaupt zu benutzen. So sollte sich zum Beispiel niemand mit abgelaufenem Account auf einem System einloggen können.
password: Module dieses Typs dienen der Änderung des Authentifizierungsmerkmals. Dies ist in den meisten Fällen ein Passwort.
session: Module dieses Typs sind zur Verwaltung und Konfiguration von Benutzer-Sessions gedacht. Diese Module werden vor und nach der Authentifizierung gestartet, um Loginversuche zu protokollieren und dem Benutzer seine eigene Umgebung zuzuweisen (Mailzugang, Home-Verzeichnis, Systemlimits usw.)

Die zweite Spalte enthält die Kontroll-Flags, mit denen die gewünschten Module aufgerufen werden:

required: Das Modul muss erfolgreich abgearbeitet werden, damit die Authentifizierung fortschreiten kann. Bei Fehlschlagen eines required Moduls werden noch alle anderen Module dieses Typs abgearbeitet, bevor der Benutzer eine Meldung über das Fehlschlagen seines Authentifizierungsversuchs erhält.
requisite: Diese Module müssen ebenso wie die required Module erfolgreich abgearbeitet werden. Bei einem Fehlschlag erhält der Benutzer unmittelbares Feedback und es werden keine weiteren Module mehr abgearbeitet. Im Erfolgsfall werden weitere Module genau wie bei required abgearbeitet. Dieses Flag kann als ein einfacher Filter eingesetzt werden, um bestimmte Bedingungen abzufragen, die für eine korrekte Authentifizierung notwendig sind.
sufficient: Wird ein Modul dieses Typs erfolgreich abgearbeitet, erhält das aufrufende Programm sofort eine Erfolgsmeldung und es werden keine weiteren Module mehr abgearbeitet, wenn kein voranstehendes required-Modul fehlgeschlagen ist. Schlägt ein sufficient-Modul fehl, hat dies keine Folgen und die folgenden Module werden der Reihe nach weiter abgearbeitet.
optional: Erfolg oder Fehlschlag hat keinerlei Auswirkung. Diese Eigenschaft wird zum Beispiel bei Modulen verwendet, die anzeigen sollen, ob ein Benutzer E-Mail erhalten hat, aber keine weiteren Auswirkungen haben.
include: Wenn diese Flag benutzt wird, wird die als Argument angegebene Datei hier eingefügt.

Der Modulpfad wird nicht explizit angegeben, wenn die Module im Standardverzeichnis /lib/security (bzw. unter /lib64/security bei allen von SUSE LINUX unterstützten 64-bit Plattformen) zu finden sind. Als vierter Eintrag kann einem Modul noch eine Option wie zum Beispiel debug (Debugmodus) oder nullok (leere Passwörter sind erlaubt) übergeben werden.