Skip to main content

One-off Access Requests - Hitachi ID Privileged Access Manager

Overview of Workflow in Hitachi ID Privileged Access Manager

Privileged Access Manager includes the same authorization workflow engine as is used in Hitachi ID Identity Manager. Workflow enables users to request access to a privileged account that was not previously or permanently authorized. When this happens, one or more additional users are invited (via e-mail or SMS) to review and approve the request. Approved requests trigger a message to the request's recipient, including a URL to Privileged Access Manager where he or she can re-authenticate and "check out" access.

The workflow process is illustrated by the following series of steps:

  1. User UA signs in and requests that access to privileged account PA on system S be made available to user UB at some later time T. UA may be the same person as UB (a self-service request).
  2. Privileged Access Manager looks up authorizers associated with LA on S.
  3. Privileged Access Manager may run business logic to supplement this authorizer list, for example, UA or UB's manager. The final list of authorizers is LA. There are N authorizers but approval by just M (M <= N) is sufficient to disclose the password to PA.
  4. Privileged Access Manager sends e-mail invitations to authorizers LA.
  5. If authorizers fail to respond, they get automatic reminder e-mails.
  6. If authorizers still don't respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request. Privileged Access Manager will invite replacement authorizers next.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web portal, review the request and approve or deny it.
  8. If any authorizers deny the request, e-mails are sent to all participants (UA, UB and LA) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. The e-mail sent to the recipient includes a URL to an access disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager.
  11. UB clicks on a button in the web portal to check-out privileged access.
  12. UB then may click on a button to do one of the following (the options available will vary based on policy):
    1. Display the password (rarely allowed).
    2. Place a copy of the password in the operating system copy buffer (sometimes allowed).
    3. Launch an RDP, SSH, vSphere, SQL Studio or similar login session to PA on S (most common).

Turning Human Authorizers into Reliable Participants

The _PRODUCT workflow engine is designed to get quick and reliable feedback from groups of business users, who may be individually unreliable. This is accomplished with:

  • Concurrent invitations to multiple users to review a request.
  • Approval by N of M authorizers (N is fewer than M).
  • Automatic reminders to non-responsive authorizers.
  • Escalation from non-responsive authorizers to their alternates.
  • Scheduled delegation of approval responsibility from unavailable to alternate approvers.
  • Checking authorizers' out-of-office status and pre-emptively escalating requests if an OOO message has been set.
  • Allowing authorizers to approve or reject requests from their mobile phone (from any location, at any time, without a VPN).

Scenarios for use of Workflow

In a typical Privileged Access Manager deployment, two different kinds of workflow requests are used. To understand why, one first has to consider that there are two styles of access disclosure:

  1. Some users are pre-authorized to gain access to a set of privileged accounts. This is typically done by placing users into Active Directory or LDAP groups and configuring Privileged Access Manager such that users who are members of specific AD or LDAP groups are automatically granted the right to access privileged accounts on managed systems attached to a given managed system policy.

    When these users need to access a privileged account, they just sign into Privileged Access Manager and checkout a session into the account they need -- no further authorization is required.

    An illustrative example: users in the AD group NYC_WINDOWS_SERVER_ADMINS can sign into Privileged Access Manager with their AD ID and password and launch an RDP session as Administrator on any of the Windows servers in the New York data center without waiting for approvals.

  2. Other users have no pre-assigned rights to access privileged accounts, but may require occasional access, subject to one-off approval.

    An illustrative example: a developer who will assist with a production migration can request access to root on a Linux server LAX_ECOM_A tomorrow between 11PM and 3AM. Since he is not pre-authorized, the developer must wait for this request to be approved by the e-Commerce server's owner before he can start a session and in any case the session must start on or after 11PM and will be terminated on or before 3AM.

The scenarios above raise the question: how did users get placed in pre-authorized groups in the first place? This question leads to two types of workflow requests:

  1. The first type of workflow request is to place users into pre-authorized groups, typically on AD or LDAP. These requests are handled by complementary Hitachi ID Systems modules, included with Privileged Access Manager at no cost:

    1. Hitachi ID Group Manager allows users to request membership in pre-authorized AD or LDAP groups, subject to validation and authorization business processes.
    2. Hitachi ID Access Certifier can be configured to periodically invite group owners to review lists of pre-authorized users and remove those who no longer have a legitimate business need for that access.

  2. The second type of workflow request is to authorize a single session to use a privileged account. This is handled directly by the Privileged Access Manager workflow process.

Both types of workflow request are accessed using the same web portal, login credentials, etc. Both support multiple authorizers, automated reminders, escalation, delegation, etc.

Read More:

page top page top