Modulo PAM estas nekonata: kiu procezo fakte malsukcesis

Legu tiun frazon kiel aserton pri komuna objekto kaj funkcia montrilo, ne pri pasvorto. La samaj vortoj povas veni el OpenVPN-kromaĵo, de PAM-stako ŝarĝita por unu servo, aŭ el interne de la RADIUS-demono, kaj tio estas tri malsamaj esploroj. Unue elektu la procezon.

La sekvaj kontroloj supozas, ke la mesaĝo aperis per Linux-PAM-integriĝo ĉe VPN-ensaluto. Se ĝi venis el la propra agordo de la RADIUS-servilo, la pruvoj de tiu demono estas la loko por komenci.

Nomu la procezon antaŭ ol nomi la pakaĵon

Tri komponentoj nomiĝas modulo kaj neniu el ili estas interŝanĝebla. OpenVPN-aŭtentiga kromaĵo estas ŝarĝata de la VPN-demono kaj realigas la retrovoĥan interfacon de tiu demono. PAM-modulo estas komuna objekto, kiun libpam ŝarĝas por nomita servo, kaj kiu realigas enirpunktojn kiel pam_sm_authenticate. FreeRADIUS-modulo estas parto de la propra agordo de tiu demono. Mesaĝo kun la samaj vortoj povas veni de iu ajn el la tri, do la unua demando estas, kiu protokola linio produktis ĝin.

Kunigu la tempomarkon de unu malsukcesa provo inter la VPN-protokolo kaj la sistema aŭtentiga protokolo, poste legu la liniojn antaŭ la resumo. La konkreta mesaĝo de la ŝargilo kutime jam estas tie.

Legu la ŝarĝeraron, poste la enirpunkton

PAM raportas nekonatan modulon, kiam ĝi ne povas ŝarĝi la elektitan komunan objekton, aŭ kiam la ŝarĝita objekto ne provizas la funkcion, kiun postulas tiu stakero. Tio estas malsamaj riparoj: la unua estas problemo pri vojo, pakaĵo aŭ ABI, kaj la dua estas neakorda enirpunkto. Aŭtentiga linio bezonas pam_sm_authenticate dum kontolinio bezonas pam_sm_acct_mgmt, kaj biblioteko, kiu realigas nur unu el ili, malsukcesos ĉe la alia, kiel la kodo de la dissendilo montras. Trovi la dosieron sur la disko pruvas nek unu nek la alian.

Preni bibliotekon kun simila nomo el alia distribuaĵo aŭ CPU-arkitekturo ne estas ripari, kaj ĝi povas lasi procezon ŝarĝanta modulon, kiu neniam estis testita kontraŭ sia libpam. Kontrolu la pakaĵon, kiu posedas la celitan vojon, kaj la realan arkitekturon de la dosiero antaŭ ol ŝanĝi ion ajn.

Konservu la garantiojn, kiujn la stako donis

La plej rapida maniero silentigi ĉi tiun eraron estas ankaŭ la plej malbona: marki postulatan modulon kiel laŭvolan, forigi la kontan etapon, aŭ enmeti senkondiĉan permeson. Ĉiu el tiuj ŝanĝas malsukcesan kontrolon en forestantan kontrolon, kaj la ensaluto tiam sukcesas pro kialoj, kiujn neniu intencis. Pasvortaj restarigoj kaj ŝanĝoj de komuna sekreto ankaŭ ne provizas mankantan funkcion, ĉar la malsukceso okazas antaŭ ol iu ajn legitimilo atingas malantaŭan servilon.

Stako kun pluraj moduloj eble funkciigis alian malantaŭan servilon antaŭ la malsukcesa ero, do la eraro ne pruvas, ke neniu RADIUS-peto estis sendita.

Kontrolu la ensaluton, ne la modulon

Post kiam la malkongruo estas korektita, testu la faktan akceptvojon. Valida konto devus sukcesi, nevalidaj legitimiloj devus ankoraŭ malsukcesi, kaj malpermesita konto devus ankoraŭ esti rifuzata. Konfirmu ankaŭ, ke ajna postulo pri atestilo aŭ aldona faktoro ankoraŭ estas plenumata, ĉar riparita stako, kiu saltas etapon, aspektas kiel sukceso de la klienta flanko.

Tio, ke modulo ŝarĝiĝas pure, estas progreso, ne finita testo.

Notu, kiu serva nomo, kiuj politikaj dosieroj kaj kiuj enirpunktoj estis engaĝitaj, kune kun la ununura provo, kiun vi uzis kiel pruvon. Ĝuste tiu noto faras la sekvan okazon serĉado anstataŭ arkeologia ekzerco.