Kapitel 36. Authentifizierung mit PAM

SUSE Linux-Dokumentation Teil VIII. System / Kapitel 36. Authentifizierung mit PAM
	35.4. Konfiguration von OpenGL/3D		36.2. PAM-Konfiguration von sshd

Inhaltsverzeichnis

36.1. Struktur einer PAM-Konfigurationsdatei
36.2. PAM-Konfiguration von sshd
36.3. Konfiguration von PAM-Modulen
36.4. Weitere Informationen

Zusammenfassung

Während des Authentifizierungsprozesses verwendet Linux PAM (Pluggable Authentication Modules) als Vermittlungsschicht zwischen Benutzer und Anwendung. PAM-Module sind systemweit verfügbar, sodass sie von jeder beliebigen Anwendung angefordert werden können. In diesem Kapitel wird beschrieben, wie der modulare Authentifizierungsmechanismus funktioniert und wie er konfiguriert wird.

Häufig möchten Systemadministratoren und Programmierer den Zugriff auf bestimmte Teile des Systems einschränken oder die Nutzung bestimmter Funktionen einer Anwendung begrenzen. Ohne PAM müssen die Anwendungen bei jedem neu eingeführten Authentifizierungsmechanismus, wie LDAP oder SAMBA, angepasst werden. Dieser Prozess ist jedoch sehr zeitaufwändig und fehleranfällig. Eine Möglichkeit, diese Nachteile zu vermeiden, ist eine Trennung zwischen den Anwendungen und dem Authentifizierungsmechanismus und das Delegieren des Letzteren an zentral verwaltete Module. Wenn ein neues Authentifizierungsschema erforderlich ist, genügt es, ein geeignetes PAM-Modus für die Verwendung durch das betreffende Programm anzupassen oder zu schreiben.

Jedes Programm, das mit dem PAM-Mechanismus arbeitet, verfügt über eine eigene Konfigurationsdatei im Verzeichnis /etc/pam.d/programmname. Mit diesen Dateien werden die für die Authentifizierung verwendeten PAM-Module definiert. Darüber hinaus sind im Verzeichnis /etc/security globale Konfigurationsdateien für die meisten PAM-Module gespeichert, in denen die genaue Verhaltensweise der Module definiert ist (Beispiele: pam_env.conf, pam_pwcheck.conf, pam_unix2.conf und time.conf). Jede Anwendung, die ein PAM-Modul verwendet, ruft eine Reihe von PAM-Funktionen auf, mit denen dann die Informationen in den verschiedenen Konfigurationsdateien verarbeitet und das Ergebnis an die anfordernde Anwendung zurückgegeben wird.

36.1. Struktur einer PAM-Konfigurationsdatei

Jede Zeile in einer PAM-Konfigurationsdatei enthält maximal vier Spalten:

<Modultyp> <Kontrollflag> <Modulpfad> <Optionen>

PAM-Module werden als Stapel verarbeitet. Die unterschiedlichen Modultypen dienen verschiedenen Zwecken. So wird beispielsweise mit einem Modul das Passwort und mit einem anderen Modul der Standort überprüft, von dem aus auf das System zugegriffen wird. Mit einem dritten Modul können beispielsweise benutzerspezifische Einstellungen abgelesen werden. PAM sind vier verschiedene Modultypen bekannt:

auth: Dieser Modultyp dient der Überprüfung der Authentizität des Benutzers. Dies erfolgt in der Regel über die Abfrage des Passworts, es kann jedoch auch mithilfe einer Chipkarte oder biometrischer Daten (Fingerabdruck oder Irisscan) erreicht werden.
account: Mit Modulen dieses Typs wird überprüft, ob der Benutzer allgemein zur Verwendung des angeforderten Diensts berechtigt ist. Solch eine Prüfung sollte beispielsweise durchgeführt werden, um sicherzustellen, dass keine Anmeldung mit einem Benutzernamen eines nicht mehr gültigen Accounts erfolgen kann.
password: Mit diesem Modultyp kann die Änderung eines Authentifizierungstokens aktiviert werden. In den meisten Fällen handelt es sich hierbei um ein Passwort.
session: Mit diesem Modultyp werden Benutzersitzungen verwaltet und konfiguriert. Sie werden vor und nach der Authentifizierung gestartet, um Anmeldeversuche in Systemprotokollen aufzuzeichnen und die spezielle Umgebung des Benutzers (wie Mailkonten, Home-Verzeichnis, Systemlimits usw.) zu konfigurieren.

Die zweite Spalte enthält Kontrollflags, mit denen das Verhalten der gestarteten Module beeinflusst wird:

required: Ein Modul mit diese Flag muss erfolgreich abgearbeitet werden, damit die Authentifizierung fortgesetzt werden kann. Wenn ein Modul mit dem Flag required fehlschlägt, werden alle anderen Module mit demselben Flag verarbeitet, bevor der Benutzer eine Meldung bezüglich des Fehlers beim Authentifizierungsversuch erhält.
requisite: Module mit diesem Flag müssen ebenfalls erfolgreich abgearbeitet werden, ähnlich wie Module mit dem Flag required. Falls jedoch ein Modul mit diesem Flag fehlschlägt, erhält der Benutzer sofort eine entsprechende Rückmeldung und es werden keine weiteren Module abgearbeitet. Bei einem erfolgreichen Vorgang werden die anderen Module nachfolgend verarbeitet, genau wie alle Module mit dem Flag required. Das Flag requisite kann als Basisfilter verwendet werden, um zu überprüfen, ob bestimmte Bedingungen erfüllt sind, die für die erfolgreiche Authentifizierung erforderlich sind.
sufficient: Wenn ein Modul mit diesem Flag erfolgreich abgearbeitet wurde, erhält die anfordernde Anwendung sofort eine Nachricht bezüglich des erfolgreichen Vorgangs und es werden keine weiteren Module abgearbeitet, vorausgesetzt, es ist zuvor kein Fehler bei einem Modul mit dem Flag required aufgetreten. Fehlschlagen eines Moduls mit dem Flag sufficient hat keine direkten Auswirkungen auf die Verarbeitung oder die Verarbeitungsreihenfolge nachfolgender Module.
optional: Ein Fehler oder die erfolgreiche Verarbeitung hat bei diesem Modul keine direkten Folgen. Dies kann für Module sinnvoll sein, die nur der Anzeige einer Meldung (beispielsweise um dem Benutzer mitzuteilen, dass er eine Email erhalten hat) dienen, ohne weitere Aktionen auszuführen.
include: Wenn dieses Flag gesetzt ist, wird die als Argument angegebene Datei an dieser Stelle eingefügt.

Der Modulpfad muss nicht explizit angegeben werden, solange das Modul sich im Standardverzeichnis /lib/security befindet (für alle von SUSE Linux unterstützten 64-Bit-Plattformen lautet das Verzeichnis /lib64/security). Die vierte Spalte kann eine Option für das angegebene Modul enthalten, wie beispielsweise debug (zum Aktivieren der Fehlersuche) oder nullok (um die Verwendung leerer Passwörter zu ermöglichen).