Я использую аутентификацию Kerberos / LDAP в небольшой сети уже много лет. Kerberos хранится в LDAP, который, в свою очередь, реплицируется на другой сайт. Машины на втором сайте аутентифицируются на реплике, старый сайт аутентифицируется на исходном сервере. Недавно я добавил несколько новых учетных записей пользователей.
На оригинальном сайте все работает гладко. Новые пользователи могут войти в систему без проблем.
На втором сайте с использованием реплики kinit userтоже работает без проблем. Однако login userутверждает, что пароль истек и его необходимо немедленно сменить. После смены пароля пользователь прекрасно входит в систему.
Проверяю настройки на реплике KDC, на kadmin.localмой взгляд, все выглядит хорошо:
kadmin.local: getprinc user
Principal: [email protected]
Expiration date: [never]
Last password change: Di Nov 22 21:06:35 CET 2022
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Di Nov 22 21:06:35 CET 2022 ([email protected])
Last successful authentication: Di Nov 22 21:19:27 CET 2022
Last failed authentication: So Nov 13 09:05:17 CET 2022
Failed password attempts: 0
Number of keys: 8
[ ... ]
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
Таким образом, ни пароли, ни принципалы не истекают. И, таким образом, kinitработает так, как и ожидалось:
root@client:~# kinit user
Password for [email protected]:
root@client:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
22.11.2022 21:25:17 23.11.2022 07:25:17 krbtgt/[email protected]
renew until 23.11.2022 21:25:11
Однако loginутверждается, что пароль устарел и его необходимо сменить:
root@ganesha:~# login user
Password:
Sie müssen Ihr Passwort sofort ändern (Passwortablauf).
Current Kerberos password:
Enter new Kerberos password:
Retype new Kerberos password:
Linux client 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Letzte Anmeldung: Dienstag, den 22. November 2022, 20:59:02 CET auf pts/5
user@client:~$
После этого входа в систему обновляются Last password changeи принципала . не меняется. Он не меняется и после успешного входа. Но он меняется для успешного входа или на исходных клиентах. Это может быть другой проблемой, но это происходит точно так же со старыми пользователями, которые отлично работают на обоих сайтах. Используя Я не могу заметить никакой разницы между старыми и новыми пользователями.Last modifiedLast successful authenticationkinitloginkinitgetprinc
Для loginследующих настроек PAM должны быть эффективны authи accountт. е. настройки по умолчанию для установки Debian:
auth optional pam_faildelay.so delay=3000000
auth requisite pam_nologin.so
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_group.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
Я настроил новый клиент Bullseye, который использует оригинальный Kerberos и LDAP через VPN. Он показывает то же самое поведение. Я сделал некоторую отладку PAM:
Jan 23 21:32:44 psyche login[2861]: pam_krb5(login:auth): user user authenticated as [email protected]
Jan 23 21:32:44 psyche login[2861]: pam_unix(login:account): expired password for user user (password aged)
Jan 23 21:32:53 psyche login[2861]: pam_krb5(login:chauthtok): user user changed Kerberos password
Jan 23 21:32:53 psyche login[2861]: pam_unix(login:session): session opened for user user(uid=10##) by admin(uid=0)
Старые пользователи, которые отлично работают на всех системах, не имеют записи (login:account)и, следовательно, не могут менять пароль, конечно. Так что, похоже, это не связано с репликацией. Еще более странно, что есть системы, где все loginотлично работает для этих пользователей. Я проверил /etc/pam.d/common-account, и это идентично на обеих системах.
Буду признателен за любые идеи о том, что можно проверить.
Спасибо за вашу помощь.
решение1
Фактическая причина не была связана с Kerberos. Неудачные учетные записи были shadowMaxустановлены в LDAP. Хотя я не знал об этой настройке изначально, учетные данные сообщаются как просроченные, даже если shadowLastChangeplus shadowMaxвсе еще отстает от текущей даты. Установка shadowMaxзначения -1 или полное удаление значения устраняет проблему.
Это не совсем объясняет, почему установка на другом объекте, по-видимому, полностью игнорирует значение, но это уже другая история.