Модуль PAM неизвестен: какой процесс на самом деле отказал

Читайте эту фразу как утверждение о разделяемом объекте и указателе на функцию, а не о пароле. Те же слова могут прийти из OpenVPN плагина, из стека PAM, загруженного для одной службы, или изнутри демона RADIUS, и это три разных расследования. Сначала определите процесс.

Проверки ниже предполагают, что сообщение появилось через интеграцию Linux-PAM при входе в VPN. Если оно пришло из собственной конфигурации сервера RADIUS, начинайте с доказательств этого демона.

Назовите процесс, прежде чем называть пакет

Три компонента называют модулем, и ни один из них не взаимозаменяем. Плагин аутентификации OpenVPN загружается демоном VPN и реализует интерфейс обратного вызова этого демона. Модуль PAM — это разделяемый объект, который libpam загружает для именованной службы, и который реализует точки входа вроде pam_sm_authenticate. Модуль FreeRADIUS — часть собственной конфигурации этого демона. Сообщение с теми же словами может прийти от любого из трёх, поэтому первый вопрос — какая строка журнала его создала.

Сопоставьте отметку времени одной неудачной попытки в журнале VPN и в системном журнале аутентификации, затем прочитайте строки перед сводкой. Конкретное сообщение загрузчика обычно уже там.

Прочитайте ошибку загрузки, затем точку входа

PAM сообщает о неизвестном модуле, когда не может загрузить выбранный разделяемый объект или когда загруженный объект не предоставляет функцию, которую требует эта запись стека. Это разные исправления: первое — проблема пути, упаковки или ABI, второе — несовпадающая точка входа. Строке аутентификации нужен pam_sm_authenticate а строке учётной записи нужен pam_sm_acct_mgmt, и библиотека, реализующая только один из них, откажет на другом, как код диспетчера показывает. Нахождение файла на диске не доказывает ни то, ни другое.

Взять библиотеку с похожим именем из другого дистрибутива или архитектуры процессора — не исправление, и это может оставить процесс загружающим модуль, никогда не проверявшийся с его libpam. Проверьте пакет, которому принадлежит нужный путь, и реальную архитектуру файла, прежде чем что-либо менять.

Сохраните гарантии, которые давал стек

Самый быстрый способ заглушить эту ошибку — одновременно и худший: пометить обязательный модуль как необязательный, удалить этап учётной записи, или вставить безусловное разрешение. Каждое из этого превращает неудачную проверку в отсутствующую, и вход затем удаётся по причинам, которых никто не планировал. Сброс паролей и смена общего секрета тоже не дают отсутствующую функцию, потому что сбой происходит раньше, чем какие-либо учётные данные достигнут бэкенда.

Стек из нескольких модулей мог запустить другой бэкенд до сбойной записи, поэтому ошибка не доказывает, что запрос RADIUS не отправлялся.

Проверяйте вход, а не модуль

После исправления несоответствия проверьте реальный путь допуска. Действительная учётная запись должна пройти, неверные учётные данные должны по-прежнему не проходить, а запрещённая учётная запись должна по-прежнему отклоняться. Убедитесь также, что требование сертификата или дополнительного фактора всё ещё применяется, потому что исправленный стек, пропускающий этап, со стороны клиента выглядит как успех.

Чистая загрузка модуля — это прогресс, а не завершённый тест.

Запишите, какое имя службы, какие файлы политики и какие точки входа были задействованы, вместе с единственной попыткой, которую вы использовали как доказательство. Именно эта запись делает следующий случай поиском, а не археологическим упражнением.