Three integration methods: direct, proxy and local service

There are three styles of connectivity between a Hitachi ID Privileged Access Manager server and managed systems, as illustrated in Figure [link].

    Push-mode, pull-mode and proxies to connect to managed systems

In the figure:

  1. Direct access is where the Privileged Access Manager server runs a connector locally. This connector connects to the target system over the network. This is also called a push mode target system.
  2. Indirect access via a Privileged Access Manager proxy server is where an active Privileged Access Manager server connects to a proxy server. The proxy server runs a connector on behalf of the active server. The connector connects to a target system on the network. Proxy servers are typically co-located with one or more distant or firewalled managed systems. Interaction with target systems via a proxy is still considered push mode, because an active Privileged Access Manager server initiates each connection.
  3. Direct or web-proxied connections initiated from a client device, accessing a web services API URL on an active Privileged Access Manager server. This is called local service mode and is typically deployed on user laptops, to allow for the fact that they may be powered off, relocated assigned dynamic IP addresses, firewalled, NAT'ed and generally be difficult or unreliable for a central Privileged Access Manager server to find.

Pushing updates directly or via a proxy server

Figure [link] illustrates the network communication paths in a typical Privileged Access Manager deployment, where Privileged Access Manager pushes passwords to fixed target systems -- servers, applications, network devices, etc.

    Privileged Access Manager Push-Mode Network Architecture Diagram

In the diagram:

  1. Three distinct physical sites are shown, each surrounded by a dotted-line border.
  2. Two Privileged Access Manager servers are deployed, to two different sites. Real-time replication provides for resiliency in the event of a hardware failure on a single server or a complete outage at either site.
  3. The Privileged Access Manager servers run on Windows 2012. This platform provides the widest possible range of client software, making Privileged Access Manager easy to integrate with many kinds of target systems.
  4. Stored passwords are encrypted (using AES). The encryption key is kept in the registry of each Privileged Access Manager server and is itself encrypted using a key embedded in the Privileged Access Manager software.
  5. Each Privileged Access Manager server has a complete, local copy of the entire password database along with all configuration information.
  6. Data replication traffic between the two servers is encrypted, making it resistant to snooping or tampering by a man-in-the-middle attacker.
  7. Periodically, each Privileged Access Manager server connects to target systems and pushes new passwords to them. The protocol used depends on the type of target system, with two examples shown: LDAPS or NTLM for Windows servers, SSH to Unix or Linux servers and an encrypted TCP/IP connection to Unix targets that do not have an SSH service but do have a local Privileged Access Manager listener.
  8. Some target systems may be unreachable directly, because of intervening firewalls. These may be contacted indirectly using a Privileged Access Manager proxy server, co-located with the target system. In this scenario, communication from the primary Privileged Access Manager server to the target system is via an arbitrarily-numbered TCP/IP connection and AES encryption using a shared key. The connection is forwarded to the target system by the proxy, using that target system's native protocol.
  9. Privileged Access Manager clients, such as IT workers or applications that use Privileged Access Manager in place of embedded passwords, connect to Privileged Access Manager over HTTPS. Since multiple Privileged Access Manager servers are available and each of them contains a full data set, this connection can be load balanced.

Local service on laptops and rapidly provisioned VMs

When managing passwords on laptops or rapidly provisioned VMs, Privileged Access Manager may be configured to operate in "local service mode." This means that a local agent is installed on the endpoint and this agent periodically contacts the central Privileged Access Manager server, over HTTPS, to request new administrator passwords.

Once the local password has been set, a confirmation is sent to the Privileged Access Manager server, which stores the new value. The new password(s) are encrypted and archived in the Privileged Access Manager server's replicated storage, where IT staff may retrieve them.

Local service mode is not used by default. However, there are specific cases where it is preferable to the more common push-style integration:

  1. On laptops, because a server (i.e., Privileged Access Manager) has no way of knowing where or when they will next be attached to the network and may be unable to initiate a connection to the laptop, due to firewalls, NAT, closed ports or other security measures.
  2. On rapidly provisioned VMs (e.g., IaaS or private cloud), since their entire lifespan may be quite short and it is important to onboard them when first provisioned, rather than waiting for a scheduled, batch auto-discovery process to run.

The Privileged Access Manager local workstation service (LWS), which implements "local service mode" integration such that the managed endpoint initiates communication with the Privileged Access Manager server, rather than the reverse, is compatible with:

  1. Windows clients: Windows XP, Windows Vista, Windows 7~10.
  2. Windows servers: Server 2003, Server 2008/R2 and Server 2012/R2.
  3. Linux: 32-bit and 64-bit Linux systems.
  4. Other Unix: Available on demand.