PAM-Modul ist unbekannt: Welcher Prozess ist tatsächlich fehlgeschlagen

Lesen Sie diesen Satz als Aussage über ein Shared Object und einen Funktionszeiger, nicht über ein Passwort. Dieselben Worte können von einem OpenVPN Plugin stammen, von einem PAM-Stack, der für einen Dienst geladen wurde, oder aus dem Inneren des RADIUS-Daemons, und das sind drei verschiedene Untersuchungen. Bestimmen Sie zuerst den Prozess.

Die folgenden Prüfungen setzen voraus, dass die Meldung über eine Linux-PAM-Integration bei einer VPN-Anmeldung aufgetreten ist. Kam sie aus der Konfiguration des RADIUS-Servers selbst, beginnen Sie mit den Belegen dieses Daemons.

Benennen Sie den Prozess, bevor Sie das Paket benennen

Drei Komponenten werden Modul genannt, und keine ist austauschbar. Ein OpenVPN-Authentifizierungs-Plugin wird vom VPN-Daemon geladen und implementiert dessen Callback-Schnittstelle. Ein PAM-Modul ist ein Shared Object, das von libpam für einen benannten Dienst geladen wird und Einstiegspunkte wie pam_sm_authenticate implementiert. Ein FreeRADIUS-Modul ist ein Teil der eigenen Konfiguration dieses Daemons. Eine Meldung mit denselben Worten kann von allen dreien kommen, daher lautet die erste Frage, welche Logzeile sie erzeugt hat.

Korrelieren Sie den Zeitstempel eines fehlgeschlagenen Versuchs zwischen VPN-Log und System-Authentifizierungslog und lesen Sie dann die Zeilen vor der Zusammenfassung. Die konkrete Lader-Meldung steht meist schon dort.

Lesen Sie den Ladefehler, dann den Einstiegspunkt

PAM meldet ein unbekanntes Modul, wenn es das ausgewählte Shared Object nicht laden kann oder wenn das geladene Objekt die Funktion nicht bereitstellt, die dieser Stack-Eintrag verlangt. Das sind unterschiedliche Reparaturen: Das erste ist ein Pfad-, Paketierungs- oder ABI-Problem, das zweite ein nicht passender Einstiegspunkt. Eine auth-Zeile braucht pam_sm_authenticate während eine account-Zeile pam_sm_acct_mgmt braucht, und eine Bibliothek, die nur eines davon implementiert, scheitert am anderen, wie der Dispatcher-Code zeigt. Die Datei auf der Platte zu finden, beweist keines von beiden.

Eine Bibliothek mit ähnlichem Namen aus einer anderen Distribution oder CPU-Architektur zu nehmen, ist keine Reparatur, und es kann einen Prozess zurücklassen, der ein Modul lädt, das nie gegen sein libpam getestet wurde. Prüfen Sie das Paket, dem der vorgesehene Pfad gehört, und die tatsächliche Architektur der Datei, bevor Sie etwas ändern.

Bewahren Sie die Garantien, die der Stack gab

Der schnellste Weg, diesen Fehler zum Schweigen zu bringen, ist auch der schlechteste: ein erforderliches Modul als optional markieren, die Konto-Stufe löschen oder eine unbedingte Freigabe einfügen. Jede davon macht aus einer fehlgeschlagenen Prüfung eine fehlende Prüfung, und die Anmeldung gelingt dann aus Gründen, die niemand beabsichtigt hat. Passwort-Zurücksetzungen und Änderungen gemeinsamer Geheimnisse liefern ebenfalls keine fehlende Funktion, denn der Fehler tritt auf, bevor irgendeine Anmeldeinformation ein Backend erreicht.

Ein Stack mit mehreren Modulen kann vor dem fehlschlagenden Eintrag ein anderes Backend ausgeführt haben, daher beweist der Fehler nicht, dass keine RADIUS-Anfrage gesendet wurde.

Prüfen Sie die Anmeldung statt das Modul

Sobald die Abweichung korrigiert ist, testen Sie den tatsächlichen Zulassungsweg. Ein gültiges Konto sollte durchkommen, ungültige Anmeldeinformationen sollten weiterhin scheitern, und ein gesperrtes Konto sollte weiterhin abgelehnt werden. Bestätigen Sie außerdem, dass eine Zertifikats- oder Zusatzfaktor-Anforderung noch durchgesetzt wird, denn ein reparierter Stack, der eine Stufe überspringt, sieht aus Sicht des Clients wie Erfolg aus.

Dass ein Modul sauber lädt, ist Fortschritt, kein abgeschlossener Test.

Notieren Sie, welcher Dienstname, welche Richtliniendateien und welche Einstiegspunkte beteiligt waren, zusammen mit dem einen Versuch, den Sie als Beleg genutzt haben. Genau diese Notiz macht den nächsten Fall zu einem Nachschlagen statt zu einer archäologischen Übung.