Gute Argumente
Die letzte Spalte (Argumente) ist optional und enthält nur bei einigen Modulen einen Eintrag. Argumente sind als Liste anzugeben, deren Felder durch Leerzeichen getrennt sind. Es gibt einfache Flags wie »nullok« oder »use_first_pass« sowie Zuweisungen, zum Beispiel »strict=false«. Kommen Leerzeichen in einem Argument vor, ist es in eckige Klammern zu setzen. Soll eine eckige Klammer Bestandteil des Arguments sein, führt ein Backslash-Quoting zum Erfolg.
Die Liste möglicher Argumente ist nicht von PAM vorgegeben, sondern abhängig vom Modul. Manche Argumente werden aber von fast allen Modulen verstanden: »debug« liefert Diagnosemeldungen an das Systemlog, »no_warn« unterdrückt sie. Authentifizierungs- und Passwortmodule kennen zudem »use_first_pass«. Mit dieser Option versucht das Modul, das Passwort vom vorhergehenden »auth«-Modul zu übernehmen. Schlägt dies fehl, meldet es den Status »fail«. Ähnlich wirkt »try_first_pass«, nur fordert es im Fehlerfall die Applikation und damit den Benutzer auf, das Passwort erneut einzutippen.
Falsch eingetragene Argumente ignoriert PAM. Bei falsch formatierten Zeilen sorgt es sicherheitshalber dafür, dass das betroffene Modul die Meldung »fail« als Statuswert zurückgibt.
Für jeden Zweck ein passendes PAM-Modul
Inzwischen gibt es PAM-Module für fast alle Aufgaben, manchmal sogar verschiedene Implementation für dieselbe Aufgabe. Das PAM-Standardpaket bringt schon eine Menge Module mit. Nur für spezielle Aufgaben wie LDAP-Authentifizierung oder um AFS-Token zu beschaffen sind zusätzliche PAM-Module nötig. Tabelle 3 stellt die gängigen Module zusammen. Darüber hinaus gibt es noch eine ganze Reihe weiterer Module für bestimmte Einsatzszenarien.
|
|
|
Modul
|
Aufgabe
|
|
pam_access
|
Stellt eine Art Access Control List zur Verfügung. Das
Modul erwartet eine Konfigurationsdatei
»/etc/security/access.conf«. Dort pflegt der Admin » Erlaubnis : Anwender : Ursprung«-Listen.
|
|
pam_afs
|
Dieses Authentifizierungsmodul kennt zwei Betriebsarten.
Entweder authentifiziert ein anderes Modul den Benutzer, dann holt
»pam_afs« nur noch das Token vom AFS-Server. Oder
»pam_afs« authentifiziert den User ebenfalls selbst.
|
|
pam_chroot
|
Dieses Modul enthält Account-, Session- und
Authentifizierungskomponenten. Es versetzt Benutzer beim Login in einen Changeroot-Käfig.
|
|
pam_cracklib
|
Setzt Richtlinien für gute Passwörter durch, Benutzer
können damit keine erkennbar schlechten Passwörter
verwenden. Das Modul arbeitet in der Kategorie
»Password«. Es benötigt die Cracklib und passende Wörterbücher.
|
|
pam_deny
|
Verhindert immer den Zugriff, dazu sendet das Modul eine entsprechende Rückmeldung an die aufrufende Applikation.
|
|
pam_devperm
|
Passt die Zugriffsrechte auf Device-Files an. Damit dürfen
lokal eingeloggte User zum Beispiel das Floppy-Laufwerk und die
Soundkarte nutzen. Es liest die Konfigurationsdatei »/etc/logindevperm«.
|
|
pam_env
|
Passt die Umgebungsvariablen an. Es benutzt dazu die
Konfigurationsdatei »/etc/security/pam_env.conf«. Diese
kann festlegen, welche »DEFAULT«-Werte für eine
Variable gelten oder wie diese überschrieben (»OVERRIDE«) werden sollen.
|
|
pam_lastlog
|
Kümmert sich als Modul der Session-Kategorie um die Datei
»/var/log/lastlog« und trägt dort den Benutzer
ein. Es kann, wenn das nicht schon die Applikation erledigt, auch anzeigen, wann der Nutzer das letzte Mal angemeldet war.
|
|
pam_ldap
|
Benutzerauthentifizierung gegen eine LDAP-Datenbank. Je
nachdem, wie dieses Modul kompiliert wurde, bezieht es seine
LDAP-Konfiguration aus »/etc/ldap.conf« oder »/etc/openldap/ldap.conf«.
|
|
pam_limits
|
Erlaubt es dem Systemadministrator festzulegen, wie viel
Systemressourcen (Speicher, CPU-Zeit ...) dem Benutzer maximal zur
Verfügung stehen. Diese Einschränkungen gelten nicht
für User mit der ID 0. Die Konfigurationsdatei für dieses Modul ist »/etc/security/limits.conf«.
|
|
pam_mkhomedir
|
Legt bei Bedarf ein Homeverzeichnis für den Benutzer an.
|
|
pam_mktemp
|
Kann als Teil des Session- oder Accountmanagements für
angemeldete Benutzer ein persönliches Temporärverzeichnis
festlegen. Hierzu setzt es die Umgebungsvariablen »TMPDIR« und »TMP«.
|
|
pam_nologin
|
Prüft, ob die Datei »pam_nologin« existiert.
Wenn ja, zeigt es jedem Benutzer (bis auf den Systemadministrator)
den Inhalt dieses Files und verhindert, dass sich der User anmeldet.
|
|
pam_permit
|
Liefert immer ein fröhliches »sucess«. Dieses
Modul sollte nur unter sehr speziellen Bedingungen zum Einsatz kommen.
|
|
pam_pwcheck
|
Stellt Hilfsfunktionen in der »password«-Kategorie
für die Passwortänderung zur Verfügung. Es verwendet
Einstellungen aus »/etc/login.defs«. Hier kann der
Admin mittels Modulargument festlegen, nach welchem Crypt-Verfahren
(»md5«, »blowfish« ...) das Passwort verschlüsselt wird.
|
|
pam_rootok
|
Ein Modul der Authentifizierungskategorie. Es kann für
bestimmte Dienste (wie »su«) dem Admin einen Login ohne
Passwort erlauben. Auf diese Weise kann Root zu einem normalen User werden, ohne dessen Passwort wissen zu müssen.
|
|
pam_securetty
|
Stellt fest, von welchem Terminal (TTY) sich der
Systemadministrator anmelden darf. Die Datei
»/etc/securetty« enthält hierfür eine Liste von Devices, von denen aus sich Root anmelden kann.
|
|
pam_unix
|
Das Standard-Unix-Authentifizierungsmodul, das ebenfalls
Komponenten für »session«, »password«
und »account« zur Verfügung stellt. Es benutzt die
Standardaufrufe der Systembibliotheken und beschafft Informationen aus »/etc/passwd« und »/etc/shadow«.
|
|
pam_warn
|
Hat die Aufgabe, Log-Output zu generieren und an den Syslog
weiterzugeben. Es arbeitet in den Kategorien »authentication« und »password«.
|
|
pam_winbind
|
Kommt mit der Samba-Suite und erlaubt eine Authentifizierung gegen Windows-Systeme.
|
Modulen im Betastadium sollte der Admin lieber mit Vorsicht begegnen. Zu dieser kritischen Kategorie zählt zum Beispiel »pam_storepw«, ein Passwort-Caching-Modul. Es arbeitet in der Auth-Kategorie und kann im Stapel mit anderen Authentifizierungsmodulen Benutzername und Passwort abgreifen.
Diese Geheimnisse landen als Klartext in einem für Root lesbaren Verzeichnis »/var/run/pw«. Mit diesen Daten kann der Automounter geschützte Samba-Shares einbinden, die ebenfalls Benutzername und Passwort erfordern. Das Verfahren ist zwar ziemlich riskant, »pam_storepw« liefert jedoch eine hervorragende Programmiervorlage für eigene PAM-Erweiterungen.
|
Ähnliche Artikel
|
|
Gezähmter Höllenhund
|
Linux-Authentifizierung über einen Active-Directory-Service mit Kerberos 5
Active-Directory-Service mit Kerberos 5
|
|
Fenster-Öffnung
|
Zentrale Benutzerverwaltung für Linux-Clients im Active
Directory
|
|
Verhandlungskünstler
|
Fremde Daten aufs Dateisystem abbilden
|
|
Aufmerksamer Wächter
|
Authentifizierung an der Firewall dank Netfilter-Modul
|
|
Der Sun-Blocker
|
Die freie Terminalserver-Software X2go in neuer Version
|
|
Bastelstunde
|
Workshop: Einen modernen Fileserver fürs Unternehmen aufsetzen
|
| Whitepaper |
|
Usage Landscape Enterprise Open Source Data Integration
Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.
Download PDF (Registrierung erforderlich)
|
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|