#50206 Add Unlock Inactive Accounts option to dsidm CLI
Closed: fixed 3 months ago by spichugi. Opened 9 months ago by spichugi.

Issue Description

Accounts which are inactivated through the Account Policy Plug-in cannot be managed with the tools that are used to manage lockouts that are set manually by the administrator (ns-activate.pl) or through the password policy.

If an account is locked because it reached the inactivity limit, it can be reactivated by resetting the lastLoginTime attribute. We should be able to set it with CLI for a generic account:

dsidm ldap://server.example.com -D bind_dn -W -b dc=example,dc=com account reactivate user 20160610080000Z

Also, we should add the functionality from ns-inactivate.pl too.
account status should show the full ns-accountstatus.pl functionality.

I think it can be done as a part of this issue.

Metadata Update from @spichugi:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

9 months ago

I thought this was already done?

I thought this was already done?

For the activation/deactivation, we only have the nsAccountLock to true or removing it option.

What we lack:
ns-accountstatus.pl has a much bigger output than account status.

There is also a possibility to reactivate with setting lastLoginTime which is not in new CLI dsidm account.

ns-activate.pl and ns-inactivate.pl did take care about nsRoleDN, nsDisabledRole andnsManagedDisabledRole

@spichugi In this case, I think we should only support removing from the nsDisabledRole, we shouldn't add back into during an inactivate. The point of the role was to assigna cos template that wrote nsAccountLock on the account. My assumption is that this way you could give an aci to allow someone to write to the nsDisabledRole, but not the user themsely, and the server would proxy the write to the user. However, this is just a simply emulated by an aci of "allow write nsAccountLock" to anything because it's the same effect ...

I'd rather not have "account lock" create cos templates, nsroles, and all that just to set a single attribute. It requires many more permissions than the simple "just write accountlock true".

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.1

8 months ago

@spichugi In this case, I think we should only support removing from the nsDisabledRole, we shouldn't add back into during an inactivate. The point of the role was to assign a cos template that wrote nsAccountLock on the account. My assumption is that this way you could give an aci to allow someone to write to the nsDisabledRole, but not the user themsely, and the server would proxy the write to the user. However, this is just a simply emulated by an aci of "allow write nsAccountLock" to anything because it's the same effect ...

Actually it is so you can lock/unlock a subtree of users, it has nothing to do with aci's or delegating access. We should still support this functionality in dsidm.

@spichugi, sorry to jump late in the thread but I am not sure to understand what is the purpose of the ticket.

The account lockout is enforced during bind, either by the core server (using nsAccountLock) or by accntPolicy plugin (using by default lastLoginTime or any other timestamp attribute).

nsAccountLock can be real or virtual (e.g. ns-inactivate). I think it could be similar for accntPolicy plugin.

IMHO new CLI should offers the two approaches

@mreynolds If it's to lock a subtree of users, should we implement that differently in the cli over a single account lock?

@mreynolds If it's to lock a subtree of users, should we implement that differently in the cli over a single account lock?

Do you mean ditch COS, and loop over and update all the subtree entries?

No I mean to keep COS but to say "subtreelock" instead of "lock"? I think that for single account locks, we shouldn't involve COS, but for subtrees, no issue (which also has the benefit that once the subtree lock is removed, the individual account lock remains).

Metadata Update from @spichugi:
- Issue assigned to spichugi

4 months ago

Metadata Update from @spichugi:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata