Skip to main content

User Access Deactivation - Hitachi ID Identity Manager

Several processes are available for timely and reliable user access deactivation. Choice of the appropriate process depends on Hitachi ID Systems customer business requirements and preferences:

  • Scheduled termination

    Some workers, such as contractors, summer students and temporary staff, have pre-defined termination dates. These dates can be entered or loaded into Hitachi ID Identity Manager.

    A scheduled batch process runs periodically on the Identity Manager server and checks for scheduled terminations. It can send e-mails to managers in advance, allowing them to update termination dates (e.g., defer them). It can disable users whose termination date has passed and it can delete, move or reassign accounts, mail boxes, home directories etc. for users who have been disabled for a sufficiently long amount of time.

  • HR-initiated termination

    HR staff can mark employees and contractors If contractors      are tracked in an HR or similar application (note) either with a termination date, which is processed as described above or as already terminated. The Identity Manager automation engine can periodically poll the HR system for such changes and automatically disable login access for every newly-terminated user.

  • Manager-initiated termination

    Managers can use the same change request process to request updates to a user's termination date and status. This can be used to schedule or defer termination or to request immediate deactivation. Requests are routed to authorizers by e-mail, who respond on a secure, authenticated web form. Once deactivation requests are approved and/or a user's termination date has elapsed, all login IDs for the indicated user are disabled.

  • Urgent termination

    A web-based user management interface allows security administrators to terminate access to any user, on any combination of systems, immediately. This is used for urgent termination scenarios.

  • Request-driven access deactivation

    Users can sign into the request portal and ask to remove specific access rights in their own user profiles (they rarely do this) or the profiles of their subordinates or others within their scope of authority.

  • Access certification

    Managers, resource owners and others can be invited to periodically, or in response to an event such as a transfer, review users and their entitlements, certifying some and flagging others for removal. Items flagged for removal may be subject to further approval before being deactivated.


Automated Deactivation

Real-world access deactivation in a typical, corporate environment can be a complex, multi-step process. Following is an overview of how Identity Manager is normally configured to handle this process. While the following may sound complex, Hitachi ID Systems provides a pre-built configuration that means everything described below can be setup in just a few hours.

Day

Participants

Steps
Before 0

\multicolumn{2)(>l)(Prior to access deactivation}
  HR, Manager

View, set, modify scheduled termination date.
  IDM

Read new scheduled termination date from SoR such as HR.
  IDM

Send manager advance warnings of impending date, so it can be changed.
0

\multicolumn{2)(>l)(At deactivation time, on the deactivation date}
  HR, Manager, IT Security

Optionally request immediate/urgent deactivation
  IDM

Deactivate all login IDs, disconnect any "live" sessions; leave everything else in place.
0 to X

\multicolumn{2)(>l)(After deactivation, before archiving}
  HR, Manager

Request reactivation (i.e., did not notice erroneous termination date).
X

\multicolumn{2)(>l)(Archiving}
  IDM

Move user's accounts to "disabled users" OUs.
  IDM

Remove user from security groups and mail distribution lists.
  IDM

Add user to "disabled users" security group.
  IDM

Move, change ownership of user's home directory, mail folder (e.g., expose to manager).
  IDM

Archive contents of user's home directory, mail folder.
X+Y

\multicolumn{2)(>l)(Cleanup}
  IDM

Delete accounts on target systems, but retain identity information (in case of rehire).
After 0

\multicolumn{2)(>l)(Rehire detection and blocking}
  IDM

Prevent new users from being created who appear to be the same person. Ask user to reactivate profile or inform user that this user is not allowed back.

 

In the above, 0 is a scheduled termination date, X is typically 30 days and Y is typically 60 days.


Watch a Movie

Scheduled termination


Play movie

Content:

  • A manager schedules termination/deactivation for one of his subordinates.
  • Members of the HR department are invited to approve the change.

Key concepts:

  • Scheduled events, such as deactivation, are modeled using a date attribute in the user's profile.
  • Access controls determine who can see this date, who can request a change and who must approve a change.
  • In this example, a user's manager and anyone in HR can see/edit this date, but the user cannot. If the manager requests a change, HR must approve it. Conversely, if HR requests a change, the manager will be asked to approve it.
  • Once the request is approved and stored in the user's profile, other processes take care of the deactivation process. The workflow component is simply for setting this date.

Authorize scheduled termination


Play movie

Content:

  • Approval of a change to a user's scheduled termination date is handled by an HR user.
  • In this example, three HR users were invited but any one of them can do the job -- increasing process reliability and shortening time to completion.

Key concepts:

  • Who is invited to approve a change is determined by policy.
  • Policy is based on relationships between requester, recipient and authorizer.
  • A random subset of a users (e.g., members of an HR group) can be chosen.
  • A further subset of invited users may be sufficient to approve.
  • Invitations go out via e-mail, with responses via authenticated, secure, encrypted web form.

Defer scheduled termination


Play movie

Content:

  • After termination was scheduled, but before it was completed, it can still be deferred.
  • The manager of a user scheduled for deactivation is automatically invited to review and possibly defer the termination date.

Key concepts:

  • Batch processes send advance warnings of scheduled events like termination.
  • Users can follow an embedded link and make appropriate changes, if required.

Termination/deactivation triggered by HR system of record (SoR)


Play movie

Content:

  • A scheduled deactivation date can be set from a system of record.
  • Changes from a SoR are normally automatically approved.
  • The user's manager will still get advance warning and may defer the date.

Key concepts:

  • New values for identity attributes can be fed in from a system of record, with no direct human interaction with Identity Manager.
  • Regardless of the data source, all changes go through a workflow request, which may (or may not) require approval.
  • Once a value is set, any processes which depend on the value proceed - regardless of the value's source (web portal request, HR feed, etc.).

Immediate deactivation triggered by HR SoR


Play movie

Content:

  • The HR system of record can specify that a user should be deactivated immediately, rather than on a scheduled date.
  • This means that when the batch process runs to read HR data it will deactivate the user.

Key concepts:

  • Changes to identity data (attribute value, disappearance of a user, etc.) in a SoR can drive actions other than just attribute changes to a user's profile.
  • In this case, the required change is immediately disabling the user.
  • Urgent normally does not require approvals.

Immediate deactivation, initiated by manager, requiring approval


Play movie

Content:

  • A manager can log into Identity Manager and deactivate an employee immediately.
  • This kind of process typically does require approval, by HR.

Key concepts:

  • The user is deactivated, but only once the request is approved.
  • Managers are generally only allowed to do this to their direct reports.
  • HR users are generally allowed to do this to anyone (at least outside of HR and executive groups).

page top page top