Когда пользователь вводит пароль в login, в su, при подключении по SSH или при разблокировке экрана - решение пускать или нет принимает не сама программа, а отдельный механизм PAM. Задача администратора: настроить единые правила проверки пароля, блокировки после неудачных попыток и ограничений на вход, а в больших инфраструктурах - подключить машины к централизованному каталогу (LDAP, Active Directory) через SSSD, чтобы учётки не размазывались по сотням серверов. В этом уроке разберём, как устроен стек PAM, что значат типы и control-флаги, и как SSSD кеширует и связывает Linux с доменом.
Как это работает
PAM (Pluggable Authentication Modules) - это прослойка между приложением и механизмами проверки. Программа собрана с libpam и не знает, как именно проверяется пароль: она просто говорит PAM провести аутентификацию для сервиса с таким-то именем. PAM смотрит в файл /etc/pam.d/<имя сервиса> и выполняет перечисленные там модули по порядку. Это и есть смысл слова pluggable: правила меняются редактированием текста, без перекомпиляции программ.
Каждая строка конфигурации описывает четыре вещи: тип (для какой фазы), control-флаг (как трактовать результат модуля), сам модуль (.so файл) и его аргументы. Типов четыре. auth проверяет, кто ты (пароль, ключ, токен). account решает, разрешён ли вход вообще (не истёк ли аккаунт, не запрещено ли время суток). password управляет сменой пароля. session готовит и закрывает сессию (монтирует домашний каталог, пишет в лог, ставит лимиты).
Модули одного типа выстраиваются в стек и выполняются сверху вниз. Control-флаг говорит, что делать с вердиктом каждого. required - модуль обязан пройти, но стек идёт дальше до конца (чтобы не подсказывать злоумышленнику, где именно сорвалось). requisite - то же, но при провале выходим немедленно. sufficient - если прошёл и до него никто не провалился, успех сразу, остальное не смотрим. optional - результат влияет, только если это единственный модуль типа. Есть и развёрнутый синтаксис в квадратных скобках вида [success=done new_authtok_reqd=ok default=die], где для каждого кода ответа задаётся действие - именно его используют include-стеки современных дистрибутивов.
Чтобы не дублировать правила в каждом сервисе, применяют подключаемые наборы. В Debian и Ubuntu это common-auth, common-account, common-password, common-session, которые тянутся директивой @include, а собирает их утилита pam-auth-update. В RHEL, Fedora и подобных это system-auth и password-auth, подключаемые через include или substack, а генерирует их authselect (пришёл на смену старому authconfig). Не правьте сгенерированные файлы руками - меняйте профиль authselect, иначе перезапись затрёт ваши изменения.
SSSD (System Security Services Daemon) решает другую задачу - откуда брать пользователей и группы, если их нет в /etc/passwd. Он работает как кеширующий посредник между системой и сетевым каталогом. Для NSS (резолв имён и групп) подключается через nss_sss в /etc/nsswitch.conf, для аутентификации - через модуль pam_sss.so в стеке PAM. Главный плюс перед старым прямым подключением nss_ldap и pam_ldap - локальный кеш: учётка, однажды проверенная, какое-то время работает даже при недоступном сервере (offline-вход), что критично для ноутбуков и филиалов.
Конфигурация SSSD живёт в /etc/sssd/sssd.conf (права обязаны быть 600, иначе демон не стартует). Файл делится на секции. Секция [sssd] перечисляет активные домены и службы. Секция [domain/ИМЯ] описывает конкретный источник: id_provider (откуда брать идентичность - ldap, ad, ipa), auth_provider (чем проверять пароль), параметры подключения, базовый DN, фильтры. SSSD умеет напрямую вступать в Active Directory (id_provider = ad) с учётом групп, Kerberos-билетов и доверий, а связку realmd join + SSSD сегодня используют как стандартный способ ввести Linux в домен Windows.
Команды и примеры
Типичный стек auth в /etc/pam.d/ - модуль блокировки после неудачных попыток pam_faillock (заменил устаревший pam_tally2):
Код: Выделить всё
auth required pam_faillock.so preauth silent deny=5 unlock_time=900
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900
account required pam_faillock.so
account required pam_unix.so
Код: Выделить всё
faillock --user alice # показать неудачные входы
faillock --user alice --reset # обнулить блокировку
Код: Выделить всё
pam-auth-update # интерактивно включить/выключить профили (mkhomedir, sss, ...)
pam-auth-update --enable mkhomedir
Код: Выделить всё
authselect list # доступные профили
authselect select sssd with-mkhomedir # профиль sssd + создание домашних каталогов
authselect current # что выбрано сейчас
Код: Выделить всё
[sssd]
services = nss, pam
domains = LDAP
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = demand
cache_credentials = true
enumerate = false
Код: Выделить всё
realm discover example.com # что за домен, какие пакеты нужны
realm join -U administrator example.com
realm list # статус членства
Код: Выделить всё
getent passwd alice@example.com
sss_cache -E # пометить кеш как протухший
systemctl restart sssd
- Правка файла без бэкапа: одна ошибка в pam.d может закрыть вход всем, включая root. Держите открытым второй root-сеанс и проверяйте, не закрывая первый.
- sufficient до pam_unix в auth: если такой модуль ошибочно всегда возвращает успех, он пускает кого угодно - порядок строк критичен.
- Права на /etc/sssd/sssd.conf не 600 (или владелец не root) - демон молча не стартует, смотрите journalctl -u sssd.
- Ручная правка system-auth или common-auth: authselect и pam-auth-update перезапишут файл при следующем обновлении профиля.
- enumerate = true на большом каталоге вешает getent и грузит сервер - в проде держите enumerate = false.
- pam_tally2 и pam_cracklib в гайдах - это легаси; в 2026 это pam_faillock и pam_pwquality.
- Кеш SSSD хранит старое - после изменений на сервере чистите sss_cache -E, иначе видите устаревшие данные.
- Сделайте копию /etc/pam.d/sshd (или common-auth) и откройте второй root-сеанс на всякий случай.
- Добавьте в стек auth модуль pam_faillock с deny=3 unlock_time=120.
- Трижды войдите с неверным паролем тестового пользователя, затем посмотрите faillock --user тест.
- Дождитесь разблокировки или сбросьте её через faillock --user тест --reset.
- Включите автосоздание домашних каталогов: authselect select ... with-mkhomedir или pam-auth-update --enable mkhomedir.
- Напишите минимальный sssd.conf с id_provider = ldap, выставьте права 600 и запустите демон, проверьте логи journalctl -u sssd.
- Проверьте резолв учётки командой getent passwd <user> и очистите кеш sss_cache -E.
- Чем отличается control-флаг required от requisite и в каком случае стек прерывается немедленно?
- Какой тип PAM отвечает за проверку срока действия аккаунта, а какой - за смену пароля?
- Почему файл system-auth не редактируют вручную и какая утилита им управляет в RHEL?
- Что даёт параметр cache_credentials в sssd.conf и для каких сценариев он важен?
- Какие права обязан иметь /etc/sssd/sssd.conf и что произойдёт при их нарушении?
- Чем pam_faillock лучше устаревшего pam_tally2 и как сбросить счётчик блокировок?
