Network connectivity requirements
IPv6 Support
Trust Protection Foundation supports the IPv6 protocol across the product with one exception: for network discovery, IPv6 is not supported for network discovery jobs.
Network access requirements
Platform requirements
There are a number of systems that require network access to be enabled for Trust Protection Foundation to run.
- All Trust Protection Foundation servers need access to the database server
- If using an HSM to (1) encrypt private keys, credentials, and other secrets stored in the CyberArk database, or (2) for the central generation or storage of private keys, all Trust Protection Foundation servers need access to the HSM.
- If using an identity provider, like Active Directory or LDAP, all Trust Protection Foundation servers need network access to the identity infrastructure.
- Each Trust Protection Foundation server that has the Event Processing component enabled must have access to the configured logging channels. For example, email server, syslog, SMTP, etc.
- For each Trust Protection Foundation server that has a web service enabled (e.g. UI consoles, Web SDK, Agent service, etc.), all clients that are connecting to the service must have network access to the Trust Protection Foundation server, either directly or through a proxy.
Feature-specific requirements
Most features in Trust Protection Foundation can be configured to only use a subset of servers to use that feature. For example, when integrating with a certificate authority, the Trust Protection Foundation server(s) integrated with that certificate authority need network access to connect to that certificate authority, but other servers in your cluster would not need that access.
There are three ways you can control what Trust Protection Foundation servers need access:
- Processing engines. For more information see Management Zones.
- Network discovery zones. For more information see Configuring discovery zones.
- Turning off the associated component on a specific server's CyberArk Configuration Console. For more information see Trust Protection Foundation components.
Most product features have a Network Access component for the feature. We recommend you review what features you plan to use, as well as which Trust Protection Foundation server(s) will be responsible for these features, and configure network access accordingly.
Port requirements
Depending on your environment, Trust Protection Foundation can use the following ports:
|
Port |
Description |
|---|---|
|
Default Port Assignments |
|
|
80 |
While CyberArk Trust Protection Foundation - Self-Hosted provides several methods of ensuring encryption of traffic, Port 80 binding is ONLY required if you are using SCEP or the Time Stamp Service endpoints, as these features require http access to the internet to function correctly. If you are not using SCEP, and you don't care if the Time Stamp Service endpoints in Code Sign Manager - Self-Hosted can get time stamping data, you can disable Port 80 binding in IIS. All other CyberArk web services will continue to function if access to port 80 is blocked. |
|
443 |
Hyper Text Transfer Protocol Secure (HTTPS) should be enabled if Policy Tree is secured with a certificate. |
|
50443 |
This port is used by Trust Protection Foundation to handle certificate requests via Enrollment Over Secure Transport (EST) protocol. Allow this port only on servers which will handle such requests. |
| 8883 | This is the IANA-assigned port for encrypted (TLS) MQTT connections between servers in the cluster using the Message Bus feature. By default, Message Bus uses this encrypted port. If you opt for unencrypted communication, the IANA-assigned port is 1883. |
|
Operational Port Assignments |
|
|
135 |
Trust Protection Foundation communicates with the Microsoft Certificate Services and the server hosting Internet Information Services over DCOM. The default DCOM port is 135 (dynamic port range 49152-65535). Trust Protection Foundation contacts the IIS application on port 135; however, the application returns its response on a different port. This can pose a problem in a firewall environment. For information on configuring DCOM with firewalls, see the following Microsoft Technical Document: http://support.microsoft.com/kb/154596. |
|
21 |
Port 21 can be used for sending reports via the FTP protocol. Reports can also be sent using the SMB protocol (port 445). |
|
22 |
Trust Protection Foundation uses the Secure Shell protocol (SSH) to communicate with servers and appliances. The default SSH port is 22. SCP and SFTP run as subsystems of SSH on port 22. Trust Protection Foundation supports Open SSH and Tectia SSH versions 4 and 5.3.x. |
|
25, 587 |
Trust Protection Foundation uses the Simple Message Transfer Protocol (SMTP) to communicate with a configured email server to send email notifications. The default SMTP port is 25. |
|
161 |
Trust Protection Foundation uses the Simple Network Management Protocol (SNMP) channel to send selected events to an SNMP management system via an SNMP trap. |
|
445 |
Port 445 can be used for sending reports via the SMB protocol. Reports can also be sent using the FTP protocol (port 21). |
|
514 |
The CyberArk Log server can send log messages to a syslog server. By default, the Syslog channel uses UDP port 514, but an administrator may configure an alternate port in the Syslog channel configuration. The Log server can also use TLS for sending Syslog messages, if configured. For more information, see About syslog channels. |
|
Default Database Ports |
|
|
1433 |
For more information on running the Trust Protection Foundation database on a Microsoft SQL system, see Setting up your Microsoft SQL database server. |