Launch Privileged Login Sessions - Hitachi ID Privileged Access Manager
Hitachi ID Privileged Access Manager is designed to not only randomize and securely store
privileged passwords, but also to connect users and programs to
privileged accounts after appropriate authentication and authorization.
Passwords and/or access can be disclosed to:
- frequent users, subject to access control policy;
- infrequent users, subject to a one-time approval workflow;
- applications, to replace embedded passwords, via a web
services API, client-side library, OTP, IP address validation,
program fingerprinting and more; and
- service launching infrastructure, such as the Windows SCM and scheduler,
by injecting new passwords and optionally restarting services.
All disclosure is subject to user identification, strong authentication,
SSL encryption in transit and audit logs.
Immediate Disclosure With Access Controls
The most common form of access control in the Privileged Access Manager is based
on managed system policies. These policies are named collections of
managed systems containing privileged accounts whose passwords may be
randomized and access to which is controlled.
Managed systems may either be attached to a policy explicitly (e.g.,
"attach system SYS0123 to policy MSP-A") or implicitly,
using an expression such as "all systems of type Linux at 10.0.1.0/24
are attached to MSP-B". Expressions may be based on the operating
system type, IP address, MAC address, system name or other metadata.
Managed system policies are configured with operational and access
control rules, including:
- Which accounts' passwords to randomize on attached systems.
- How often to change passwords.
- How to compose random passwords (e.g., length, complexity, etc.).
- What actions to take after successful or failed attempts to
- What access disclosure methods to offer authorized users -- e.g.,
launch a given type of client program with ID/password from the
credential vault, display a password, copy buffer integration,
temporary group membership or SSH trust, etc.
Privileged Access Manager users are organized into user
groups, also either explicitly or implicitly. Most commonly,
users are assigned to Privileged Access Manager user groups by virtue of their
membership in Active Directory or LDAP groups.
Groups of users are then assigned specific rights with respect to
specific managed system policies. For example, "every user in
group A may launch RDP sessions to privileged accounts on systems
in policy B."
Business rules, such as segregation of duties between different
sets of users, can also be enforced. This is done by examining,
managing and limiting group membership on reference systems, such as
Active Directory or LDAP.
One-Time Disclosure With Approval Workflow
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 reject it.
- If any authorizers reject 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).
Watch a Movie
Request one-time access
- During an emergency or during a one-time event such as a
production migration, users can request access
to privileged accounts.
- Requests are subject to validation (e.g., does the request
include a valid incident number?) and authorization.
- A powerful workflow engine is built into Privileged Access Manager.
- The approval process supports:
- Inviting multiple authorizers at one time.
- N of M approvals.
- Reminders, escalation and delegation to replace
non-responsive authorizers with alternates.
Approve one-time access
- Authorizers are invited to review requests via e-mail.
- Requests are approved or rejected via a secure, authenticated
- Authorizers who don't respond promptly will receive
- The approvals UI is works with small web browsers, such as
on smart phones. This means that requests can be approved
Launch one-time session to a privileged account
- Once a session has been approved, the request's recipient
can launch a login session to the privileged account.
- As with routine administrator access, Privileged Access Manager is normally
configured to launch SSH, RDP and similar sessions rather than
displaying a password value.
- Passwords are normally re-randomized when a session completes
and access is "checked in."
- Checkout/checkin controls can limit the number of people
connected to the same administrator ID at one time.
- Late users are shown the names of people already connected
to the same account.