PAM-module is onbekend: welk proces is werkelijk mislukt

Lees die zin als een uitspraak over een gedeeld object en een functiepointer, niet over een wachtwoord. Dezelfde woorden kunnen van een OpenVPN plugin komen, van een PAM-stack die voor één dienst is geladen of van binnen de RADIUS-daemon, en dat zijn drie verschillende onderzoeken. Kies eerst het proces.

De controles hieronder gaan ervan uit dat het bericht via een Linux-PAM-integratie bij een VPN-aanmelding is verschenen. Kwam het uit de configuratie van de RADIUS-server zelf, begin dan bij het bewijs van die daemon.

Noem het proces voordat je het pakket noemt

Drie componenten worden module genoemd en geen ervan is uitwisselbaar. Een OpenVPN-authenticatieplugin wordt door de VPN-daemon geladen en implementeert de callback-interface van die daemon. Een PAM-module is een gedeeld object dat libpam voor een genoemde dienst laadt, en dat ingangspunten implementeert zoals pam_sm_authenticate. Een FreeRADIUS-module is een onderdeel van de eigen configuratie van die daemon. Een bericht met dezelfde woorden kan van alle drie komen, dus de eerste vraag is welke logregel het heeft geproduceerd.

Correleer de tijdstempel van één mislukte poging tussen het VPN-log en het systeem-authenticatielog en lees daarna de regels vóór de samenvatting. Het specifieke laadbericht staat daar meestal al.

Lees de laadfout en daarna het ingangspunt

PAM meldt een onbekende module wanneer het het gekozen gedeelde object niet kan laden, of wanneer het geladen object de functie niet levert die die stackregel vereist. Dat zijn verschillende reparaties: de eerste is een probleem met pad, verpakking of ABI, en de tweede is een ingangspunt dat niet klopt. Een auth-regel heeft pam_sm_authenticate nodig, terwijl een accountregel pam_sm_acct_mgmt nodig heeft, en een bibliotheek die er slechts één van implementeert, faalt op de andere, zoals de dispatcher-code laat zien. Het bestand op schijf vinden bewijst geen van beide.

Een bibliotheek met een vergelijkbare naam uit een andere distributie of CPU-architectuur halen is geen reparatie, en het kan een proces achterlaten dat een module laadt die nooit tegen zijn libpam is getest. Controleer het pakket dat het beoogde pad bezit en de werkelijke architectuur van het bestand voordat je iets verandert.

Behoud de garanties die de stack gaf

De snelste manier om deze fout te dempen is ook de slechtste: een vereiste module als optioneel markeren, de accountfase verwijderen, of een onvoorwaardelijke toelating invoegen. Elk daarvan maakt van een mislukte controle een ontbrekende controle, en de aanmelding slaagt dan om redenen die niemand bedoelde. Wachtwoordresets en wijzigingen van het gedeelde geheim leveren ook geen ontbrekende functie, want de fout treedt op voordat enige inloggegevens een backend bereiken.

Een stack met meerdere modules kan vóór de falende regel een andere backend hebben gedraaid, dus de fout bewijst niet dat er geen RADIUS-verzoek is verzonden.

Controleer de aanmelding, niet de module

Zodra de afwijking is gecorrigeerd, test het werkelijke toegangspad. Een geldig account zou moeten slagen, ongeldige inloggegevens zouden nog steeds moeten falen, en een verboden account zou nog steeds moeten worden geweigerd. Bevestig ook dat een certificaat- of extra-factorvereiste nog steeds wordt afgedwongen, want een gerepareerde stack die een fase overslaat lijkt vanuit de client op succes.

Dat een module schoon laadt is vooruitgang, geen afgeronde test.

Noteer welke dienstnaam, welke beleidsbestanden en welke ingangspunten betrokken waren, samen met de enige poging die je als bewijs gebruikte. Die notitie maakt het volgende geval een opzoeking in plaats van een archeologische oefening.