Moduli PAM është i panjohur: cili proces dështoi në të vërtetë
Mesazhi emërton një objekt të përbashkët dhe një pikë hyrjeje, jo një fjalëkalim. Gjeni procesin që e regjistroi, më pas kontrolloni ngarkimin, simbolet dhe garancitë e stakut.
Lexojeni atë frazë si një deklaratë për një objekt të përbashkët dhe një tregues funksioni, jo për një fjalëkalim. Të njëjtat fjalë mund të vijnë nga një OpenVPN shtojcë, nga një stak PAM i ngarkuar për një shërbim ose nga brenda demonit RADIUS, dhe këto janë tri hetime të ndryshme. Zgjidhni fillimisht procesin.
Kontrollimet më poshtë supozojnë se mesazhi u shfaq përmes një integrimi Linux-PAM në një hyrje VPN. Nëse erdhi nga konfigurimi i vetë serverit RADIUS, filloni me provat e atij demoni.
Emërtoni procesin përpara se të emërtoni paketën
Tre komponentë quhen modul dhe asnjëri nuk është i këmbyeshëm. Një shtojcë autentikimi OpenVPN ngarkohet nga demoni VPN dhe zbaton ndërfaqen e kthimit të thirrjes të atij demoni. Moduli PAM është një objekt i përbashkët që libpam e ngarkon për një shërbim të emërtuar, dhe që zbaton pika hyrjeje si pam_sm_authenticate. Moduli FreeRADIUS është një pjesë e konfigurimit të vetë atij demoni. Një mesazh me të njëjtat fjalë mund të vijë nga secili prej të treve, prandaj pyetja e parë është cila rresht regjistri e prodhoi atë.
Ndërlidhni vulën kohore të një tentative të dështuar midis regjistrit VPN dhe regjistrit të autentikimit të sistemit, më pas lexoni rreshtat përpara përmbledhjes. Mesazhi specifik i ngarkuesit zakonisht është tashmë atje.
Lexoni gabimin e ngarkimit, më pas pikën e hyrjes
PAM raporton një modul të panjohur kur nuk mund të ngarkojë objektin e zgjedhur të përbashkët, ose kur objekti i ngarkuar nuk ofron funksionin që kërkon ai rresht i stakut. Këto janë riparime të ndryshme: i pari është problem rruge, paketimi ose ABI, dhe i dyti është një pikë hyrjeje që nuk përputhet. Një rresht autentikimi ka nevojë për pam_sm_authenticate ndërsa një rresht llogarie ka nevojë për pam_sm_acct_mgmt, dhe një bibliotekë që zbaton vetëm njërin prej tyre do të dështojë në tjetrin, siç kodi i dërguesit tregon. Gjetja e skedarit në disk nuk vërteton asnjërin.
Marrja e një biblioteke me emër të ngjashëm nga një shpërndarje ose arkitekturë tjetër procesori nuk është riparim, dhe mund të lërë një proces duke ngarkuar një modul që nuk është testuar kurrë me libpam-in e tij. Kontrolloni paketën që zotëron rrugën e synuar dhe arkitekturën reale të skedarit përpara se të ndryshoni diçka.
Ruani garancitë që jepte staku
Mënyra më e shpejtë për ta heshtur këtë gabim është edhe më e keqja: shënimi i një moduli të detyrueshëm si opsional, fshirja e fazës së llogarisë, ose futja e një lejeje pa kushte. Secila prej tyre e shndërron një kontroll të dështuar në një kontroll që mungon, dhe hyrja pastaj ka sukses për arsye që askush nuk i synonte. Rivendosja e fjalëkalimeve dhe ndryshimi i sekretit të përbashkët as nuk ofrojnë funksionin që mungon, sepse dështimi ndodh përpara se ndonjë kredencial të arrijë një backend.
Një stak me disa module mund të ketë ekzekutuar një backend tjetër përpara rreshtit të dështuar, prandaj gabimi nuk vërteton se nuk u dërgua asnjë kërkesë RADIUS.
Verifikoni hyrjen, jo modulin
Pasi korrigjohet mospërputhja, provoni rrugën reale të pranimit. Një llogari e vlefshme duhet të kalojë, kredencialet e pavlefshme duhet të vazhdojnë të dështojnë, dhe një llogari e ndaluar duhet të vazhdojë të refuzohet. Konfirmoni gjithashtu se çdo kërkesë për certifikatë ose faktor shtesë ende zbatohet, sepse një stak i riparuar që kalon një fazë duket si sukses nga ana e klientit.
Ngarkimi i pastër i një moduli është përparim, jo një test i përfunduar.
Regjistroni cili emër shërbimi, cilat skedarë politikash dhe cilat pika hyrjeje ishin të përfshira, së bashku me tentativën e vetme që përdorët si provë. Ky regjistrim është ai që e kthen rastin e radhës në një kërkim dhe jo në një ushtrim arkeologjik.