PCS Network Requirements

Privilege Control for Servers (PCS) requires network access between each managed server and several internal components. Use this topic to configure your firewall before you install the Privilege Control Agent.

This topic covers the Privilege Control Agent and the PCS components it relies on. For the Platform Agent, see Setting Up PCS with Platform Agent. For outbound access from your network to the Verify Privileged Identity Platform, see Network Requirements.

How the Privilege Control Agent Connects

The Privilege Control Agent joins its server to Active Directory (AD). The server then acts as an AD client. The agent communicates directly with your domain controllers to join the domain, authenticate users, and get policies.

The agent also connects to two internal components:

  • AD Connector: Receives agent multi-factor authentication (MFA) and proxy traffic.

  • Audit Collector: Receives session recordings. The Audit Collector is a workload that runs on the Verify Privileged Identity Platform Engine.

The AD Connector doesn't forward the agent's LDAP or Kerberos traffic to your domain controllers. Open ports to your domain controllers and to the AD Connector.

Reading the Port Tables

In this topic, an agent server is a Linux or Windows server where the Privilege Control Agent is installed.

Each table lists the source and destination of every connection. The source host starts each connection. A stateful firewall allows reply traffic automatically.

Agent Server to Domain Controller Ports

Open the following ports from each agent server to your domain controllers:

Source Destination Port Protocol Service Purpose
Agent server Domain controller 53 TCP/UDP DNS Resolves domain controller and service names.
Agent server Domain controller 88 TCP/UDP Kerberos Authenticates the server and users to AD.
Agent server Domain controller 123 UDP NTP Synchronizes server time with the domain. Kerberos authentication fails when clocks are out of sync.
Agent server Domain controller 389 TCP/UDP LDAP Queries AD for users, groups, and computers.
Agent server Domain controller 445 TCP/UDP SMB Accesses domain resources on the domain controller.
Agent server Domain controller 464 TCP/UDP Kerberos password change Processes password changes.
Agent server Domain controller 3268 TCP Global Catalog Searches directory data across the AD forest.

Windows agent servers are members of your AD domain. They also need the standard ports that Microsoft requires for domain members. See Service overview and network port requirements for Windows in the Microsoft documentation.

LDAP Port 389 and LDAPS

The Privilege Control Agent uses standard LDAP on port 389. It doesn't use LDAP over TLS (LDAPS) on port 636, or Global Catalog over SSL on port 3269.

LDAP traffic on port 389 is encrypted. The agent first authenticates to AD with Kerberos. It then signs and seals all LDAP traffic with a key negotiated through the Generic Security Services API (GSSAPI). Keep port 389 open, even if your organization prefers LDAPS.

The Privilege Control Agent works with the following Group Policy settings:

  • Domain controller: LDAP server signing requirements set to Require signing

  • Domain member: Digitally encrypt or sign secure channel data (always) set to Enabled

Because the agent uses GSSAPI instead of TLS, Microsoft's LDAP channel binding requirements (advisory ADV190023) don't affect it.

Agent Server to AD Connector and Audit Collector Ports

Open the following ports from each agent server to the servers that host the AD Connector and the Audit Collector:

Source Destination Port Protocol Service Purpose
Agent server AD Connector 8443 TCP (HTTPS) MFA Sends agent MFA requests.
Agent server AD Connector 8080 TCP (HTTPS) Proxy Proxies agent connections from the agent server to your Verify Privileged Identity Platform tenant.
Agent server Audit Collector 5063 TCP Session recording Sends session recordings to the Verify Privileged Identity Platform.

In a proof of value environment, one Verify Privileged Identity Platform Engine server usually hosts both the AD Connector and the Audit Collector. In that case, open all three ports to that server.

PCS Component to Domain Controller Requirements

PCS also relies on components that run on Windows servers in your AD domain: the AD Connector, and the Command Relay and AD Rapid Discovery workloads on the Verify Privileged Identity Platform Engine.

  • Join each server that hosts the AD Connector or the Command Relay to your AD domain.

  • Open the standard ports that Microsoft requires for domain members between these servers and your domain controllers. See Service overview and network port requirements for Windows in the Microsoft documentation.

The Command Relay also requires the following port:

Source Destination Port Protocol Service Purpose
Command Relay server Domain controller 9389 TCP Active Directory Web Services (ADWS) Creates, updates, and deletes PCS policies in AD.

The AD Connector and AD Rapid Discovery don't need any ports beyond the standard domain member ports.

Troubleshooting

No Writeable Domain Controllers Found

Issue:

Joining a Linux server to the domain fails with the error No writeable domain controllers found.

Cause:

The server can't reach a domain controller. The most common causes are DNS settings on the Linux server, or firewall rules that block the domain controller ports.

Resolution:

  1. On the Linux server, ping the fully qualified domain name (FQDN) of your AD domain.

  2. Confirm that the response returns the IP address of one of your domain controllers. If it doesn't, correct the DNS settings on the Linux server.

  3. Confirm that every port in Agent Server to Domain Controller Ports is open from the server to your domain controllers.

  4. Join the server to the domain again. See Joining Linux/UNIX Hosts to a Domain/Zone.

For more PCS issues, see Troubleshooting PCS.

Related Topics