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, large scale 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.
  IAM system

Read new scheduled termination date from SoR.
  IAM system

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

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

Optionally request immediate/urgent deactivation
  IAM system

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

  IAM system

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

Remove user from security groups and mail distribution lists.
  IAM system

Add user to "disabled users" security group.
  IAM system

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

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

  IAM system

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

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

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

Read More:

  • Secure User Administration:
    Changing business processes and infrastructure to secure user administration.
  • Locking Down Identity Manager:
    Protecting the Identity Manager server, its data and its communications against attack.
  • Finding and Deactivating Orphan Accounts:
    Using Identity Manager to find and deactivate dormant and orphan login accounts.
  • User Access Deactivation:
    Prompt and reliable user access termination are essential to internal controls over enterprise IT infrastructure.
  • Access Change Authorization:
    Use Identity Manager to enforce robust processes to authorize changes to user access rights.
  • Enforcing Security Standards:
    Standards are an important way to ensure that users get just the entitlements they need, and no more. Naming standards are also important, as they help in the implementation of accountability measures, such as connecting security events on different systems back to individual users.
  • Global Access Reporting:
    One of the key requirements for secure identity management and access governance is the ability to find out who has access to what systems of data. This capability must span systems and platforms -- hence global access reporting.
  • Segregation of Duties Policy Enforcement:
    Detecting users whose already-assigned security entitlements violate policy and preventing users from acquiring new entitlements that would violate segregation of duties rules.
  • Entitlement and Request History:
    Hitachi ID Identity and Access Management Suite retains a history of all change requests – including requester, recipient, authorizers, times and dates, operations, attributes, entitlements and either connector results or implementer feedback.
page top page top