Single Sign-on Mechanisms - Hitachi ID Privileged Access Manager
Hitachi ID Privileged Access Manager controls access by users and programs to privileged accounts on systems and applications. By default, that means that when a user is authorized to connect to a privileged account, the user is able to launch a login session directly to that account without ever seeing its password.
Display of current password values can be enabled through Privileged Access Manager policy configuration but is not normally recommended.
Access disclosure options include:
- IT staff can directly launch Terminal Services (RDP), SSH (PuTTY), VMWare vSphere, SQL Studio and other connections to target systems from the Privileged Access Manager web user interface, without displaying a password value.
- IT staff can use an ActiveX control embedded in the Privileged Access Manager web portal to place a copy of a sensitive password into their Windows copy buffer, again without displaying the passwords. This password is automatically cleared from their copy buffer after a few seconds.
- Privileged Access Manager can dynamically attach a recipient's Active Directory domain login ID to a local security group on a target system and later remove it. This eliminates the need to disclose passwords even to a software agent on the recipient's workstation.
- Privileged Access Manager can temporarily place a user's public SSH key into the target account's .ssh/authorized_keys file.
A policy defined for each set of managed systems in Privileged Access Manager determines which of these access disclosure mechanisms is available. For example, password display may be allowed for Windows workstations, since they may be inaccessible over the network, but RDP sessions with injected passwords may be mandatory on Windows servers.
Unix / Linux Systems: Temporary SSH Trust
Privileged Access Manager can be configured to disclose 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:
- The Privileged Access Manager server gets its own SSH public and private keys.
- Every user who may require privileged access to Unix/Linux systems
- An SSH client package on his PC.
- Defined SSH private and public key.
- A copy of the public SSH key for every user is kept on the Privileged Access Manager server.
- Each managed Unix/Linux computer is configured with:
- An SSHD listener.
- The SUDO package.
- A set of functional, unprivileged accounts (more on this later).
- 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.
- 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.
- 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.
- 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:
- Administrator A requests access to functional account F on computer C.
- 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.
- Administrator A "checks out" access to F@C.
- 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.
- A connects to F@C using SSH. This connection is authenticated using an SSH key exchange (not a password).
- 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.
- 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 disclose privileged access to Windows servers by temporarily placing an administrative user's unprivileged Active Directory domain account into a privileged security group on the target computer.
This process works as follows:
- Administrator A requests privileged access to computer C.
- 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 computer C, approves the request.
- Administrator A "checks out" access to computer C.
- Privileged Access Manager places A's AD account into a privileged group on computer C, such as (local group) "Administrators."
- 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 Active-X control.
- Depending on how Privileged Access Manager and C are configured, A may or may not have to type his personal AD password to establish the RDP connection to C. For example, if C trusts Kerberos-authenticated RDP sessions or if Privileged Access Manager has an agent on A's workstation to acquire his login password, then no manual authentication step will be required.
- 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 AD account from the privileged group on C.
This approach of manipulating group memberships rather than disclosing password has the advantage that audit logs on the target computer (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:
- It does not help with non-Windows machines or non-domain-members.
- It does not help with machines which are disconnected from the network.