PAM-modulen är okänd: vilken process misslyckades egentligen

Läs den meningen som ett påstående om ett delat objekt och en funktionspekare, inte om ett lösenord. Samma ord kan komma från en OpenVPN plugin, från en PAM-stack som laddats för en enda tjänst eller inifrån RADIUS-demonen, och det är tre olika utredningar. Välj processen först.

Kontrollerna nedan förutsätter att meddelandet uppstod via en Linux-PAM-integrering vid en VPN-inloggning. Om det kom från RADIUS-serverns egen konfiguration är den demonens bevis stället att börja.

Namnge processen innan du namnge paketet

Tre komponenter kallas modul och ingen av dem är utbytbar. En OpenVPN-autentiseringsplugin laddas av VPN-demonen och implementerar den demonens callback-gränssnitt. En PAM-modul är ett delat objekt som libpam laddar för en namngiven tjänst, och som implementerar ingångspunkter som pam_sm_authenticate. En FreeRADIUS-modul är en del av den demonens egen konfiguration. Ett meddelande med samma ord kan komma från alla tre, så den första frågan är vilken logglinje som skapade det.

Korrelera tidsstämpeln för ett misslyckat försök mellan VPN-loggen och systemets autentiseringslogg och läs sedan raderna före sammanfattningen. Det specifika laddarmeddelandet finns oftast redan där.

Läs inläsningsfelet och sedan ingångspunkten

PAM rapporterar en okänd modul när den inte kan ladda det valda delade objektet, eller när det laddade objektet inte tillhandahåller den funktion som stackposten kräver. Det är olika reparationer: den första är ett problem med sökväg, paketering eller ABI, och den andra är en ingångspunkt som inte stämmer. En auth-rad behöver pam_sm_authenticate medan en kontorad behöver pam_sm_acct_mgmt, och ett bibliotek som bara implementerar en av dem misslyckas på den andra, som dispatcher-koden visar. Att hitta filen på disken bevisar inget av det.

Att ta ett bibliotek med liknande namn från en annan distribution eller CPU-arkitektur är inte en reparation, och det kan lämna en process som laddar en modul som aldrig testats mot dess libpam. Kontrollera paketet som äger den avsedda sökvägen och filens verkliga arkitektur innan du ändrar något.

Behåll garantierna som stacken gav

Det snabbaste sättet att tysta det här felet är också det sämsta: att markera en obligatorisk modul som valfri, ta bort kontofasen, eller infoga ett ovillkorligt tillstånd. Var och en av dessa gör en misslyckad kontroll till en saknad kontroll, och inloggningen lyckas då av skäl som ingen avsåg. Återställning av lösenord och ändringar av den delade hemligheten ger inte heller den saknade funktionen, eftersom felet inträffar innan några autentiseringsuppgifter når en backend.

En stack med flera moduler kan ha kört en annan backend före den felande posten, så felet bevisar inte att ingen RADIUS-förfrågan skickades.

Verifiera inloggningen, inte modulen

När avvikelsen är rättad, testa den faktiska åtkomstvägen. Ett giltigt konto bör lyckas, ogiltiga autentiseringsuppgifter bör fortfarande misslyckas och ett förbjudet konto bör fortfarande avvisas. Bekräfta också att ett krav på certifikat eller extra faktor fortfarande tillämpas, eftersom en reparerad stack som hoppar över ett steg ser ut som framgång från klientens sida.

Att en modul laddas rent är framsteg, inte ett avslutat test.

Anteckna vilket tjänstenamn, vilka policyfiler och vilka ingångspunkter som var inblandade, tillsammans med det enda försök du använde som bevis. Den anteckningen gör nästa förekomst till en sökning i stället för en arkeologisk övning.