How to set account expiry date in openldap

Question

I wish to implement a new account policy in openldap that allow an administrator to set expiry date of user accounts. However, I can't find any related attribute in the object classes.

This is nothing related to password attributes like pwdMaxAge. The usage of this policy is for a subscription service. Once user has subscribed the server for a certain period, the administrator will set the account expiry date where subscription ends. User is authenticated if before expiry date and will fail to authenticated beyond the expiry date.

Is that possible to do so in openldap? I google and found that Microsoft's ActiveDirectory has AccountExpirationDate attribute.

Gorky

You could use expiring objects for this. – Hinze

Answer 1

There's no direct support for account expiration in OpenLDAP or it's overlays (not even in contrib/).

Howard Chu suggests using ppolicy's pwdMaxAge for this, which can be made to work, but I've found this less than ideal: If you're already using ppolicy for expiring passwords (in addition to expiring accounts), it will conflict with those settings and if you've configured grace logins (the sane thing to do), the user can change his password and thus reset the expiration timer.

So it seems the best way to implement this (and a good way it is not) is by running an external task that sets the (ppolicy attribute) pwdAccountLockedTime to the magic number that indicates a manually locked account, which cannot be unlocked by the user.

pwdAccountLockedTime

This attribute contains the time that the user's account was locked. If the account has been locked, the password may no longer be used to authenticate the user to the directory. If pwdAccountLockedTime is set to 000001010000Z, the user's account has been permanently locked and may only be unlocked by an administrator. Note that account locking only takes effect when the pwdLockout password policy attribute is set to "TRUE".

This external task (a cronjob, most likely) could be implemented in such a way that it reads the expiration date/time from a custom attribute (e.g. expirationTime) on the user record as it loops over them. That way you could store the expiration time/date on the user record, but of course the lockout relies entirely on this external task running.

Or you could write your own overlay.

Hackbut

Answer 2

Have a look at the Password Policy extension. It is supported from OpenLDAP 2.3 onwards. You may need to write some code to implement the required extended request/response controls.

If you're using OpenLDAP, you can use the dynamic objects overlay. Add objectClass=dynamicObject when creating the account, and set an appropriate entryTTL via the dynamic object refresh request.

Hinze

Note that the DDS overlay documentation indicate that objects are deleted when they expire. If this seems too harsh in situations where you want the users to able to reactivate their account under certain conditions (e.g. they pay a bill). It is possible to add a tolerance time in DDS, during which the object are kept before deletion. – Capet

Answer 3

Use shadowExpire if the user account is of type shadowAccount

Fagaceous

Answer 4

Since OpenLDAP 2.5 you can use the pwdEndTime attribute from the ppolicy overlay to achieve account expiration:

Details from the spec draft 11:

This attribute specifies the time the entry's password becomes invalid for authentication. Authentication attempts made after this time will fail, regardless of expiration or grace settings. If this attribute does not exist, then this restriction does not apply.

Capet

Answer 5

without getting to detailed - take a look at the PPolicy overlay mentioned above. It works. And you are correct, there is no "account expire time" like there is in AD.

One solution is to run a script that calculates the age of the account and add/modify the user attribute pwdPolicySubentry and set it to the DN of a policy that expires any password that is 1 second old and does not allow the user to change the password.

No client will get around that, and yet the user entry remains virtually intact.

Lanceolate

No need for all that. Just set the pwdAccountLockedTime to the zero value specified in the password-policy draft. – Hinze