Модуль 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 не надсилався.

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

Після виправлення невідповідності перевірте реальний шлях допуску. Чинний обліковий запис має пройти, неправильні облікові дані мають і далі не проходити, а заборонений запис має й далі відхилятися. Переконайтеся також, що вимога сертифіката або додаткового фактора все ще застосовується, бо виправлений стек, який пропускає етап, з боку клієнта виглядає як успіх.

Чисте завантаження модуля — це прогрес, а не завершений тест.

Запишіть, яка назва служби, які файли політики та які точки входу були задіяні, разом з єдиною спробою, яку ви використали як доказ. Саме цей запис робить наступний випадок пошуком, а не археологічною вправою.