PAM-modulet er ukendt: hvilken proces fejlede egentlig

Læs denne sætning som en udtalelse om et delt objekt og en funktionsmarkør, ikke om en adgangskode. De samme ord kan komme fra et OpenVPN plugin, fra en PAM-stak indlæst til én tjeneste eller indefra RADIUS-dæmonen, og det er tre forskellige undersøgelser. Vælg processen først.

Kontrollerne nedenfor forudsætter, at beskeden opstod via en Linux-PAM-integration ved et VPN-login. Hvis den kom fra RADIUS-serverens egen konfiguration, er den dæmons beviser stedet at begynde.

Navngiv processen, før du navngiver pakken

Tre komponenter kaldes et modul, og ingen af dem kan udskiftes. Et OpenVPN-godkendelsesplugin indlæses af VPN-dæmonen og implementerer den dæmons callback-grænseflade. Et PAM-modul er et delt objekt, som libpam indlæser for en navngivet tjeneste, og som implementerer indgangspunkter som pam_sm_authenticate. Et FreeRADIUS-modul er en del af den dæmons egen konfiguration. En besked med de samme ord kan komme fra alle tre, så det første spørgsmål er, hvilken loglinje der frembragte den.

Korrelér tidsstemplet for ét mislykket forsøg på tværs af VPN-loggen og systemets godkendelseslog, og læs derefter linjerne før opsummeringen. Den konkrete indlæserbesked er som regel allerede der.

Læs indlæsningsfejlen, derefter indgangspunktet

PAM rapporterer et ukendt modul, når det ikke kan indlæse det valgte delte objekt, eller når det indlæste objekt ikke leverer den funktion, som den stakpost kræver. Det er forskellige reparationer: den første er et problem med sti, pakning eller ABI, og den anden er et indgangspunkt, der ikke stemmer. En auth-linje har brug for pam_sm_authenticate mens en kontolinje har brug for pam_sm_acct_mgmt, og et bibliotek, der kun implementerer én af dem, fejler på den anden, som dispatcher-koden viser. At finde filen på disken beviser ingen af delene.

At tage et bibliotek med et lignende navn fra en anden distribution eller CPU-arkitektur er ikke en reparation, og det kan efterlade en proces, der indlæser et modul, som aldrig er testet mod dens libpam. Kontroller pakken, der ejer den tilsigtede sti, og filens reelle arkitektur, før du ændrer noget.

Bevar de garantier, stakken gav

Den hurtigste måde at bringe denne fejl til tavshed på er også den værste: at markere et påkrævet modul som valgfrit, slette kontofasen, eller indsætte en ubetinget tilladelse. Hver af disse gør en mislykket kontrol til en manglende kontrol, og login lykkes derefter af grunde, ingen havde til hensigt. Nulstilling af adgangskoder og ændringer af delte hemmeligheder leverer heller ikke en manglende funktion, fordi fejlen sker, før nogen legitimationsoplysning når en backend.

En stak med flere moduler kan have kørt en anden backend før den fejlende post, så fejlen beviser ikke, at ingen RADIUS-anmodning blev sendt.

Verificér loginet i stedet for modulet

Når uoverensstemmelsen er rettet, skal du teste den faktiske adgangsvej. En gyldig konto bør lykkes, ugyldige legitimationsoplysninger bør stadig fejle, og en forbudt konto bør stadig afvises. Bekræft også, at ethvert krav om certifikat eller ekstra faktor stadig håndhæves, fordi en repareret stak, der springer en fase over, ser ud som succes fra klientens side.

At et modul indlæses rent er fremskridt, ikke en afsluttet test.

Notér hvilket tjenestenavn, hvilke politikfiler og hvilke indgangspunkter der var involveret, sammen med det ene forsøg, du brugte som bevis. Den note gør den næste forekomst til et opslag i stedet for en arkæologisk øvelse.