Features Launch Privileged Login Sessions
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+

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. It includes the following access disclosure capabilities:

  1. To users, via a web interface, subject to access control policy.
  2. To users who do not have pre-authorized access rights, after approval.
  3. To applications, in order to replace embedded passwords, using an API where applications authenticate using an OTP and may only connect from a pre-defined range of IP addresses.
  4. To service launching programs, such as the Windows Service Control Manager, by writing new password values to the appropriate locations after a successful password change.

Note that all disclosure is subject to SSL encryption, strong, personal authentication, access controls or workflow approval 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 workstation WKSTN01234 to policy RGWKSTNS") or implicitly, using an expression. Expressions may be based on the operating system type, IP address, MAC address or workstation name (e.g., "attach every workstation running Windows XP in subnet 10.1.2.3/24 to policy X")

Managed system policies are configured with operational and access control rules, including:

  1. Which accounts' passwords to randomize on attached systems.
  2. How often to change passwords.
  3. How to compose random passwords (e.g., length, complexity, etc.).
  4. What actions to take after successful or failed attempts to disclose a password.
  5. What access disclosure methods to offer users who wish to sign into privileged accounts on attached systems (e.g., launch remote desktop, launch SSH, temporarily place user in security groups, display current password to user, etc.).

Privileged Access Manager users are organized into user groups, either explicitly or implicitly. In a typical deployment, 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, that can be simultaneously assigned to the same user.

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:

  1. User UA signs in and requests that the then-current password to login account LA on system S be made available to user UB at some later time T. UA may or may not be the same person as UB.
  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 with someone in the management chain for UA or UB. 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 AZ.
  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 continue to fail to respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request and invites the replacement authorizers as well.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web login page, review the request and approve or reject it.
  8. If any authorizers reject the request, e-mails are sent to all participants (UA, UB and AZ) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. A special e-mail is sent to the recipient -- UB with a URL to an access disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager and displays the password.
  11. UB clicks on a button 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.
    2. Place a copy of the password in the operating system copy buffer.
    3. Launch an RDP, SSH, vSphere or similar remote control session to the server in question.

    In other words, display of a sensitive password is not a mandatory or even recommended part of the solution.

Watch a Movie

Request one-time access


Play movie

Content:

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

Key concepts:

  • 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


Play movie

Content:

  • Authorizers are invited to review requests via e-mail.
  • Requests are approved or rejected via a secure, authenticated web form.

Key concepts:

  • Authorizers who don't respond promptly will receive reminder e-mails.
  • The approvals UI is works with small web browsers, such as on smart phones. This means that requests can be approved any-where, any-time.

Launch one-time session to a privileged account


Play movie

Content:

  • Once a session has been approved, the request's recipient can launch a login session to the privileged account.

Key concepts:

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