PAM принимает любой пароль для действительных пользователей
Я только что подключил свою рабочую станцию Arch Linux к Samba AD, которую я настроил для нашей компании. Я протестировал его, и он работал, по крайней мере, я так думал. Он принял мой пароль, создал мой домашний адрес и все остальное и вошел в систему. Я забыл проверить то, что он не примет . Оказывается, пока имя пользователя действительное (AD или локальное, не имеет значения), он будет принимать любой пароль. Может ли кто-нибудь указать мне, что я сделал не так?
Я использую SSSD для управления подключением AD. Вот мой /etc/pam.d/system-auth :
#%PAM-1.0
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_env.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
Давайте подробно проанализируем раздел аутентификации вашей конфигурации PAM.
auth sufficient pam_unix.so nullok try_first_pass
В первой строке говорится: «Если этот тест прошел успешно, прекратите проверку и примите логин; если он не удастся, продолжайте проверку. Проверьте пользователей / пароли, настроенные в / etc / passwd и / etc / shadow . Если пользователь существует, а поле пароля пусто, пользователю разрешен вход. " Это проверка аутентификации для учетных записей локальных пользователей.
auth requisite pam_succeed_if.so uid >= 500 quiet
Во второй строке говорится: «Если этот тест завершится неудачно, прекратите проверку и отклоните вход в систему; в случае успеха продолжайте проверку. Значение UID пользователя должно быть 500 или больше». Это предотвращает вход в системные учетные записи с использованием паролей в AD или другой общей базе данных пользователей.
auth sufficient pam_sss.so use_first_pass
В третьей строке говорится: «Если этот тест прошел успешно, прекратите дальнейшие проверки и примите вход в систему; если это не удается, продолжайте проверку. Проверьте с помощью SSSD. . " Это проверка учетных записей AD.
auth required pam_env.so
В четвертой строке говорится: «Если эта строка не работает, отклоните вход в систему; но в любом случае продолжайте проверять до конца этого раздела.Задайте любые переменные среды, описанные в /etc/security/pam_env.conf и / или / etc / environment . "
Теперь подумайте, что произойдет, если пользователь существует (либо в AD или в локальном / etc / passwd ), но проверка пароля не выполняется. Во-первых, происходит сбой pam_unix.so ; но это не может вызвать отказ, потому что это помешает вам использовать любые AD на основе учетных записей пользователей.
Итак, процесс переходит ко второй строке. Если у пользователя есть действительное сопоставление UID и номер UID равен 500 или больше, это тоже будет успешным. UID был меньше 500.
Третья строка выполняет проверку AD; это тоже не удается. Но опять же, "достаточно" используется, чтобы разрешить настройку любых других методов аутентификации после этого, поэтому процесс продолжается, как и с pam_unix.so .
На этом этапе четвертая строка должна быть успешно выполнена, чтобы позволить пользователю войти. Но это просто установка переменной среды es. man pam_env сообщает мне, что модуль pam_env.so вернет значение PAM_SUCCESS, если переменные среды были успешно установлены. Но поскольку это последний модуль PAM в этом стеке, и ни один из других модулей до сих пор не подвергался абсолютному отклонению, результат этого модуля станет общим результатом фазы аутентификации.
Чтобы исправьте это, на этапе аутентификации в самом конце требуется pam_deny.so , чтобы остановить любые попытки входа в систему, когда все действующие механизмы аутентификации не смогли принять пользователя.
Кроме того, pam_env.so , вероятно, должно произойти раньше в процессе, чтобы инициализация переменной среды происходила одинаково для всех допустимых пользователей. Если это не работает в начале фазы auth , тогда pam_env.so , вероятно, следует вместо этого перейти в фазу сеанса ; man pam_env говорит, что он будет работать либо на фазах auth , либо на session .
Итак, моим первоначальным предложением было бы изменить auth ] вашей конфигурации PAM на это:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth requisite pam_deny.so
Итак, функциональные возможности будут следующими:
- Установить переменные среды для пользователя. Если это не удается, все равно что-то серьезно не так.
- Проверьте локальный пароль; в случае успеха, примите логин и завершите этот этап.
- Отклонить всех пользователей с UID менее 500 на этом этапе (= нет входа в систему с учетной записью root или системы с учетной записью AD!)
- Проверьте пароль в AD; в случае успеха примите логин и завершите этот этап.
- Если мы дойдем до этого момента, ни один из реальных механизмов аутентификации не принял пароль, поэтому безоговорочно отклоните попытку входа в систему.
Если окажется, что pam_env .so вызывает проблемы при размещении в начале фазы auth , вы можете попробовать просто закомментировать его; похоже, что раньше он пропускался при любом действительном входе в систему.
Как всегда при изменении конфигурации PAM, сначала откройте сеанс в системе и убедитесь, что он sudo имеет права root или иным образом имеет полные привилегии root доступно: затем создайте резервную копию текущей конфигурации. Внесите изменение , но не выходите из системы , чтобы проверить его: вместо этого проверьте его, открыв другой сеанс. Если это не удается, у вас все еще есть вход в исходный сеанс, поэтому вы можете легко восстановить старую конфигурацию при необходимости. Если это производственная система или другая критическая система, откройте два корневых сеанса перед внесением изменений, просто чтобы защитить себя от ошибок «пальцы быстрее, чем мозг».