Hitachi ID Systems, Inc.

Hitachi

Features Disclose Passwords
Hitachi ID Systems Web Feeds Follow Us on Twitter Follow us on LinkedIn
certification

Product Sites

Disclose Passwords

Hitachi ID Privileged Password Manager is designed to not only randomize and securely store, but also to disclose privileged passwords to people and programs after appropriate authentication and authorization. It includes the following password disclosure capabilities:

  1. To users, via a web interface, subject to access control policy.
  2. To users who do not have pre-programmed password disclosure rights, after approval by pre-defined authorizers.
  3. To applications, in order to replace embedded passwords, using an API (application programming interface) where applications authenticate using an OTP (one time password) 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 Password Manager is based on resource groups. Resource groups are named collections of devices where privileged passwords are managed and to which policies are applied.

Resources can either be attached to a group explicitly (e.g., "attach workstation WKSTN01234 to resource group 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 resource group X")

Policies applied to resource groups include:

  1. Which accounts' passwords to randomize.
  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 allow (e.g., launch RDP, launch SSH, temporary group membership, display password, etc.).

Privileged Password Manager users are likewise grouped into user groups, either explicitly or implicitly (i.e., via membership in a user group on a target system, such as Active Directory). Groups of console users are granted specific rights to resource groups. Rights include the right to display member devices, to establish login sessions to privileged accounts, etc.

Business policies, such as segregation of duties between different groups of IT administrators, can be enforced by assigning users to distinct user groups, each with access to different (non-overlapping) resources and accounts.

Approved Disclosure With Workflow

Privileged Password Manager includes the same authorization workflow engine as is used in other Hitachi ID Systems products -- Hitachi ID Identity Manager, Hitachi ID Access Certifier and Hitachi ID Group Manager. Workflow enables one user to request release of a given password. When this happens, one or more other users are invited (via e-mail) to review and approve the request. Approved requests trigger an e-mail to the password recipient, including a URL to Privileged Password Manager where he or she can re-authenticate to display the requested password or launch a login session to the device in question.

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 Password Manager looks up authorizers associated with LA on S.
  3. Privileged Password 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 Password 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 Password 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 Password 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 a password disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Password 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 or similar remote control session to the server in question.

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

Watch a Movie


(Play movie)