Red Hat Linux 9: Red Hat Linux Referenzhandbuch | ||
---|---|---|
Zurück | Kapitel 14. Pluggable Authentication Modules (PAM) | Vor |
Jede PAM Konfigurationsdatei enthält eine Gruppe von Anweisungen, welche wie folgt formattiert sind:
<module interface> <control flag> <module path> <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 Module werden zur Authentifizierung des Benutzers benutzt, zum Beispiel durch Erfragen und Überprüfen des Passworts und dem Einstellen von Berechtigungsmerkmalen, wie z.B. Mitgliedschaft in einer Gruppe oder Kerberos-Tickets.
account — Diese Module stellen 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 Module werden zur Einstellung des Passworts verwendet.
session — Diese Module werden, nachdem der Benutzer authentifiziert wurde, dazu verwendet, seine 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 /lib/security/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 /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth |
Bevor rlogin ausgeführt wird, stellt PAM fest, dass die /etc/nologin Dateien nicht existieren, dass sie auch nicht versuchen, sich aus der Ferne über eine unverschlüsselte Netzwerkverbindung als Root anzumelden und dass alle Umgebungsvariablen geladen werden können.Wenn die rhosts -Authentifizierung erfolgreich, kann die Verbindung zugelassen werden. Ist die Authentifizierung nicht erfolgreich ist, 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. In diesem Fall bestimmt der Erfolg oder Misserfolg eines optional Moduls die gesamte PAM-Authentifikation für diese Modul-Schnittstelle.
![]() | 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).
Modulpfade geben PAM an, wo die "Pluggable Modules" zu finden sind, die von der ausgewählten Modul-Schnittstelle verwendet werden. Sie geben üblicherweise den kompletten Pfad zu einem Modul an, wie zum Beispiel /lib/security/pam_stack.so. Wenn der komplette Pfad jedoch nicht angegeben ist, wird angenommen, dass sich das angegebene Modul in /lib/security/ , dem Default-Verzeichnis für PAM-Module, befindet.
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 /lib/security/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 | Vor |
PAM-Konfigurationsdateien | Zum Kapitelanfang | Beispiele für PAM-Konfigurationsdateien |