Prerequisites

The following summarizes the minimum software and hardware requirements for deploying Hyper-scalable PAS. Requirements may vary based on your scale out and performance needs; for details see Scaling and High Availability

Database

The database configuration, at a minimum, must have a PostgreSQL-compatible server or cluster with a network reachable service for each Installation. That is, each site (or Installation for a hostname) requires its own database server.

Additional requirements for the PostgreSQL server are noted below:

• PostgreSQL server version 14.9 (or a higher version of 14) or PostgreSQL server version 15, or a managed PostgreSQL service from Amazon Web Service (AWS), Microsoft Azure, or Google Cloud Platform (GCP). Managedservices include: Amazon Relational Database Service (RDS), Amazon Aurora, Azure Database for PostgreSQL, Cloud SQL for PostgreSQL

  Your site specifications for CPU, RAM and disk space are really dependent on workload. However, the server running PostgreSQL at a minimum should include:

  • CPU—a quad-core 2+GHz Intel i7 CPU or equivalent
  • RAM—16GB
  • Disk space—1TB (The amount of disk space in your system is dependent on the amount of data at your site.) Also note that the disk should include priority on disk speed (such as a RAID of SSDs), and RAM (for shared buffer caching) over CPU.

• The following PostgreSQL extensions:

  • postgres_fdw

    postgres_fdw is a foreign data wrapper used to access data stored in remote PostgreSQL servers. See https://github.com/postgres/postgres/tree/master/contrib/postgres_fdw for installation instructions.

The PostgreSQL extensions often come standard if you are using a managed PostgreSQL service.

You can run the following query from a psql prompt to make sure the proper extensions are installed:

If support for older versions of PostgreSQL require the use of the deprecated PLV8 the following query can be executed to validate the PLV8 extension is in use.

select * from pg_available_extensions where name in ('plv8','postgres_fdw');

• An administrative account with credentials for the database and open port access.

  The username, password, URI and port may be passed to the Centrify-PAS-NewInstallation command.

  Password authentication supports scram-sha-256 or MD5 for PostgreSQL.

• No Privileged Access Service tables should exist in the database server. If tables do exist, you will need to use the -overwrite flag when issuing the installation command.

• SSL is supported through the -DBSSL switch:

  • If PostgreSQL is configured to use SSL, the port specified with DBPort must be the SSL port.
  • If -DBSSL is specified, the database server certificate authority chain will be verified, which will fail if the client (the Management, Web, or Background node) does not have all related certificates. -DBTrustServerSSL may be used to bypass this check, especially for private authority certificates.

HSPAS Compatibility Matrix

The following table outline the supported PostgreSQL versions for each HSPAS release: 

	PG 14	PG 15
RHEL 7.9 EOL June, 3 2024	Not supported	Not supported
RHEL 8.x	Not supported	Not supported
RHEL 8.x w/PLV8	Not supported	Not supported
RHEL 9.2	Not supported	Supported on HSPAS 23.1 HF8
Win 2022	Supported HSPAS 22.3 and 23.1.2	Not supported
Win 2019	Supported HSPAS 22.3 and 23.1.2	Not supported
Win 2016	Supported HSPAS 22.3 and 23.1.2	Not supported

Install the PostgreSQL 15 Database on RHEL 9.2

To install the HSPAS application on a RHEL 9.2 system with a PostgreSQL 15 database, you will need to complete the following steps: 

1. Install the RHEL 9.2 operating system on your server.

2. Subscribe your RHEL 9.2 account with a valid account or activation key.

3. Download PostgreSQL 15 using the instructions from the official PostgreSQL download page located here:
   https://www.postgresql.org/download/linux/redhat/

4. Run the following command to set a password for the PostgreSQL user: 

   Copy

   [user@localhost ~]$ sudo -u postgres psql 
   postgres=# ALTER USER postgres PASSWORD '<Enter a password>';

5. Open port 5432 to allow remote connections to the PostgreSQL database.

6. Run the following command to install the PostgreSQL 15 library: 

   Copy

   [user@localhost ~]$ sudo yum install postgresql15-contrib

