Changing the expired password fails

Bug
,
1

While fixing a #bug of password expiration policy with OpenLDAP local accounts provider, a new issue was found:

  1. User has an expired password – see Effects of expired passwords
  2. User connects to /user-settings page to change their password but it does not work. Services based on PAM (like IMAP) are not accessible.

Possible approaches:

A. WONTFIX: Password expiration with OpenLDAP is rarely used, we can live with this limitation. Users with expired passwords call and get a new password from the sysadmin.

B. REMOVE the feature completely starting from NS 7.10. The Password policy is removed from the UI, LDAP shadow* attributes are no longer enforced also in existing systems, which are forcibly migrated to a non-expiring password policy.

C. IMPLEMENT an alternative. New systems will be based on the new implementation. Old systems retain the current behavior. A manual migration path would be useful.

After a brief discussion with @giacomo and @nrauso, we found approach B is a good compromise:

  • A is a time-bomb, as it leaves the door open to sudden service lockouts
  • C is optimal but it seems it is not worth the effort for a feature that is rarely used

What do you think?

More information

4 Likes
3

IMHO it is reasonable to remove it from OpenLDAP.
My motive is: windows clients can’t setup single-sign-on against OpenLDAP. This does not encourage people to configure it in the first place.

2 Likes
4

@davidep can the user which binds OpenLDAP and the NethServer management tool override the expired password?

5

The user can change their own password with the LDAPv3 modify password operation.

However Cockpit, SSH and other PAM based clients which implement the password changing form, rely on SSSD for that operation.

It seems SSSD as it is configured in NS 7 can’t update the LDAP shadow attributes properly :frowning: