Skip to content
Avanet

Configure multiple domain controllers with Sophos ZTNA

Zero Trust Network Access

When Windows devices need to reach Active Directory through Sophos ZTNA, a single domain controller creates an avoidable single point of failure. Starting with Sophos Endpoint 2026.1, ZTNA supports multiple DC resources with priority and weighting. This allows two domain controllers to be used during normal operation and another DC to serve as a fallback.

Each domain controller is created as a separate agent-based resource of the Domain Controller (DC) type. Sophos ZTNA provides the connection and responds to the relevant DNS SRV queries on the endpoint. The existing AD structure, DNS resolution, and trust relationships remain the responsibility of the Active Directory environment.

For the general setup sequence, start with Set up Sophos ZTNA: overview and sequence. Plan and create a Sophos ZTNA Gateway explains planning, DNS, and gateway connectivity.

Distinguishing DC resources from the identity provider

Multiple DC resources do not automatically mean that the ZTNA identity provider can authenticate users from multiple independent AD domains.

  • DC resources carry DNS, Kerberos, LDAP, and other required AD traffic through the ZTNA tunnel.
  • The identity provider authenticates the user for ZTNA. With the local Microsoft AD identity provider, Sophos still supports one domain; the Primary and Secondary AD Servers must belong to the same domain.
  • AD DNS and forest trusts must already work. ZTNA does not create DNS forwarding, trust relationships, or cross-domain user synchronization.

This makes the function directly suitable for multiple DCs in the same domain. With multiple domains or forests, it is also necessary to verify whether the identity provider, DNS, and existing trusts actually support the planned access.

Requirements

The following points should be in place before configuration:

  • Sophos Central with an active ZTNA license.
  • A configured ZTNA Gateway that the endpoint can reach.
  • Windows devices with the ZTNA Agent and Sophos Endpoint 2026.1 or later.
  • Synchronized user groups and a suitable agent-based ZTNA Policy.
  • A unique FQDN for each domain controller, such as dc01.example.com.
  • Connectivity from the ZTNA Gateway to every DC over the AD services actually required.
  • Working internal DNS resolution and existing trusts and DNS forwarding for multiple domains or forests.

The endpoint version is shown in Sophos Central under My Environment > Computers & Servers > <Device> > Summary. Under Assigned Products and Installed component versions, verify whether the pilot device already uses the required version.

Creating each domain controller as a resource

Create a separate resource for each DC:

  1. In Sophos Central, open My Products > ZTNA > Resources & Access and select Add Resource.
  2. Enter a unique name and a short description, such as dc01-example and Domain controller Zurich site.
  3. Select the responsible Gateway.
  4. For Access method, select Agent.
  5. Assign the appropriate agent-based Policy.
  6. For Resource type, select Domain Controller (DC).
  7. Under External FQDN, enter the full name of this DC, such as dc01.example.com—not only the root domain example.com.
  8. Enter an Internal FQDN/IP address only if the internal destination differs from the External FQDN. Without a value, Sophos uses the External FQDN.
  9. Review the ports added automatically and only add services that this environment actually requires.
  10. Under Advanced Domain Controller settings, review the SRV records.
  11. Under Assign User Groups, assign the groups that need AD services through this DC.
  12. Save the resource, then test the DC with a Windows pilot device.

Sophos does not create a Resource Alias for an agent-based DC resource. Therefore, do not create a public CNAME or a wildcard DNS record for the DC, and the External FQDN must not be publicly available. A gateway CNAME required for the Sophos Cloud Gateway is unaffected. The ZTNA Agent intercepts the configured FQDN on the endpoint. Direct access through the IP address is not automatically captured by this mechanism.

Checking ports for the environment

The Domain Controller (DC) resource type automatically adds a range of ports. This list is a starting point, not a substitute for checking the AD functions actually in use. A simple LDAP test requires different connections from a Kerberos login, Group Policy, DNS, SMB, or dynamic RPC.

Static port lists should therefore not be adopted blindly. The decisive factors are:

  • the ports automatically preconfigured in the current Sophos Central interface,
  • the services and ports used under Advanced Domain Controller settings,
  • Microsoft’s port requirements for the AD functions used in this environment,
  • connectivity from the ZTNA Gateway to the respective DC over these ports.

If a required port is missing from the resource’s regular port field, a matching SRV record in the advanced settings alone is not sufficient. The connection may then fail despite a correct DNS response.

Understanding SRV priority and weighting

Active Directory uses DNS SRV records so that clients can find an appropriate service and domain controller. Sophos ZTNA represents these records under Advanced Domain Controller settings.

The most important fields are:

  • Services: AD service, such as LDAP or Kerberos.
  • Domain name: DNS domain to which the SRV record applies.
  • Protocol: TCP or UDP.
  • Port numbers: Port of the respective service, such as 389 for LDAP or 88 for Kerberos.
  • Priority: A lower number means a higher priority. DCs with the lowest available priority are used first.
  • Weight: Distributes selection among DCs with the same priority.
  • TTL: Time in seconds for which a response may be cached. The default value 86400 is 24 hours.

Priority therefore determines the preferred group. Weight only influences selection within the same group. It does not guarantee an exact percentage distribution of traffic because DNS caching, client behavior, and the number of requests also affect the result.

Example with two active DCs and one fallback DC

For the example.com domain, normal load should be distributed across two DCs. A third DC is used only as a fallback:

  • dc01.example.com: Priority 1, Weight 60
  • dc02.example.com: Priority 1, Weight 40
  • dc03.example.com: Priority 2

Because they have the same Priority, dc01 and dc02 belong to the preferred group. Their weighting controls their approximate selection at a ratio of 60 to 40. dc03, with Priority 2, is only considered when no DC with Priority 1 is available.

All three resources need suitable SRV records for the same domain and the services actually required. However, the higher numeric value 2, and thus the lower selection priority, does not automatically make dc03 a complete replacement: replication, DNS, the Global Catalog role, and reachable AD services must also be suitable for the intended failover.

Testing the function on a Windows device

First, check the SRV response for the required domain:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.example.com

The response should contain the configured domain controllers with Priority and Weight. Then force a new DC lookup:

nltest /dsgetdc:example.com /force

nltest shows the selected reachable DC, but not necessarily all available destinations. Therefore, also test the connection to individual services:

Test-NetConnection dc01.example.com -Port 389
Test-NetConnection dc02.example.com -Port 389
Test-NetConnection dc03.example.com -Port 389

In this example, port 389 tests LDAP over TCP. Kerberos, DNS, SMB, or RPC require tests appropriate to the actual use case. A complete acceptance test also includes a real Windows login or access to the application that requires AD through ZTNA.

For a packet capture on the endpoint, this Wireshark filter exclusively shows DNS SRV queries:

dns.qry.type == 33

A failover test belongs on a pilot device and in a maintenance window. Do not shut down a production DC for this purpose; instead, interrupt the primary path in a controlled manner only for the test. Then recheck nltest, SRV resolution, and the affected application. After changes to Priority or Weight, TTL and local DNS caches may delay the result.

When no domain controller is reachable

For an outage, check the following points in this order:

  1. Is each DC created as a resource with Access method: Agent and Resource type: Domain Controller (DC)?
  2. Does External FQDN use the specific DC name and not only the AD domain?
  3. Are the domain, service, protocol, port, Priority, and Weight of the SRV records correct?
  4. Are all ports used there also included in the resource’s regular port field?
  5. Can the ZTNA Gateway reach every DC over these ports?
  6. Are the pilot users, groups, and Policy assigned correctly?
  7. Does the Windows device run Sophos Endpoint 2026.1 or later?
  8. Do Resolve-DnsName, nltest, and dns.qry.type == 33 show the same DCs as Sophos Central?

For ZTNA Gateway 2.2, Sophos also lists NZT-10022 in the current Known Issues List: Large AD packets may be dropped intermittently. Possible symptoms include unreliable Kerberos, RDP, or file-sharing connections. Sophos lists an MTU of 1420 bytes for the Sophos ZTNA TAP adapter as the workaround. This change applies only to this specific issue and should not be set proactively on all devices.

Sophos provides the official field descriptions and the current interface under Add resources. Microsoft documents the port requirements for the Windows services in use under Service overview and network port requirements.