Multiple, Load-Balanced Servers
Hitachi ID Password Manager supports multiple, load-balanced servers.
Each server can host multiple Password Manager instances, each with its own users, target systems, features and policies.
Password Manager instances can and normally do span multiple servers. Every server hosting a given instance is functionally identical. User traffic is load balanced between servers supporting the instance. Load balancing may be accomplished using DNS (round-robin is built into most DNS servers) or at the IP level with a device from Cisco, F5, etc.
High availability is accomplished by combining load balancing with server health monitoring and automatic fail-out. Password Manager includes server monitoring tools that can be configured on each server to monitor its peers and when a failure is detected to trigger an alarm (e.g., by e-mail) and to automatically update DDNS records to remove the failed server from circulation. Hitachi ID Systems also provides these tools for Unix/BIND with traditional DNS.
There is no coded limit to the number of concurrent, replicated servers. With more than 10 servers, replication may become slow. Since the three largest customers of Hitachi ID run with just two production servers each, this is only a theoretical problem.
Password Manager must be installed on a Windows Server, with Windows 2016. being recommended at the current release level of Password Manager. Widows 2016 will be mandatory in the next major release.
Installing on a Windows server allows Password Manager to leverage client software for most types of target systems, which is available primarily on the "Wintel" platform. In turn, this makes it possible for Password Manager to manage passwords and accounts on target systems without installing a server-side agent.
Each Password Manager application server requires a web server. IIS is used as it comes with the Windows 2016 & Windows 2012 Server OS.
Password Manager is a security application and should be locked down accordingly. Please refer to the Hitachi ID document about hardening Password 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):
- No ASP, JSP or PHP are used, so such engines should be disabled.
- Web-facing .NET is not used and should be disabled (some connectors require it, due to .NET API bindings).
- No ODBC or DCOM are required inbound, so these services should be filtered or disabled at the web server. As with .NET, ODBC is sometimes needed to connect to target systems.
- Inbound file sharing should be disabled.
- Remote registry services should be disabled.
- Inbound TCP/IP connections should be firewalled, allowing only port 443, remote desktop services (to configure the software) and a handful of ports between Password Manager servers, mainly for data replication.
Each Password Manager server requires a database instance. Microsoft SQL 2016 is the recommended choice. Microsoft SQL 2014 and 2012 are also supported. Oracle database was supported on versions up to 9.0.x and is not supported on 10.0 or later releases.
- Hardware requirements or equivalent VM capacity:
- Intel Xeon or similar CPU. Multi-core CPUs are supported and leveraged. Dual core is a minimum.
- At least 16GB RAM -- 32GB or more is leveraged and is typical for a server.
- At least 600GB of HD storage, preferably in an enterprise RAID
configuration for reliability and preferably larger for retention
of more historical and log data.
More space is always better, to increase log retention.
- At least one Gigabit Ethernet NIC.
- Operating system:
- Windows Server 2016 (recommended) or 2012 (still supported, but not in the next release).
- All available service packs and hotfixes should be applied (automatically).
- It is recommended that the server is not a domain controller.
- Core mode on Windows Server is supported.
- Installed and tested software on the server:
- TCP/IP networking, with a static IP address and DNS name.
- IIS web server with a valid SSL certificate and the following configured: CGI, HTTP redirect, URL Rewrite, and Dynamic Compression.
- At least one web browser (i.e. Chrome) and PDF viewer.
- Python 3.5.3 (64-bit).
- A Git client (for revision control).
- A Microsoft SQL Server 2016 (recommended), 2014 or 2012 instance
is required to host the Password Manager schema:
- Normally one database instance per application server.
- The SQL Server database software can be deployed on the same server as the Password Manager application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes.
- SQL Server 2016, 2014 or 2012 Standard is recommended in almost all cases -- SQL Express is acceptable for small deployments and evaluations.
Password Manager requires SQL Server, typically with one database instance per application server. In most environments, the Microsoft SQL Server software is installed on the same hardware or VM as the Password Manager software, on each Password Manager server node. This reduces hardware cost, eliminates network latency and reduces the security surface of the combined solution.
Be sure to install the following components that come with Microsoft SQL Server 2016, 2014 and 2012:
- Database Engine Services
- Client Tools Connectivity
- Management Tools - Basic
- Management Tools - Complete
Database I/O performance on a virtualized filesystem (e.g., VMDK or equivalent) is slow. If the database server software runs on a VM, please use a fast, nearby NAS or SAN to store the actual data files.
Password Manager can leverage an existing database server cluster, but Hitachi ID recommends a dedicated database server instance, preferably one per Password Manager application server, installed on the same OS image as the core application.
- The data managed by Password Manager is extremely sensitive, so it is
desirable to minimize the number of DBAs who can access it (despite
use of encryption).
- SQL Server has limited features to isolate workloads between
database instances on the same server. This means that a burst of
activity from Password Manager (as happens during auto-discovery)
would cause slow responses in other applications. Conversely, other
applications experiencing high DB load would slow down Password Manager.
- Password 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.
- Deploying the database to localhost has performance advantages (minimal
packet latency from the application to its storage).
- Allowing Password Manager administrators full control over the database
simplifies performance and related diagnostics and troubleshooting,
especially when we consider that database administrators in most
organizations are few in number and very busy.
- Eliminating reliance on shared database infrastructure also eliminates the need to coordinate events such as database version upgrades, which involve reboots. Some Hitachi ID customers who leverage a shared database infrastructure have experienced application disruption due to unscheduled and uncommunicated database outages and restarts.
The Password Manager replicating data service can be configured to use the following SQL database engines as its physical data store:
- Microsoft SQL Server 2016/2014/2012, Standard Edition.
- Microsoft SQL Server 2016/2014/2012, Express Edition, with Advanced Services (free download from https://www.microsoft.com/en-ca/) -- suitable for development, test and very small production environments.