Red Hat Enterprise Linux 3: Referenzhandbuch | ||
---|---|---|
Zurück | Kapitel 15. Pluggable Authentication Modules (PAM) | Nach vorne |
Jede PAM Konfigurationsdatei enthält eine Gruppe von Anweisungen, welche wie folgt formattiert sind:
<module interface> <control flag> <module name> <module arguments> |
Jedes dieser Elemente ist in den folgenden Abschnitten erklärt.
Es gibt vier Typen von Modul-Schnittstellen, welche den unterschiedlichen Aspekten des Authentifizierungsprozesses entsprechen:
auth — Diese Modulschnittstelle authentifiziertdie Verwendung. Sie, zum Beispiel, erfragt und überprüft das Passwort und stellt Berechtigungsmerkmale, wie z.B. Mitgliedschaft in einer Gruppe oder Kerberos-Tickets, ein.
account — Diese Modulschnittstelle stellt sicher, dass der Zugriff erlaubt ist. Zum Beispiel können sie prüfen, ob der Account abgelaufen ist, oder ob der Benutzer zur Anmeldung um diese Uhrzeit zugelassen ist.
password — Diese Modulschnittstelle wird zur Einstellung des Passworts verwendet.
session — Diese Modulschnittstelle wird, nachdem der Benutzer authentifiziert wurde, dazu verwendet, dessen Session zu verwalten. Das Modul kann auch zusätzliche, für den Zugriff benötigte Tasks durchführen, wie beispielsweise das Mounten des Home-Verzeichnisses des Benutzers oder die Aktivierung seiner Mailbox.
![]() | Anmerkung |
---|---|
Ein einzelnes Modul kann jeglichen, oder alle der o.g. Modul-Schnittstellen ansprechen. Zum Beispiel pam_unix.so besitzt Komponenten, die alle vier Modularten ansprechen. |
In einer PAM Konfigurationsdatei wird als Erstes die Modul-Schnittstelle bestimmt. Eine solche typische Zeile in einer Konfiguration könnte wie folgt aussehen:
auth required pam_unix.so |
Dies weist PAM an, die auth-Schnittstelle des pam_unix.so Moduls zu verwenden.
Anweisungen der Modul-Schnittstellen können gestapelt werden, so dass mehrere Module zu einem Zweck verwendet werden können. Deshalb ist die Reihenfolge in der die Module aufgelistet werden für den Authentifikationsprozess sehr wichtig.
Das Stapeln macht es dem Administrator einfacher, zu erkennen, dass bereits einige Voraussetzungen erfüllt sind, bevor die Benutzerauthentifizierung stattgefunden hat. Zum Beispiel verwendet rlogin in der Regel fünf gestapelte auth Module, wie in der PAM-Konfigurations- datei zu sehen:
auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth |
Bevor rlogin ausgeführt werden kann, stellt PAM fest, dass die Datei /etc/nologin nicht existiert, dass niemandversucht, sich von einem Remote-Rechner über eine unverschlüsselte Netzwerkverbindung als Root anzumelden und dass alle Umgebungsvariablen geladen werden können. Wenn die rhosts -Authentifizierung erfolgreich ist, kann die Verbindung zugelassen werden. Ist die Authentifizierung nicht erfolgreich, wird zur Standardauthentifizierung mit Passwort übergegangen.
Alle PAM-Module erstellen bei einer Überprüfung Fehler- oder Erfolgsmeldungen. Die Steuer-Flags geben PAM an, was mit diesen Ergebnissen geschehen soll. Während Module in einer bestimmten Reihenfolge gestapelt werden können, können Sie mit den Steuer-Flags einstellen, wie wichtig der Erfolg oder das Fehlschlagen des entsprechenden Moduls für die Authentifizierung des gesamten Service ist.
Es gibt vier vordefinierte Steuer-Flags:
required — Solche Module müssen erfolgreich überprüft werden, bevor die Authentifizierung erfolgen kann. Wenn bei einem required Modul Fehler auftreten, wird der Benutzer darüber informiert, sobald auch alle anderen Module, welche die gleiche Schnittstelle referenzieren überprüft wurden.
requisite — Solche Module müssen ebenfalls überprüft werden, bevor die Authentifizierung erfolgreich sein kann. Wenn bei einem requisite Modul Fehler auftreten, wird der Benutzer hierüber sofort informiert. Diese Mitteilung zeigt das erste fehlerhafte required oder requisite Modul an.
sufficient — Bei solchen Modulen werden Fehler ignoriert. Wenn ein sufficient Modul jedoch erfolgreich überprüft wurde, und kein required Modul fehlschlägt, werden keine weiteren Überprüfungen dieser Modul-Schnittstelle benötigt und diese wird erfolgreich authentifiziert.
optional — Solche Module sind für die erfolgreiche oder fehlgeschlagene Authentifizierung dieser Modul-Schnittstelle nicht von Bedeutung. Diese werden nur dann wichtig, wenn kein anderes Modul dieser Modul-Schnittstelle erfolgreich war oder fehlgeschlagen ist.
![]() | Wichtig |
---|---|
Die Reihenfolge in welcher required Module aufgerufen werden spielt keine Rolle. Bei den Steuer-Flags sufficient und requisite ist die Reihenfolge allerdings wichtig. |
Eine neuere Steuer-Flag Syntax mit immer mehr Kontrollmöglichkeiten steht nun für PAM zur Verfügung. Mehr Informationen über diese neue Syntax finden Sie in den PAM-Dokumentationen im Verzeichnis /usr/share/doc/pam-version-number/ (wobei <version-number> die Versionsnummer von PAM ist).
Der Modulname liefert PAM den Namen des Pluggable Moduls, das die angegebene Modulschnittstelle enthält. Unter älteren Versionen von Red Hat Enterprise Linux wurde der vollständige Pfad zum Modul in der PAM-Konfigurationsdatei angegeben, wie z.B. /lib/security/pam_stack.so. Seit dem Aufkommen von Multilib-Systemen, die 64-bit PAM Module im Verzeichnis /lib64/security/ speichern, wird der Verzeichnisname jedoch weggelassen, da die Applikation zur richtigen Version von libpam verbunden ist, die die richtige Version des Moduls feststellen kann.
PAM verwendet Argumente, um während der Authentifizierung Informationen über eine bestimmte Modul-Schnittstelle einem "Pluggable Module" zu übermitteln.
Zum Beispiel verwendet das Modul pam_userdb.so versteckte Dateien aus der Berkeley DB-Datei, um den Benutzer zu authentifizieren. Berkeley DB ist eine in vielen Anwendungen eingebundenes Open-Source Datenbank-System. Das Modul verwendet ein db Argument, welches die von Berkeley DB für den angeforderten Service zu verwendende Datenbank angibt.
Eine typische pam_userdb.so Zeile in einer PAM- Konfigurationsdatei sieht wie folgt aus:
auth required pam_userdb.so db=<path-to-file> |
Im vorangegangenen Beispiel ersetzen Sie <path-to-file> mit dem vollständigen Pfad der Berkeley DB Datenbank-Datei.
Ungültige Argumente werden ignoriert und wirken sich auch nicht auf den Erfolg oder Misserfolg eines PAM-Moduls aus. Wenn ein ungültiges Argument auftaucht, erscheint jedoch normalerweise eine Fehlermeldung in /var/log/messages.
Zurück | Zum Anfang | Nach vorne |
PAM-Konfigurationsdateien | Nach oben | Beispiele für PAM-Konfigurationsdateien |