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:
- 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).
- Privileged Access Manager looks up authorizers associated with LA on S.
- 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.
- Privileged Access Manager sends e-mail invitations to authorizers LA.
- If authorizers fail to respond, they get automatic reminder e-mails.
- 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.
- 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.
- If any authorizers deny the request, e-mails are sent
to all participants (UA, UB and LA) and the request is terminated.
- 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.
- UB clicks on the e-mail URL and authenticates to Privileged Access Manager.
- UB clicks on a button in the web portal to check-out privileged access.
- UB then may click on a button to do one of the following (the options
available will vary based on policy):
- Display the password (rarely allowed).
- Place a copy of the password in the operating system copy buffer (sometimes allowed).
- Launch an RDP, SSH, vSphere, SQL Studio or similar login session to
PA on S (most common).
Turning Human Authorizers into Reliable Participants
The built-in workflow engine is designed to get quick and reliable
feedback from groups of business users, who may be individually
unreliable. It supports:
- 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.
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:
- 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.
- Other users have no pre-assigned rights to access privileged
accounts, but may require occasional access, subject to one-off
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:
- 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:
- Hitachi ID Group Manager allows users to request membership in
pre-authorized AD or LDAP groups, subject to validation and
authorization business processes.
- 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
- 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.