У меня CentOS6 с аутентификацией пользователей через LDAP, использующий OpenLDAP и SSSD. Я пытаюсь заставить пользователя изменить пароль. В соответствии с этим вопросом на ServerFault я попытался установить ShadowLastChange на 0, но, казалось, это просто игнорируется, когда пользователь входил в систему через SSH.

В этом вопросе есть предупреждение, что это может вызвать баг с бесконечным циклом запросов на изменение пароля, но я не получил ни одного запроса…

Вопрос содержал другое предложение,

Попробуйте атрибут passwordMustChange

Но когда я пытаюсь использовать его в своем .ldif файле, я получаю ошибку Неопределенный тип атрибута (17).

Я также пытался использовать passwd -e username для локального Unix-пользователя, просто чтобы убедиться, что это работает, и да – этот локальный пользователь был вынужден изменить пароль при входе через SSH.

ИЗМЕНЕНИЕ

Я нашел наложение Политики паролей в документации OpenLDAP. Это должно помочь? (если да – это единственный способ решить мою проблему?)

ИЗМЕНЕНИЕ2

Политики паролей также, похоже, не помогают.

ИЗМЕНЕНИЕ3

А.

На самом деле, Политика паролей работает. Сначала я пытался проверить это, воспользовавшись предложениями поддержки HP – но ppolicy не отображалась в лог-файле.

Но затем я нашел хороший способ проверить Политику – установить pwdAllowUserChange в FALSE, и увидеть, что пользователь не может изменить пароль с помощью passwd, с сообщением об ошибке от сервера. Или изменить pwdMaxAge на 1, войти в систему и увидеть, что пользователю предлагается изменить пароль.

Тем не менее, pwdMustChange: TRUE все еще не помогает. После того как я изменил пароль пользователя (либо с помощью клиента JXplorer, либо из оболочки Unix ldapmodify), пользователю не приходит уведомление о необходимости изменить пароль.

Может быть, я не устанавливаю пароль, как ожидалось? В slapo-ppolicy говорится

pwdMustChange

   Этот атрибут указывает, должны ли пользователи менять свои пароли, когда
   они впервые связываются с каталогом после того, как пароль был установлен или 
   сброшен администратором, или нет. Если pwdMustChange имеет значение "TRUE", 
   пользователи должны менять свои пароли, когда они впервые связываются с 
   каталогом после установки или сброса пароля администратором.

Похоже, есть разница между установить и сбросить пароль. Я пытался установить. Может быть, сбросить поможет мне. Как я могу сбросить пароль?

Вот моя политика:

dn: cn=default,ou=policies,dc=***,dc=com
cn: default
objectClass: pwdPolicy
objectClass: person
objectClass: top
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdExpireWarning: 604800
pwdFailureCountInterval: 30
pwdInHistory: 2
pwdLockout: TRUE
pwdLockoutDuration: 172800
pwdMinAge: 0
pwdMinLength: 6
pwdMustChange: TRUE
pwdSafeModify: FALSE
sn: dummy value
pwdAllowUserChange: FALSE
pwdGraceAuthNLimit: 0
pwdMaxFailure: 5
pwdMaxAge: 999999

Б.

(В ответ на вопросы Кэмерона Керра в комментариях)

Это CentOS 6.6. А вот мои файлы /etc/pam.d/system-auth*:

# cat  /etc/pam.d/system-auth
#%PAM-1.0
# Этот файл создается автоматически.
# Изменения пользователей будут удалены в следующий раз при запуске authconfig.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.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        required      pam_deny.so

account     required      pam_unix.so broken_shadow
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    requisite     pam_cracklib.so try_first_pass retry=3 type=
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_oddjob_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

# cat  /etc/pam.d/system-auth-ac
#%PAM-1.0
# Этот файл создается автоматически.
# Изменения пользователей будут удалены в следующий раз при запуске authconfig.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.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        required      pam_deny.so

account     required      pam_unix.so broken_shadow
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    requisite     pam_cracklib.so try_first_pass retry=3 type=
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_oddjob_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

ИЗМЕНЕНИЕ4

Хорошо, я обнаружил, что если я установлю pwdReset:TRUE в записи пользователя, он будет вынужден изменить пароль при входе в систему. Я думаю, что это зависит от pwdMustChange: TRUE в Политике паролей.

Это работает, но я не понимаю, почему это единственное решение, которое я мог найти. (и решение, которое Google не смог мне найти!) Более того, странно, что это изменение должно быть сделано с помощью ldapmodify – JXplorer даже не показывала мне этот атрибут до того, как я его изменил…

Убедитесь, что атрибуты политики пароля LDAP и атрибуты shadowAccount согласованы (как предварительное условие). Похоже, что sssd не заботится о атрибутах shadowAccount, и ваш maxAge в 99999 соответствует 11,5 дням (примерно).