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.
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: 11+, or a managed PostgreSQL service from Amazon Web Service (AWS), Microsoft Azure, or Google Cloud Platform (GCP). Managed services 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
- 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 (e.g., a RAID of SSDs), and RAM (for shared buffer caching) over CPU.
The following PostgreSQL extensions:
PLV8 version 2.X
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 PostgrSQL 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:
select * from pg_available_extensions where name in ('plv8','postgres_fdw');
Use the DBNoPLV8 switch to bypass PLV8 and turn FastDB off in settings. If you do not have the PLV8 extension available on the database server and do not use the switch, you will receive the following error "Install without requiring the PostgreSQL PLV8 extension. Warning: This bypasses significant database performance enhancement code." and Installation creation will stop. You must either add PLV8 to the database server or use the switch above. While it is not recommended to turn PLV8 on at a later date, to do so you must do the following: change the settings, add PLV8 to the database, and then build a new deployment.
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.
Note: Password authentication supports scram-sha-256 or MD5 for Postgres.
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 Centrify Management, Web, or Background node) does not have all related certificates. -DBTrustServerSSL may be used to bypass this check, especially for private authority certificates.
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.
Support for one of the following managed Redis services: Amazon Web Service (AWS), Azure, Google Cloud Platform (GCP).
Note: Refer to the Redis enterprise software overview to get more information on Redis enterprise software.
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 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.
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.
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.
Note: 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.
The primary Centrify PAS server in the cluster must contain a certificate that is used for authentication between the Centrify PAS and all endpoints that use the Centrify PAS (such as enrolled devices, clients, browsers, connector computers, and so on).
The certificate must be for the Centrify PAS URI (for example, vault.mycompany.com). This is necessary because all endpoints will use the Centrify PAS URL host name to access the Centrify PAS. All endpoints must trust the certificate authority that issues the host certificate.
When you install the Centrify 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 Centrify 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 Centrify 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.
Note: If you choose N (no), you will not be able to install the Centrify Connector on a separate computer unless the self-signed certificate and root are trusted on the domain.
During Centrify 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.
Note: 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.
Centrify Hyper-scalable Privileged Access Service supports Redis versions 4 or greater and has been verified with the following Redis versions:
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 Centrify representative if you do not have a Hyper-scalable PAS license key.
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.
- (General minimum): one Windows Server 2016 or 2019 computer for each node type (Web node, Background node, TCP Relay node, and Centrify Management node).
- (HA configuration minimum): at least two Windows Server 2016 or 2019 computers for each node type (Web, Background, and TCP Relay) and one Windows 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.
Note: All Hyper-scalable PAS Servers, including the Management node, must have .NET Framework 4.8 installed. As .NET Framework 4.8 is not installed on Windows by default, you may have to manually install it. See https://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 Centrify Privileged Access Service online help for details regarding Centrify Connectors. Ensure you enter the CentrifyPrivileged Access Service hostname when you register the connectors in your customer-managed Scalable PAS installation.
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.
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)|
443 to various nodes
(additionally for AD, RDP, SSH, etc. see Review the firewall rules)
(from the load blancer)
(requires access to Cache Redis and Database PostgreSQL—subnet 443/6379/5432)
(requires access to Cache Redis and Database PostgreSQL—subnet 443/6379/5432)
|TCP Relay node||
(can be limited for IP addresses from the Centrify Connector and the Web and Background nodes)
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
Note: 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.