Possibility to block an account (different that locking)

[coudot]

We would like to manage two different status for an account:

• Lock: the password is locked, but a user can still reset its password (for OpenLDAP, it is linked to pwdAccountLockedTime)
• Block: the account is no more useable, even if the password is still valid (for OpenLDAP, it is linked to pwdEndTime)

[davidcoutadeur]

+1

I think we should also find a way to implement pwdStartTime / pwdEndTime fields in addition to this button.

[coudot]

I will do a first proposal of UI and we will discuss in the PR.

[coudot]

Implementing pwdStartDate / pwdEndDate will solve a part of #57

With AD support (#156) I implemented the enable/disable account feature, which is specific to AD. AD also have an account expiration date (accountExpires) which is close to what is pwdEndTime.

So to be accurate, we could "expire" an account by updating pwdEndTime/accountExpires, and we can disable an account in AD (a specific bit in userAccountControl).

We need to agree on what blocking means, is it an account expiration (different from password expiration), or an account which is disabled (but we don't have a standard way to do this in OpenLDAP).

[davidcoutadeur]

AFAIK:

• a blocked account is just a generic term meaning that an account can't bind any more. The bind must return an error.
• an expired account is a special case of blocked account where the account has been locked by a period of validity of the account (pwdStartTime / pwdEndTime for OpenLDAP)
• an expired password is a special case of blocked account where the account has been locked by an expired password. (pwdAccountLockedTime for OpenLDAP)

OpenLDAP is defining a special value for pwdAccountLockedTime to implement the generic block account feature.

If we need a completely independent blocking account feature (other than expired account or expired password), today we don't have it and we would have to implement it by ourselves. For example:

• by moving the user entry into a trash branch
• by assigning the user to a password policy that immediately expires the password
• by adding a new "blockedaccount" feature in openldap

The 2 first points would add constraints on the LDAP directory, which we shouldn't impose for a software like service-desk. The last one would require some work. So IMO we should try without this independent blocking feature.

[coudot]

Some organizations use a specific attribute in OpenLDAP, like accountDisable, which is used in ACL to block the authentication (and sometimes to hide this account from searches).

As we don't have in OpenLDAP the same feature that in AD, I propose for now to not implement it for OpenLDAP.

But we could add a feature for AD/OpenLDAP that will modify the account end time (accountExpires/pwdEndTime) to current date.

[coudot]

@davidcoutadeur try to find an attribute in OpenLDAP that can be used for this

[davidcoutadeur]

I have proposed an evolution of the ppolicy draft here: https://bugs.openldap.org/show_bug.cgi?id=10261

[davidcoutadeur]

Until the evolution is accepted, the feature could be implemented by:

• adding the custom attribute into the schema:

      ( 1.3.6.1.4.1.42.2.27.8.1.34
      NAME 'pwdAccountDisabled'
      DESC 'The time an user account was disabled'
      EQUALITY generalizedTimeMatch
      ORDERING generalizedTimeOrderingMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
      SINGLE-VALUE )

and adding this attribute to the desired object classes

• adding a custom ACL in front of all ACLs in main database section:

olcAccess: to attrs=userPassword  by set="this/pwdAccountDisabled" none  by * break

[davidcoutadeur]

To discuss: add also the possibility the add a comment while enabling / disabling account

[davidcoutadeur]

We also need to add a new menu for displaying blocked accounts

[davidcoutadeur]

The two previous tasks are finished:

• add also the possibility to fill a comment while enabling / disabling account
• add a new menu for displaying disabled accounts

TODO:

• add doc for new comment parameters

Note: adding the comment modal everywhere would be done in #127

[davidcoutadeur]

This feature seems ready now. merging