7. Run the following command to check if the 'postgres_fdw' extension is installed: 

   Copy

   [user@localhost ~]$ sudo find /usr -name postgres_fdw.control

8. Run the following commands to enable the 'postgres_fdw' extension in the PostgreSQL database: 

   Copy

   [user@localhost ~]$ sudo -u postgres psql
   postgres=# Run CREATE EXTENSION postgres_fdw;

Cache

The caching system, at a minimum, must be a Redis server with a network reachable service for each site and must meet the following requirements:

• At least 2GB of RAM.
• Redis version 4 or above.
• Endpoint is only used for Hyper-scalable PAS.

Refer to the Redis enterprise software overview fore more information on Redis enterprise software.

The following are supported in addition to your hosted Redis service:

• Amazon Web Service (AWS)
• Azure
• Google Cloud Platform (GCP)

Redis is a high-speed cache and is ideally run in a protected network, without passwords or encryption to slow it down. If encrypted communications and protected endpoints are required, both SSL and access key passwords are supported.

The same SSL constraints on PostgreSQL apply to Redis. -RedisSSL may be used to require SSL, but then the specified port must be SSL and the server certificate authority chain will be verified. You can use -RedisTrustServerSSL if necessary to bypass that.

Web SSH and RDP do not support trust bypass for the Redis certificate.

Redis also supports a password (also known as an “access key”), which may be set using -RedisPassword. Due to command-line constraints, the password may not include quotes, semi-colons, pipes, or other console-impacting special characters.

Load Balancer

A network load balancer (layer 4 – i.e. not a layer 7 or application load balancer) supporting transparent source/target IP and transparent pass-through of SSL (HTTPS) traffic. While Hyper-scalable PAS does transmit via HTTPS, the load balancer must be configured to handle TCP, rather than HTTPS, on port 443; this allows the data encryption to survive the full path between client and server, ensuring security and integrity. Health checks are by HTTPS endpoint.

Load balancers that cannot pass through SSL traffic without decrypting it, such as Amazon's Layer 7 ELB, do not work as they break the full-chain authentication. However, an Amazon Network Load Balancer (ALB) can be configured to pass SSL traffic without decrypting it.

In some cases, load balancers that operate on a different layer or that do not preserve source/target IP, may work, but may impact specific functionality. The load balancer should support dynamically adding and removing servers based on their health check and type.

Certificates for Privileged Access Service Authentication

The primary PAS server in the cluster must contain a certificate that is used for authentication between the PAS and all endpoints that use the PAS (such as enrolled devices, clients, browsers, connector computers, and so on).

The certificate must be for the PAS URI (for example, vault.mycompany.com). This is necessary because all endpoints will use the PAS URL host name to access the PAS. All endpoints must trust the certificate authority that issues the host certificate.

When you install the PAS on the primary server in the cluster, you can choose to specify an existing trusted host certificate, or create a new, self-signed certificate. In a production environment, it is recommended that you specify an existing trusted host certificate. The option to create a self-signed certificate during installation is provided mostly for demonstration purposes, and is not intended for use in production environments.

To ensure that endpoints trust the PAS host certificate, the certificate that you specify during installation should be from a known third-party certificate authority (for example, GoDaddy, Verisign, and so on).

During PAS installation on the primary server, you will see the following certificate prompt:

Would you like to provide a custom host certificate, if not, one will be generated for you?

Respond to this prompt in one of these ways:

• To use an existing host certificate from a trusted third-party certificate authority, enter Y (yes). You will then be prompted for the location and file name of the certificate.

• To create a new self-signed certificate for demonstration purposes, select N (no). A new certificate will be created as part of the installation process.

  If you choose N (no), you will not be able to install the Connector on a separate computer unless the self-signed certificate and root are trusted on the domain.

During PAS installation on secondary servers, you are not prompted for a certificate because certificate information is obtained from a cluster configuration file that is created during primary server installation.

After installation, you can change to a different certificate by executing the update_host_cert.ps1 script as described in Updating or Replacing a Web Server Certificate.

