PAM Module Is Unknown: Which Process Actually Failed

Read that phrase as a statement about a shared object and a function pointer, not about a password. The same words can come from an OpenVPN plugin, from a PAM stack loaded for one service, or from inside the RADIUS daemon, and those are three different investigations. Pick the process first.

The checks below assume the message surfaced through a Linux-PAM integration on a VPN login. If it came from the RADIUS server's own configuration, that daemon's evidence is the place to start.

Name the process before naming the package

Three components get called a module and none of them is interchangeable. An OpenVPN authentication plugin is loaded by the VPN daemon and implements that daemon's callback interface. A PAM module is a shared object loaded by libpam for a named service, implementing entry points such as pam_sm_authenticate. A FreeRADIUS module is a piece of that daemon's own configuration. A message with the same words can come from any of the three, so the first question is which log line produced it.

Correlate the timestamp of one failed attempt across the VPN log and the system authentication log, then read the lines before the summary. The specific loader message is usually already there.

Read the loading error, then the entry point

PAM reports an unknown module when it cannot load the selected shared object, or when the loaded object does not provide the function that stack entry requires. Those are different repairs: the first is a path, packaging or ABI problem, and the second is a mismatched entry point. An auth line needs pam_sm_authenticate while an account line needs pam_sm_acct_mgmt, and a library implementing only one of them will fail the other, as the dispatcher code shows. Finding the file on disk proves neither.

Taking a library with a similar name from a different distribution or CPU architecture is not a repair, and it can leave a process loading a module that was never tested against its libpam. Check the package that owns the intended path and the file's real architecture before changing anything.

Keep the guarantees the stack was making

The fastest way to silence this error is also the worst: mark a required module optional, delete the account stage, or insert an unconditional permit. Each of those converts a failed check into an absent check, and the login then succeeds for reasons nobody intended. Password resets and shared-secret changes do not supply a missing function either, because the failure happens before any credential reaches a backend.

A multi-module stack may have run another backend before the failing entry, so the error does not prove that no RADIUS request was sent.

Verify the login rather than the module

Once the mismatch is corrected, test the actual admission path. A valid account should succeed, invalid credentials should still fail, and a forbidden account should still be refused. Confirm as well that any certificate or additional-factor requirement is still enforced, because a repaired stack that skips a stage looks like success from the client's side.

A module loading cleanly is progress, not a finished test.

Record which service name, which policy files and which entry points were involved, along with the single attempt you used as evidence. That record is what makes the next occurrence a lookup instead of an archaeology exercise.