LDAP com SSSD: forçar usuário a alterar a senha - 'ShadowLastChange' não está funcionando

Question

Eu tenho o CentOS6, com autenticação de usuário LDAP, usando o OpenLDAP e o SSSD. Estou tentando forçar o usuário a alterar a senha. De acordo com esta pergunta sobre ServerFault , tentei definir ShadowLastChange para 0 , mas parece ser ignorado quando o usuário logou com o SSH.

Naquela pergunta, há um aviso de que ele pode causar um bug de um loop infinito de solicitações de mudança de senha, mas eu nem recebi um único pedido ...

Houve outra sugestão nessa pergunta,

Try passwordMustChange attribute

Mas quando tento usá-lo no meu arquivo .ldif , recebo um erro Undefined attribute type (17)

Eu também tentei usar o passwd -e username no usuário local do Unix, apenas para verificar se ele está funcionando, e sim - que o usuário local foi forçado a alterar a senha no login do SSH.

EDITAR

Encontrei a sobreposição de Password Policies no documento do OpenLDAP . Deve ajudar? (se sim - é a única maneira de resolver meu problema?)

EDIT2

Password Policies não parece ajudar também.

EDIT3

A.

Na verdade, a Política de Senha está funcionando. Primeiro tentei verificar com sugestão de suporte hp - mas o ppolicy não foi exibido na arquivo de log.

Mas, depois, descobri uma boa maneira de verificar a Política - defina pwdAllowUserChange para FALSE e veja se o usuário não pode alterar a senha com passwd , com uma mensagem de erro do servidor. Ou altere pwdMaxAge para 1 , faça login e veja se o usuário recebe uma solicitação de mudança de senha.

No entanto, pwdMustChange: TRUE ainda não ajuda. Depois de alterar a senha do usuário (com o cliente JXplorer ou do shell Unix ldapmodify ), o usuário não recebe a notificação de alteração de senha.

Talvez eu não esteja definindo a senha como esperado? No slapo-ppolicy eles dizem

pwdMustChange

   This  attribute  specifies  whether  users must change their passwords when
   they first bind to the directory after a password is set or  reset  by  the
   administrator,  or not.  If pwdMustChange has a value of "TRUE", users must
   change their passwords when they first bind to the directory after a  pass-
   word  is  set  or  reset  by  the  administrator. 

Parece haver uma diferença entre set e reset a senha. Eu tentei set . Talvez reset me ajudasse. Como posso redefinir uma senha?

Aqui está minha política:

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

B.

(Em resposta às perguntas de Cameron Kerr nos comentários)

É o CentOS 6.6. E estes são meus arquivos /etc/pam.d/system-auth*:

# cat  /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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

EDIT4

OK, descobri que, se eu definir pwdReset:TRUE na entrada do usuário, ele precisará alterar a senha no login. Eu acho que isso depende do pwdMustChange: TRUE da PPolicy.

Está funcionando, mas não entendo porque é a única solução que pude encontrar. (e uma solução que o Google não conseguiu me encontrar!) Além disso, é estranho que essa mudança deva ser feita com ldapmodify - o JXplorer nem sequer me mostrou esse atributo antes de eu alterá-lo ...