Notes from triage:

• Note, we may want to disable the 'last successful bind timestamp' by default in a future release as it cause unnecessary replication messages to be fired at a time whene highly computational intensive load is on the server as well (morning authentication -> crypto operations), so at the very least it needs to be conditional.
• Maybe we should use last password change instead, if the user fails to change pw for too long it gets locked.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1273040

Workaround: https://www.redhat.com/archives/freeipa-users/2015-March/msg00052.html

There is already a 389 DS "Account Policy" plugin that is capable of this. FreeIPA should allow this plugin to be configured and used.

Additionally, it would be ideal to enhance the existing plugin to meet these compliance requirements as described in this 389 DS ticket:

​https://fedorahosted.org/389/ticket/48908

Summary from team discussion

• use nsAccountLock to lock accounts (verify that it's used by LDAP bind, kinit, and SSSD for certs and ssh login)
• store last login date as low-resolution GeneralizedTime attribute (resolution: 1 day). A low resolution time stamp is good enough for account expiration and avoids replication storms at the same time.
• create a 389-DS plugin that updates last login day time stamp when ever a user performs LDAP bind or kinit or logs in with a special server control. The plugin can also ensure that the attribute has only low resolution.
• define a special server control that is sent by SSSD whenever a user logs in with a SSH key or certificate.
• create a service that checks for expired accounts daily and sets nsAccountLock.
• store timestamp of account lock in krbPrincipalExpiration

• use group policy to define account expiration
• exclude admin group from password expiration

There is also an event thread within 389-DS, which a plugin can use to register events to execute at some regular time. This might be useful for solving part of this problem.

Please also consider SSSD offline authentication:

It is possible that users have to rely on SSSD offline auth because unable to connect to IPA serversbecause of no networking, no VPN.

They will be shock their accounts being locked in this situation.