PAM-modulen er ukjent: hvilken prosess sviktet egentlig

Les denne setningen som en uttalelse om et delt objekt og en funksjonspeker, ikke om et passord. De samme ordene kan komme fra en OpenVPN plugin, fra en PAM-stakk lastet for én tjeneste eller fra innsiden av RADIUS-demonen, og det er tre forskjellige undersøkelser. Velg prosessen først.

Kontrollene nedenfor forutsetter at meldingen oppstod via en Linux-PAM-integrasjon ved en VPN-innlogging. Hvis den kom fra RADIUS-serverens egen konfigurasjon, er den demonens bevis stedet å begynne.

Navngi prosessen før du navngir pakken

Tre komponenter kalles en modul, og ingen av dem kan byttes ut. En OpenVPN-autentiseringsplugin lastes av VPN-demonen og implementerer den demonens tilbakekallingsgrensesnitt. En PAM-modul er et delt objekt som libpam laster for en navngitt tjeneste, og som implementerer inngangspunkter som pam_sm_authenticate. En FreeRADIUS-modul er en del av den demonens egen konfigurasjon. En melding med de samme ordene kan komme fra alle tre, så det første spørsmålet er hvilken logglinje som produserte den.

Korrelér tidsstempelet for ett mislykket forsøk mellom VPN-loggen og systemets autentiseringslogg, og les deretter linjene før sammendraget. Den konkrete lastermeldingen står som regel allerede der.

Les innlastingsfeilen, deretter inngangspunktet

PAM rapporterer en ukjent modul når den ikke kan laste det valgte delte objektet, eller når det lastede objektet ikke tilbyr funksjonen som den stakkoppføringen krever. Det er forskjellige reparasjoner: den første er et problem med sti, pakking eller ABI, og den andre er et inngangspunkt som ikke stemmer. En auth-linje trenger pam_sm_authenticate mens en kontolinje trenger pam_sm_acct_mgmt, og et bibliotek som bare implementerer én av dem, feiler på den andre, slik dispatcher-koden viser. Å finne filen på disken beviser ingen av delene.

Å ta et bibliotek med lignende navn fra en annen distribusjon eller CPU-arkitektur er ikke en reparasjon, og det kan etterlate en prosess som laster en modul som aldri er testet mot sin libpam. Kontroller pakken som eier den tiltenkte stien, og filens virkelige arkitektur, før du endrer noe.

Behold garantiene stakken ga

Den raskeste måten å stilne denne feilen på er også den verste: å merke en påkrevd modul som valgfri, slette kontofasen, eller sette inn en ubetinget tillatelse. Hver av disse gjør en mislykket kontroll om til en manglende kontroll, og innloggingen lykkes da av grunner ingen hadde tenkt. Nullstilling av passord og endringer av delt hemmelighet gir heller ikke en manglende funksjon, fordi feilen skjer før noen legitimasjonsdata når en backend.

En stakk med flere moduler kan ha kjørt en annen backend før den feilende oppføringen, så feilen beviser ikke at ingen RADIUS-forespørsel ble sendt.

Verifiser innloggingen i stedet for modulen

Når avviket er rettet, test den faktiske adgangsveien. En gyldig konto bør lykkes, ugyldige legitimasjonsdata bør fortsatt feile, og en forbudt konto bør fortsatt avvises. Bekreft også at et krav om sertifikat eller ekstra faktor fortsatt håndheves, fordi en reparert stakk som hopper over en fase ser ut som suksess fra klientens side.

At en modul lastes rent, er fremgang, ikke en fullført test.

Notér hvilket tjenestenavn, hvilke policyfiler og hvilke inngangspunkter som var involvert, sammen med det ene forsøket du brukte som bevis. Den noten gjør neste forekomst til et oppslag i stedet for en arkeologisk øvelse.