Skip to main content

Server requirements - Hitachi ID Privileged Access Manager

Multiple, Load-Balanced Servers

Hitachi ID Privileged Access Manager supports multiple, load-balanced servers.

Each server can host multiple Privileged Access Manager instances, each with its own users, managed systems, features and policies.

Server Platform

Hitachi ID Privileged Access Manager: Privileged Access Management Privileged Access Manager must be installed on a Windows 2012 or Windows 2012/R2 server.

Installing on a Windows server allows Privileged Access Manager to leverage client software for most types of target systems, which is available only on the "Wintel" platform. In turn, this makes it possible for Privileged Access Manager to manage passwords and accounts on target systems without installing a server-side agent.

Each Privileged Access Manager application server requires a web server. IIS is used as it comes with the Windows 2012 Server OS.

Privileged Access Manager is a security application and should be locked down accordingly. Please refer to the Hitachi ID Systems document about hardening Privileged Access Manager servers to learn how to do this. In short, most of the native Windows services can and should be removed, leaving a very small attack surface, with exactly one inbound TCP/IP port (443):

  1. No ASP, JSP or PHP are used, so such engines should be disabled.
  2. .NET is not required on the web portal and in most cases can be disabled on IIS.
  3. No ODBC or DCOM are required inbound, so these services should be filtered or disabled.
  4. File sharing (inbound, outbound) should be disabled.
  5. Remote registry services should be disabled.
  6. Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly remote desktop services (often required for some configuration tasks), plus a handful of port numbers between Privileged Access Manager servers, for replication.

Each Privileged Access Manager server requires a database instance. Microsoft SQL 2012 is the recommended choice, Microsoft SQL 2014 will be officially supported in 2016. Oracle database is currently supported but will be deprecated in the next release, so is not recommended.

Server Configuration

Production Privileged Access Manager application servers are normally configured as follows:

  • Hardware requirements or equivalent VM capacity:
    • An Intel Xeon or similar CPU. Multi-core CPUs are supported and leveraged.
    • At least 8GB RAM -- 16GB or more is typical for a server.
    • At least 500GB disk, preferably configured as RAID for reliability and preferably larger for retention of more historical and log data. More disk is always better, to increase log retention.
    • At least one Gigabit Ethernet NIC.

  • Operating system:
    • Windows 2012R2 Server, with current service packs.
    • The server should not normally be a domain controller and in most deployments is not a domain member.

  • Installed and tested software on the server:
    • TCP/IP networking, with a static IP address and DNS name.
    • IIS web server with an SSL certificate.
    • At least one web browser and PDF viewer.

  • A database instance is required to host the Privileged Access Manager schema. Microsoft SQL Server 2012 is recommended (Oracle 11gR2 is supported but will be discontinued with the 10.0 release). The SQL Server database software can be deployed on the same server as the Privileged Access Manager application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes.

In addition to a web/application server, Privileged Access Manager requires a database server. In most environments, the Microsoft SQL Server software is installed on the same hardware or VM as the Privileged Access Manager software, on each Privileged Access Manager server node. This reduces hardware cost, eliminates network latency and reduces the security surface of the combined solution.

Database I/O performance on a virtualized filesystem (e.g., VMDK or equivalent) is not very performant. Accordingly, if a VM is used to host the database server software, please consider a NAS or SAN solution for the actual data storage.

Privileged Access Manager can leverage an existing database server cluster. Hitachi ID Systems recommends a dedicated database server instance, however, for a number of reasons:

  1. The data managed by Privileged Access Manager is extremely sensitive, so it is desirable to minimize the number of DBAs who can access it (despite use of encryption).
  2. MSSQL has limited features to isolate workloads between database instances on the same server. This means that a burst of activity from Privileged Access Manager (as happens during nightly auto-discovery) would cause slow responses in other applications. Conversely, other applications experiencing high DB load would slow down Privileged Access Manager.
  3. Privileged Access Manager already includes real-time, fault-tolerant, WAN-friendly, encrypted database replication between application nodes, each with its own back-end database. Use of an expensive DB server cluster is neither required nor beneficial.

Read More:

  • Network Architecture:
    How user PCs, servers, network devices, multiple, replicated Privileged Access Manager nodes and other elements interact on the network.
  • Replicated Credential Vault:
    Replicated storage of passwords to privileged accounts in multiple, physically distant, encrypted vaults.
  • Included Connectors:
    Systems on which Privileged Access Manager can discover accounts, randomize passwords and launch login sessions.
  • Infrastructure Auto-discovery:
    Automatically finding and classifying workstations, servers, applications and network devices as well as privileged accounts and services on each one.
  • Non-target integrations:
    Integrations between Privileged Access Manager and IT infrastructure where it may not be managing passwords or privileged access -- such as e-mail systems, incident management applications and more.
  • Workflow Requests and Approvals:
    Enabling users to request and approve one-off access to sensitive accounts.
  • Concurrent Access to Accounts:
    Limiting how many administrators can simultaneously manage a system and keeping administrators informed of one-anothers activity.
  • Single Sign-on Mechanisms:
    Options for connecting users to privileged accounts, through credential injection, trust manipulation and temporary group membership, all without displaying passwords from the vault.
  • Server requirements:
    Sizing, configuration and number of servers on which to deploy Privileged Access Manager.
  • Scalability:
    Scaling to manage passwords across millions of devices.
  • Emergency access:
    Access to Privileged Accounts During Emergencies.
  • Language Support:
    A list of languages supported in the web portal.
page top page top