Modulul PAM este necunoscut: care proces a eșuat de fapt

Citiți această frază ca o afirmație despre un obiect partajat și un pointer de funcție, nu despre o parolă. Aceleași cuvinte pot veni dintr-un OpenVPN plugin, dintr-o stivă PAM încărcată pentru un singur serviciu sau din interiorul demonului RADIUS, și acestea sunt trei investigații diferite. Alegeți mai întâi procesul.

Verificările de mai jos presupun că mesajul a apărut printr-o integrare Linux-PAM la o autentificare VPN. Dacă a venit din configurația serverului RADIUS însuși, începeți cu dovezile acelui demon.

Numiți procesul înainte de a numi pachetul

Trei componente se numesc modul și niciuna nu este interschimbabilă. Un plugin de autentificare OpenVPN este încărcat de demonul VPN și implementează interfața de apel invers a acelui demon. Un modul PAM este un obiect partajat pe care libpam îl încarcă pentru un serviciu numit, și care implementează puncte de intrare precum pam_sm_authenticate. Un modul FreeRADIUS este o parte din configurația proprie a acelui demon. Un mesaj cu aceleași cuvinte poate veni de la oricare dintre cele trei, așa că prima întrebare este care linie de jurnal l-a produs.

Corelați marca temporală a unei încercări eșuate între jurnalul VPN și jurnalul de autentificare al sistemului, apoi citiți liniile dinaintea rezumatului. Mesajul specific al încărcătorului este de obicei deja acolo.

Citiți eroarea de încărcare, apoi punctul de intrare

PAM raportează un modul necunoscut atunci când nu poate încărca obiectul partajat selectat sau când obiectul încărcat nu oferă funcția cerută de acea intrare a stivei. Sunt reparații diferite: prima este o problemă de cale, împachetare sau ABI, iar a doua este un punct de intrare care nu corespunde. O linie de autentificare are nevoie de pam_sm_authenticate în timp ce o linie de cont are nevoie de pam_sm_acct_mgmt, iar o bibliotecă ce implementează doar una dintre ele va eșua la cealaltă, după cum codul dispecerului arată. Găsirea fișierului pe disc nu dovedește niciuna.

Luarea unei biblioteci cu nume similar dintr-o altă distribuție sau arhitectură de procesor nu este o reparație și poate lăsa un proces să încarce un modul care nu a fost niciodată testat cu libpam-ul său. Verificați pachetul care deține calea dorită și arhitectura reală a fișierului înainte de a schimba ceva.

Păstrați garanțiile pe care le oferea stiva

Cea mai rapidă modalitate de a închide această eroare este și cea mai rea: marcarea unui modul obligatoriu ca opțional, ștergerea etapei de cont, sau inserarea unei permisiuni necondiționate. Fiecare dintre ele transformă o verificare eșuată într-o verificare absentă, iar autentificarea reușește apoi din motive pe care nimeni nu le-a intenționat. Resetarea parolelor și schimbarea secretului comun nici nu furnizează funcția lipsă, pentru că eșecul apare înainte ca vreo acreditare să ajungă la un backend.

O stivă cu mai multe module poate a executat un alt backend înainte de intrarea eșuată, așa că eroarea nu dovedește că nu a fost trimisă nicio cerere RADIUS.

Verificați autentificarea, nu modulul

După corectarea discrepanței, testați calea reală de admitere. Un cont valid ar trebui să treacă, acreditările invalide ar trebui să eșueze în continuare, iar un cont interzis ar trebui să fie în continuare respins. Confirmați și că orice cerință de certificat sau factor suplimentar este încă aplicată, pentru că o stivă reparată care sare o etapă pare un succes din partea clientului.

Faptul că un modul se încarcă curat este un progres, nu un test încheiat.

Notați ce nume de serviciu, ce fișiere de politică și ce puncte de intrare au fost implicate, împreună cu singura încercare pe care ați folosit-o ca dovadă. Acea notă face din următoarea apariție o căutare, nu un exercițiu de arheologie.