Skip to main content

Hitachi ID LinkedIn Page Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Single Sign-on Mechanisms - Hitachi ID Privileged Access Manager

Hitachi ID Privileged Access Manager controls access by users and programs to privileged accounts on managed endpoint systems. In most cases, this means that when a user is authorized to connect to a privileged account, the user is able to launch a login session directly to the managed account without seeing its password.

Display of current password values can be enabled through Privileged Access Manager policy configuration but is usually only recommended for users physically in the data center, who need access to a server console.

Access disclosure options include:

  1. Directly launch Terminal Services Client (RDP), SSH (PuTTY), VMware vSphere, SQL Studio, web browser/form login and other connections to target systems from the Privileged Access Manager web user interface, without displaying a password value.
  2. Place a copy of a sensitive password into the Windows copy buffer. This password is automatically cleared from their copy buffer after a few seconds.
  3. Temporarily place the authorized user's Active Directory account in a local or domain security group.
  4. Temporarily append the authorized user's public SSH key into the managed account's .ssh/authorized_keys file.
  5. Where password display is required, display the password but automatically clear it from the user's browser display after a few seconds.

Policy rules determine which mechanisms are available to what users, managed systems and managed accounts.

Unix / Linux Systems: Temporary SSH Trust

Privileged Access Manager can be configured to grant privileged access to Unix and Linux computers by temporarily placing an administrative user's personal SSH public key into the trusted keys file of a functional account on the target computer.

This architecture works as follows:

  1. The Privileged Access Manager server gets its own SSH public and private keys.
  2. Every user who may require privileged access to Unix/Linux systems must have:
    1. An SSH client on his PC.
    2. A well known SSH public key.
  3. A copy of the public SSH key for every user is kept on the Privileged Access Manager server or on a Unix/Linux system which Privileged Access Manager can access.
  4. Each managed Unix/Linux computer is configured with:
    1. An SSHD listener.
    2. The SUDO package.
    3. A set of functional accounts (see below).
  5. The /etc/sudoers file on each managed Unix/Linux computer is configured to grant a set of predefined privileges to each functional account. For example:
    • The account dba might be allowed to perform DB-related tasks.
    • The account backup might be allowed to perform filesystem backups.
    • The account procmon might be allowed to perform runaway processes.
    • The account monitor might be allowed to perform stats from /proc.
  6. The .ssh/authorized_keys file of each of the functional accounts is configured to trust the public SSH key of the Privileged Access Manager server.
  7. At access checkout time, Privileged Access Manager modifies the .ssh/authorized_keys file of the functional account to which access was granted to include the public key of the user who needs access to that account.
  8. At access checkin or expiry time, Privileged Access Manager modifies the .ssh/authorized_keys file of the relevant functional account to remove the public key of the user who had access to that account.

The access disclosure process works as follows:

  1. Administrator A requests access to functional account F on computer C.
  2. The request is approved either because A has been pre-approved for such access (typically via membership in an AD group) or because some other user, with ownership rights to F@C, approves the request.
  3. Administrator A "checks out" access to F@C.
  4. Privileged Access Manager retrieves a copy of the .ssh/authorized_keys from F@C, adds A's public SSH key to the file and puts the new .ssh/authorized_keys back in F@C's home directory.
  5. A connects to F@C using SSH. This connection is authenticated using an SSH key exchange (not a password).
  6. A may have to type a password to access his own SSH private key, depending on how whether his SSH key is encrypted with his password.
  7. Eventually A will either check-in the session or the session will time out. When either event happens, Privileged Access Manager will remove A's public SSH key from F@C's .ssh/authorized_keys file.

Windows Systems: Temporary Group Membership

Privileged Access Manager can be configured to provide privilege elevation by temporarily placing a user's (normally unprivileged) personal account into a privileged security group on the target system.

This process works as follows, using an Active Directory domain, a Windows server and an RDP connection in our example:

  1. Administrator A requests privileged access to system C.
  2. The request is approved either because A has been pre-approved for such access (typically via membership in a separate AD group) or because some other user, designated as an owner of system C, approves the request.
  3. Administrator A "checks out" access to system C.
  4. Privileged Access Manager places A's AD account into a privileged group on system C, such as (local group) "Administrators."
  5. A connects to C using RDP. This connection might be mediated by Privileged Access Manager, which can launch the RDP session directly from its web portal using an ActiveX control.
  6. Depending on how Privileged Access Manager and C are configured, A may have to type his personal AD password to establish the RDP connection to C.
  7. At some later time, A will either check-in the session or the session will time out. At this time, Privileged Access Manager will remove A's AD account from the privileged group on C.

This approach of manipulating group memberships rather than disclosing passwords has the advantage that audit logs on the target system (C in the example above) show activity by the individual administrator (A in the example above) rather than by a generic local administrator account.

The limitations of this approach are:

  1. It does not help with access to systems that are not linked to a directory (e.g., Windows in AD, Linux in LDAP, etc.) since it presupposes that the user can already sign into the system in question, but not with adequate privileges for the desired activity.
  2. It does not help with systems which are disconnected from the network.
  3. Users, once granted elevated privileges, can connect from a different client device and therefore bypass any client-based or proxy-based session monitoring infrastructure. If there is a desire to record (keylog, video capture, etc.) user activity, then this approach is not appropriate.
page top page top