Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Retroactively add lastLoginTime attribute on existing users when activating account policy plugin #776

Closed
389-ds-bot opened this issue Sep 12, 2020 · 4 comments
Labels
RFE Request for Enhancement
Milestone

Comments

@389-ds-bot
Copy link

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47439


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.

::Request For Enhancement::

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).
@389-ds-bot 389-ds-bot added the RFE Request for Enhancement label Sep 12, 2020
@389-ds-bot 389-ds-bot added this to the 1.4.5 milestone Sep 12, 2020
@389-ds-bot
Copy link
Author

Comment from lkrispen (@elkris) at 2015-03-16 13:41:28

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 ?

@389-ds-bot
Copy link
Author

Comment from lkrispen (@elkris) at 2017-02-11 22:53:55

Metadata Update from @elkris:

  • Issue set to the milestone: 1.4 backlog

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2017-10-18 21:30:55

Metadata Update from @mreynolds389:

  • 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

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2020-05-20 16:20:58

Metadata Update from @mreynolds389:

  • Issue set to the milestone: 1.4.5 (was: 1.4 backlog)

@mreynolds389 mreynolds389 modified the milestones: 1.4.5, 2.0.0 Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFE Request for Enhancement
Projects
None yet
Development

No branches or pull requests

2 participants