My clients are RHEL 6 workstations using sssd, pam and the openldap-client.

I can not reproduce the problem based on the test case provided.

Can you please provide the password settings from cn=config?

passwordGraceLimit
passwordWarning
passwordMustChange
passwordMaxAge

passwordGraceLimit: 0
passwordWarning: 1209600
passwordMustChange: off
passwordMaxAge: 15552000

I still can not reproduce your problem. I always get expired credentials, error 49.

My config:

passwordExp: on
passwordMaxAge: 15552000
passwordGraceLimit: 0
passwordWarning: 1209600
passwordMustChange: off

The steps I took:

# ldapmodify  -D cn=dm -w password
dn: uid=mark,dc=example,dc=com
changetype: modify
replace: userpassword
userpassword: password
# ldapsearch -D cn=dm -w password -xLLL -b "dc=example,dc=com" uid=mark passwordExpirationTime
dn: uid=mark,dc=example,dc=com
passwordExpirationTime: 20180325124849Z
# ldapmodify  -D cn=dm -w password
dn: uid=mark,dc=example,dc=com
changetype: modify
replace: passwordExpirationTime
passwordExpirationTime: 20170925124849Z
# ldapmodify  -D "uid=mark,dc=example,dc=com" -w password
ldap_bind: Invalid credentials (49)
    additional info: password expired!

The only time the server tells the client to reset the password is when "passwordMustChange" is set to "on". In your case it's "off", so I can not explain this behavior unless it is SSSD that's actually enforcing its own password policy. Is freeipa being used? They use their own password policy plugin - fyi.

Can you provide a reproducible testcase using just ldapmodify/ldapsearch?

Can you also run this search so we can see what plugins are installed?

ldapsearch -D "cn=directory manager" -W -xLLL -b "cn=config" objectClass=nsSlapdPlugin nsslapd-pluginEnabled

My workstations are using sssd and pam. Monitoring the /var/log/secure file, I can see the authentication failure from pam_sss. Then there are lines showing the credential as expired. That part seems to be working as I would expect. What should NOT happen is LDAP allowing the password to be changed.

I can't paste the results in for the plugins but the install is a default install with nothing unusual added. Taking the output, grep'ing for ^dn: and passing it to wc -l shows there are 75 plugins

Can you also provide the DS access log snippet showing the bind, and password mod/result?

If sssd/pam binds as Directory Server it will bypass the password policy (fyi)...

I have to fat-finger everything...
conn=687955 op=0 (initial connection with start_tls)
op=1 BIND dn="uid=user1....
op=1 RESULT err=49.....
op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
op=2 RESULT err=0
op=3 UNBIND

We don't put passwords in nslcd.conf or pam_ldap.conf so I don't think it would bypass the policy (but I'm no expert).

@redfearn Can you please provide an example case with ldappasswd and the creation of the account showin the steps that cause the issue on your prouduction environment.

As a curious question, did you set the value of the passwordexpirationtime or gracetime while the server was running live (ie ldapmodify of cn=config)? Or did you stop, edit dse.ldif, start?

@redfarm - any update?

We're going to close this soon as we can not reproduce any problem with the password policy.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2441

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.