Security User Access Deactivation
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

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:

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.



Before 0

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

View, set, modify scheduled termination date.

Read new scheduled termination date from SoR such as HR.

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

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

Optionally request immediate/urgent deactivation

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).


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

Remove user from security groups and mail distribution lists.

Add user to "disabled users" security group.

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

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


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

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

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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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).