Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 975217
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
If the account policy plugin is activated and set to lockout users after x days of inactivity, preexisting users will not be able to login if the "altstateattrname" is set to "createTimestamp" as described in the DS9 admin guide (section 14.5). A request has been made by a customer to automatically apply a "lastLoginTime" to existing users in the directory upon plugin activation. Here is the scenario: 1) Directory exists with many users whom do *not* have a "lastLoginTime" attribute 2) Some accounts never actually login using their ldap credentials 3) Company policy dictates that inactive accounts get locked out after 90 days 4) Account policy is then activated to lockout accounts after 90 days Results of activation: 1) If "createTimestamp" is used as an alternative attribute for inactivity lockout, all existing users will be locked out immediately. 2) If "createTimestamp" is _not_ used as an alternative attribute for inactivity lockouit, all existing users will be able to login once (for free) after which "lastLoginTime" will be captured and set 2a) This means that the users that do not ever log in, will be violating the mandated password policy, as their "free" login will never be used. Workarounds: 1) Run a script to set the "lastLoginTime" on all users prior to activating the lockout policy 2) Activate the policy without letting createTimestamp be the fallback attribute, and add the fallback attribute in the inactivation policy after the first 90 days have been reached (or whatever the lockout policy is).
Instead of touching all entries to set a lastlogin time, could we store the activation time in the passwordpolicy entry and use this as fallbeack if lastlogintime or an alterante attr is not set ?
Metadata Update from @lkrispen: - Issue set to the milestone: 1.4 backlog
Metadata Update from @mreynolds: - Custom field component adjusted to None (was: Server - Plugins) - Custom field reviewstatus adjusted to None (was: Needs Review) - Custom field version adjusted to None - Issue close_status updated to: None - Issue tagged with: RFE
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.5 (was: 1.4 backlog)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/776
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.