Supported Redis Versions

Hyper-scalable Privileged Access Service supports Redis versions 4 or greater and has been verified with the following Redis versions:

Redis 4.0.14

Redis 6.0.6

Redis 6.0.10

Ensure your machine meets the minimum requirements for your version of Redis.

License Key

Obtain an Hyper-scalable PAS license key that is specific to your company. During installation, you are required to provide your company name and the license key that is bound to the company name. Contact a IBM Security representative if you do not have a Hyper-scalable PAS license key.

Web, Background, TCP Relay, and Management Nodes

All nodes can be physical, virtual, or cloud instances and must be able to communicate with each other, the database, and the cache (Redis) node. For information on scaling your environment, see Scaling and High Availability. CPU and memory requirements may need to increase as you add users, especially for the Web nodes. The nodes used to run Hyper-scalable PAS must meet the following requirements.

System Requirements

• (General minimum): one Windows Server 2016 or 2019 computer for each node type (Web node, Background node, TCP Relay node, and Management node).

• (HA configuration minimum): at least two Windows Server 2016 or 2019 computers for each node type (Web, Background, and TCP Relay) and oneWindows Server 2016 or 2019 computer for the Management and Logging nodes for a total of 8 computers.

• Computer clock set to synchronize with a known accurate time source.

• Microsoft .NET Framework updated to version 4.8.

  All Hyper-scalable PAS Servers, including the Management node, must have .NET Framework 4.8 installed. As .NET Framework 4.8 is notinstalled on Windows by default, you may have to manually install it. Seehttps://dotnet.microsoft.com/download/dotnet-framework/net48 for information.

• An entry in the Domain Name Server pointing to the load balancer that services the Web nodes.

Additional Management Node Requirements:

The Management node is not required for daily operation.

• Front-end web network accessibility.

• The PKCS #12 SSL certificate file in either .pfx (Personal Information

  Exchange) or .p12 format (successor format to .pfx) must be available during

  installation.

connector computer requirements:

See the Privileged Access Service online help for details regarding Installing the Connector. Ensure you enter the Centrify Privileged Access Service hostname when you register the connectors in your customer-managed Scalable PAS installation.

Network

Make sure your network segment and subnets are defined to allow communication between all nodes within an Installation. For network topology details, see Architectural Overview. Additional network requirements include:

• IP requirements:

  • The load balancer must have an IP address with an appropriate entry connecting the name (URI) to the address in the DNS.
  • The load balancer must be in network mode (layer 4)

• Port requirements

  • Web nodes must be able to accept SSL (port 443) connections from the load balancer node (all calls are SSL).
  • TCP Relay nodes receive connections over port 443, but do not need access to the cache (Redis) or database (PostgreSQL) servers.

• Access to the internet, or—if the computer is not connected to the

  internet—access to installation media for required software. For example,

  IIS, PowerShell, and other features.

Basic Port Requirements

The following table shows the basic port configuration for Hyper-scalable PAS incoming and outgoing component communication. For additional information on port assignments, see Review the Firewall Rules.

Component	Port Setting (Incoming)	Port Setting (Outgoing)
connector	--	443 to various nodes (additionally for AD, RDP, SSH, etc. see Review the Firewall Rules
Load balancer	443	443
Web nodes	443 (from the load balancer)	unrestricted (requires access to Cache Redis and Database PostgreSQL—subnet 443/6379/5432)
Background nodes	443 808	unrestricted (requires access to Cache Redis and Database PostgreSQL—subnet 443/6379/5432)
TCP Relay node	443 (can be limited for IP addresses from the connector and the Web and Background nodes)	443
Redis cache	6379	--
PostgreSQL database	5432	--

PowerShell Execution Policy

The default PowerShell execution policy may prevent the running of unsigned or remote-signed scripts. This will interfere with the execution of Hyper-scalable PAS.The current policy can be displayed with the PowerShell command Get-ExecutionPolicy. It can be set with:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

Scope could also be LocalMachine.

For more information on PowerShell policy, see: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.