Hi,
We are seeing some odd behaviour with 389 compared to what the diagram below suggests (from RHDS Documentation) https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/h...
We have a user with an expired password with no grace logons, that user is unable to change their own password. On bind they receive "Invalid Credentials 49 Additinoal Info: password expired!" which is the same we see when manually trying to change the password (using their account to bind) using ldappasswd as well.
According to the flow diagram we should be expecting 389 to basically force change the password, which incidentally works fine when the passwordexpirytime attribute is set to epoch but not when it is any other value.
My question is basically how should we expect this to work? and how should a user with an expired password be able to change their password without admin assistance.
Thanks James
Just to confirm this is on Centos 6.x using 389-ds-base-1.2.11.15-69.el6_7.x86_64
I have also tried this on CentOS 7 and get the same behaviour using the current version on the EPEL 7 repo
389-users@lists.fedoraproject.org