Using padlock does not set pwdAccountLockedTime and setting pwdAccountLockedTime removes padlock

Description

Using the padlock symbol does not set pwdAccountLockedTime of ppolicy. Setting pwdAccountLockedTime manually via ldif file removes padlock (if padlock was set before).

If setting pwdAccountLockedTime manually via ldif file no padlock is set automatically and if setting the padlock afterwards will remove the previously set pwdAccountLockedTime attribute.

Distribution Name and Version

Debian Jessie

FusionDirectory Version

1.2.1 wit ppolicy overlay

PHP version used

Distribution packages Debian Jessie

Origin of php packages

Distribution packages

Steps to Reproduce

(four different cases)

1. case: Set padlock via browser
2. case: Set pwdAccountLockedTime manually
3. case: Set pwdAccountLockedTime manually and padlock afterwards
4. case: Set pwdAccountLockedTime manually and padlock before

Expected behavior:

1. case: pwdAccountLockedTime is set
2. case: padlock and pwdAccountLockedTime are set
3. case: padlock and pwdAccountLockedTime are set
4. case: padlock and pwdAccountLockedTime are set

Actual behavior:

1. case: pwdAccountLockedTime is NOT set, but padlock is
2. case: pwdAccountLockedTime is set, but padlock is NOT
3. case: padlock is set but cleans/deletes pwdAccountLockedTime
4. case: padlock is not set anymore, but pwdAccountLockedTime is

Reproduces how often: 100% (10/10)

assigned to @MCMic

changed milestone to %FusionDirectory 1.3

FusionDirectory locking feature is not related to ppolicy.

That said, as locking performs a password change it’s not surprising the ppolicy overlay may react in some way.

From what I know pwdAccountLockedTime is an operational attribute and cannot be set except to reset it to empty, in which case would it be manually set?

added 30m of time spent at 2018-09-03

If an account is not locked you will not find the attribute even by querying it directly or with the "+" for operational attributes (at least not on my server). Currently I've to set the attribute manually to really lock an account on ldap level (sometimes there is a need for doing so). On my fusion directory installation this is the only way to lock the account and get this info shown under dashboard and locked accounts (e.g. ppolicy tab). I've no idea where fusion directory retrieves its info from when using the padlock, since using the padlock will not trigger pwdAccountLockedTime.

changed milestone to %FusionDirectory 1.4

changed due date to July 15, 2019

So https://tools.ietf.org/id/draft-behera-ldap-password-policy-10.txt states that pwdAccountLockedTime can be set to 000001010000Z to lock an account, and it seems to work.

So we can start by doing this when an account is locked by FD.

The other way around I do not see how FD would be able to react to ppolicy manual locking, and we generally do not support this kind of things.

added 1h 30m of time spent at 2019-07-22

hello @MCMic,

i agree lets start with that

Cheers

added 5m of time spent at 2019-07-22

changed due date to July 15, 2019

changed milestone to %FusionDirectory 1.4

mentioned in commit 6671d01b

added 1h of time spent at 2019-07-23