El módulo PAM es desconocido: qué proceso falló realmente

Lea esa frase como una afirmación sobre un objeto compartido y un puntero a función, no sobre una contraseña. Las mismas palabras pueden venir de un OpenVPN complemento, de una pila PAM cargada para un servicio o desde dentro del demonio RADIUS, y son tres investigaciones distintas. Primero elija el proceso.

Las comprobaciones siguientes suponen que el mensaje apareció mediante una integración de Linux-PAM en un inicio de sesión VPN. Si vino de la configuración propia del servidor RADIUS, hay que empezar por la evidencia de ese demonio.

Nombre el proceso antes de nombrar el paquete

Tres componentes se llaman módulo y ninguno es intercambiable. Un complemento de autenticación OpenVPN lo carga el demonio VPN e implementa la interfaz de devolución de llamada de ese demonio. Un módulo PAM es un objeto compartido que libpam carga para un servicio con nombre, y que implementa puntos de entrada como pam_sm_authenticate. Un módulo de FreeRADIUS es una pieza de la configuración propia de ese demonio. Un mensaje con las mismas palabras puede venir de cualquiera de los tres, así que la primera pregunta es qué línea de registro lo produjo.

Correlacione la marca de tiempo de un intento fallido entre el registro de VPN y el registro de autenticación del sistema, y después lea las líneas anteriores al resumen. El mensaje concreto del cargador suele estar ya ahí.

Lea el error de carga y luego el punto de entrada

PAM informa de un módulo desconocido cuando no puede cargar el objeto compartido seleccionado o cuando el objeto cargado no proporciona la función que exige esa entrada de la pila. Son reparaciones distintas: la primera es un problema de ruta, empaquetado o ABI, y la segunda es un punto de entrada que no coincide. Una línea de autenticación necesita pam_sm_authenticate mientras que una línea de cuenta necesita pam_sm_acct_mgmt, y una biblioteca que solo implementa una de las dos fallará en la otra, tal como el código del despachador lo muestra. Encontrar el archivo en el disco no demuestra ninguna de las dos cosas.

Tomar una biblioteca con un nombre parecido de otra distribución o arquitectura de CPU no es una reparación, y puede dejar un proceso cargando un módulo que nunca se probó contra su libpam. Compruebe el paquete propietario de la ruta prevista y la arquitectura real del archivo antes de cambiar nada.

Mantenga las garantías que ofrecía la pila

La forma más rápida de silenciar este error es también la peor: marcar como opcional un módulo obligatorio, eliminar la etapa de cuenta, o insertar un permiso incondicional. Cada una convierte una comprobación fallida en una comprobación ausente, y el inicio de sesión pasa entonces por motivos que nadie pretendía. Restablecer contraseñas y cambiar secretos compartidos tampoco aportan la función que falta, porque el fallo ocurre antes de que ninguna credencial llegue a un servicio de fondo.

Una pila de varios módulos puede haber ejecutado otro servicio de fondo antes de la entrada fallida, así que el error no demuestra que no se enviara ninguna petición RADIUS.

Verifique el inicio de sesión, no el módulo

Una vez corregida la discrepancia, pruebe la ruta real de admisión. Una cuenta válida debería pasar, las credenciales no válidas deberían seguir fallando y una cuenta prohibida debería seguir siendo rechazada. Confirme también que cualquier requisito de certificado o factor adicional sigue aplicándose, porque una pila reparada que se salta una etapa parece un éxito desde el lado del cliente.

Que un módulo se cargue limpiamente es un avance, no una prueba terminada.

Anote qué nombre de servicio, qué archivos de política y qué puntos de entrada intervinieron, junto con el único intento que usó como evidencia. Ese registro es lo que convierte la próxima aparición en una consulta y no en un ejercicio de arqueología.