Adaxes network usage

Adaxes performs a variety of operations over the network. For example, it sends LDAP queries to your domain controllers and HTTPS requests to Microsoft Entra servers. This article will help you better understand what network activity to expect from Adaxes components and what ports must be open for those components to function without issues.

Active Directory management

Adaxes uses the following ports to communicate with your domain controllers and manage registered Active Directory domains.
For every domain registered in Adaxes, these ports must be open between:

• Domain controllers – local ports for inbound traffic.
• Computer where Adaxes service is installed – remote ports for outbound traffic.

In addition, ICMP Echo Requests from the computer with the Adaxes service to domain controllers must be allowed. Adaxes uses ICMP ping when an LDAP request to a domain controller is pending for extended time, to verify the domain controller is still available.

Restricting dynamic RPC ports

It is strongly recommended to allow communication between Adaxes service and domain controllers over the full dynamic RPC port range. In practice, this range can be reduced. The absolute minimum that doesn't break Adaxes functionality is opening only the 49668 port where the Netlogon service typically listens.

That being said, reducing the number of available dynamic RPC ports has a direct and noticeable impact on performance. A more practical range is having at least 500 available RPC ports, including port 49668. Anything fewer, and you start aggressively trading stability and performance for little to no real security benefit. Reducing the range to one or just a few ports should be reserved for restricted network environments where it is non-negotiable.

Restricting allowed domain controllers

By default, Adaxes relies on the Domain Controller (DC) locator algorithm to discover domain controllers in a managed domain. As a result, it may connect to any available DC, which may not be desirable. Restricting this behavior with firewall rules alone is not recommended. Firewall rules block the connection itself but do not prevent connection attempts, which can lead to timeouts and performance degradation.

Instead, you can configure Adaxes to only use specific domain controllers. In environments with multiple Adaxes services sharing common configuration, each service can be configured to use different domain controllers.

Enabling SSL for all traffic

In some scenarios, unencrypted LDAP traffic over port 389 between Adaxes and domain controllers may not be acceptable. For example, managed service providers (MSPs) may need to connect to customer domain controllers from an internal Adaxes server over the Internet. In such cases, you can enforce SSL for a managed domain, and avoid exposing the 389 port.

This option should be used with care, and only when strictly required by network security policies. Active Directory is designed to operate over LDAP. Forcing all communication over LDAP with SSL introduces additional computational overhead and will result in performance degradation.

Entra ID management

To manage an Entra domain or a Microsoft 365 tenant, Adaxes must be able to communicate with Microsoft servers. The computer where Adaxes service is installed must allow outbound TCP traffic over port 443 to the URLs of the national cloud where your tenant resides.

Exchange management

If any of the domains registered in Adaxes have on-premises Exchange, the following ports must be open between the computer where Adaxes service is installed and your Exchange servers. Traffic is outbound from the Adaxes service and inbound on the Exchange servers.

By default, Adaxes may connect to any Exchange server in any managed domain. You can change the default behavior and configure Adaxes to only connect to specific Exchange servers.

Adaxes components

Adaxes supports distributed deployment scenarios – its components can be installed on separate servers. In such scenarios, every client component must be able to communicate with at least one Adaxes service.

Client components include:

• Web interface
• Administration console
• REST API
• SPML provider

Adaxes clients to Adaxes services

Adaxes services listen for client communication on a specific port.

This port must be open between:

• Computers with an Adaxes service instance – local port for inbound connections.
• Computers with Adaxes client components – remote port for outbound connections.

Adaxes clients to domain controllers

Adaxes clients perform all directory operations via the Adaxes service. However, the computer where a client component is installed must still be able to communicate with a domain controller over the default LDAP ports, like any other domain-joined computer.

Additionally, every Adaxes client must be able to communicate with the AD Global Catalog over TCP port 3268 if:

• The client is deployed in a domain not managed by the Adaxes service, and
• The client and the Adaxes service are deployed in different domains.

Administration console object lookup

Adaxes administration console allows you to look up and validate domain objects. For example, this feature can be used when selecting credentials for a managed domain, or specifying Run As credentials for a script.

Object lookup is performed through a direct connection between the administration console and a domain controller. The administration console must be able to connect to a domain controller over the following ports to look up objects in that domain.

This is not mandatory. All credentials can be entered manually, without object lookup and validation.

Adaxes services sharing configuration

You can install multiple Adaxes services sharing configuration. Each service stores the configuration replica in a dedicated AD LDS instance on the computer where it is installed. The configuration is replicated between instances using native AD LDS mechanisms.

The following ports must be open between all computers hosting Adaxes services that share configuration.

AD LDS backend port

This port is used by AD LDS for communication between instances within the same configuration set. Each Adaxes service also uses this port when connecting to its local AD LDS instance to read and modify configuration data.

By default, the AD LDS backend port is randomly selected from the 1025-65535 range during the installation of an Adaxes service. Typically, this results in every AD LDS instance having a unique backend port. If a service instance is reinstalled (for example, during an upgrade), a new random port will be assigned, which may not fit into your existing firewall rules.

Using a predictable backend port simplifies firewall configuration and avoids issues caused by random port changes after reinstallation.

msiexec /i "<path_to_package>\adaxes.msi" ADLDSPORT="<port>"

<configuration>
    ...
    <softerra.adaxes>
        <!-- Backend -->
        <backendInfo server="localhost:44444" xmlns="http://softerra.com/adaxes/config">
        ...
        </backendInfo>

AD LDS replication ports

AD LDS replicates over dynamic RPC ports. It is strongly recommended to allow communication between the computers where Adaxes services that share configuration are installed over the full dynamic RPC port range.

You can restrict AD LDS replication to a single predefined port, but this approach comes with drawbacks. It should be reserved for restricted network environments where it is non-negotiable.

• Replication ports can be restricted only after the installation. During the installation, all dynamic RPC ports must be open between the computer where you are installing a new Adaxes service instance, and all computers where Adaxes services from the same configuration set are hosted.

• AD LDS does not reserve the selected port. It is your responsibility to ensure that the port is never occupied by other applications. If the port is unavailable when replication is attempted, replication will fail.

• Expect performance degradation, as AD LDS will not be able to replicate high volumes of data by establishing multiple connections over several ports simultaneously.

Other

Adaxes can automatically check for product updates. To do this, the Adaxes service and the administration console must be able to reach the following URL.

https://adaxes.com/update/adaxes.xml