Configure multiple domain controllers with Sophos ZTNA

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.

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, licensing, and roles

The following points should be in place before configuration:

Sophos Fusion (formerly 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 Fusion under My Environment > Computers & Servers > <Device> > Summary. Under Assigned Products and Installed component versions, verify whether the pilot device already uses the required version.

Before making changes, verify that ZTNA > Resources & Access is available in the tenant and that the administrator account in use is allowed to add and edit resources there. If the menu item or button is missing, do not proceed with an assumed role or license. Instead, clarify the ZTNA permission and subscribed scope in your tenant or with the responsible Sophos partner.

How to add resources: create each domain controller

Create each DC separately as a Domain Controller with an agent-based access method:

In Sophos Fusion, open My Products > ZTNA > Resources & Access and select Add Resource.
Enter a unique name and a short description, such as dc01-example and Domain controller Zurich site.
Leave Show resource in user portal enabled according to the required user access.
Select the responsible Gateway.
For Access method, select Agent and assign the appropriate agent-based Policy.
For Resource type, select Domain Controller (DC).
Under External FQDN, enter the full name of this DC, such as dc01.example.com—not only the root domain example.com.
Enter an Internal FQDN/IP address only if the internal destination differs from the External FQDN. Without a value, Sophos automatically uses the External FQDN.
Review the ports added automatically and only add services that this environment actually requires.
Under Advanced Domain Controller settings, review the SRV records.
Under Assign User Groups, move every group that needs resources behind this DC from Available User Groups to Assigned User Groups.
Select Save, then test the DC with a Windows pilot device.

Agentless resources and agent-based resources require different DNS records. Sophos does not create an alias domain for an agent-based DC resource. Therefore, do not create either a public CNAME or a wildcard DNS record for the DC; the External FQDN must not be publicly available either. A gateway CNAME required for the Sophos Cloud Gateway is unaffected. The ZTNA Agent intercepts the configured FQDN on the endpoint. IP-based access is not automatically captured by this mechanism.

Check DNS records and 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.

Sophos additionally lists the following ports for this resource type:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (the German-language Sophos help labels this line UCP)

The general resource form asks you to Specify the port type and port number (for example, HTTPS and 443 for a web app). For a domain controller, the required TCP and UDP services apply instead.

Do not adopt the unusual UDP values without review as a general AD recommendation. They come from the current Sophos resource guide; what matters is which services your own DC actually offers and which connections your AD function requires. A resource can contain up to 20 TCP and UDP port entries in total. Enter ranges with a hyphen and multiple entries separated by commas, for example 49152-65535.

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

the ports automatically preconfigured in the current Sophos Fusion 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.

For latency-sensitive CIFS or SMB file shares, Sophos recommends a local gateway. This does not change the required port and function checks, but shortens the data path compared with a Cloud Gateway.

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 production DCs. Instead, use two time-limited network rules scoped to the pilot device to isolate the paths to dc01.example.com and dc02.example.com without affecting other clients. TTL and local DNS and DC caches may delay failover, so allow for the configured TTL and cache delay in the test schedule.

While both Priority 1 DCs are isolated, use Resolve-DnsName to confirm that the SRV response contains dc03.example.com at Priority 2, use nltest /dsgetdc:example.com /force to prove that dc03 is selected, and successfully complete the real AD-dependent sign-in or application workflow. Then remove both test rules, allow again for cache delay, and use SRV resolution, nltest, and the same workflow to confirm that selection returns to dc01 or dc02 in the Priority 1 group.

When no domain controller is reachable

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

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

Access by FQDN fails, but access by IP address works

The ZTNA Agent intercepts resources only on an FQDN basis. Direct IP access can therefore bypass ZTNA and is not a successful ZTNA test. Repeat the access using the name entered under External FQDN. If users must reach internal resources exclusively through ZTNA, also block the direct IP path with suitable firewall rules.

A renamed Entra ID group no longer has access

If an already assigned Microsoft Entra ID group is renamed later, Sophos does not automatically update the resource’s group list. Reassign the affected group under Assign User Groups, save, and test access with a member of that group.

The external FQDN resolves publicly

For an agent-based resource, the external FQDN must not be publicly available. This is the opposite of an agentless resource, whose external FQDN must be publicly available. Therefore, check DNS publication and Access method together; for the DC resource described here, the access method remains Agent.

Multiple users intermittently lose AD connectivity

ZTNA Gateway 2.2 has known issue NZT-10022: The gateway websocket server may intermittently drop large AD packets. As a result, multiple users may appear to lose AD connectivity at random, or Kerberos, RDP, Windows file shares, and other AD-backed applications may respond slowly or fail. The bounded workaround is an MTU of 1420 bytes on the affected endpoint’s Sophos ZTNA TAP adapter; don’t set this value proactively on every device.

Make the change first on a pilot device from a PowerShell session running as administrator. Beforehand, record the alias and original MTU for IPv4 and IPv6:

Get-NetIPInterface | Where-Object InterfaceAlias -Like '*Sophos*ZTNA*TAP*' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Replace <TAP-ALIAS> with the displayed alias, set the MTU, and confirm the effective value:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -NlMtuBytes 1420
Get-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Then reconnect ZTNA and repeat the Kerberos, RDP, or file-share operation that previously failed several times. If the failure remains or other connectivity problems appear, restore the recorded values; replace <ORIGINAL_MTU> with the original value for each address family:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv4 -NlMtuBytes <ORIGINAL_MTU>
Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv6 -NlMtuBytes <ORIGINAL_MTU>

If the first query returns no adapter, use Get-NetAdapter to identify the exact alias and don’t modify another interface. If the MTU reverts after reconnection or restart, or 1420 doesn’t clearly help, don’t keep lowering it. Instead, collect the gateway and endpoint versions, affected users and services, timestamps, the MTU before and after the change, and a packet capture, then escalate the case with NZT-10022.

Microsoft documents the port requirements for the Windows services in use under Service overview and network port requirements.

Safe rollback and offboarding

Do not remove a DC resource during an active sign-in or production failover test. First record the assigned user groups, ports, SRV records, Priority, and Weight, and verify that at least one tested DC in the same priority group or the intended fallback DC remains reachable.

To reverse a change, open My Products > ZTNA > Resources & Access and select the resource name. There you can edit the resource details or remove the resource. First restore an incorrect change to ports, SRV values, or groups to the recorded initial values and save. Remove a resource only when users and applications no longer need its FQDN.

Then recheck SRV resolution, nltest /dsgetdc:example.com /force, and the affected sign-in or application workflow on the pilot device. If no tested DC remains reachable, stop before removal and escalate with the saved values. A completed removal cannot be undone. If the resource has already been removed, a qualified administrator may only recreate it manually from the recorded settings, reassign the groups, and then repeat the full validation. If resource identity or state must be preserved, or the records are incomplete, do not recreate it; escalate the case.

Operations, review, and lifecycle

Priority, Weight, and TTL belong in the AD environment’s operational documentation. Review the assignment after changes to DC sites, FQDNs, offered services, ports, or user groups. Reassigning a renamed Entra ID group is a separate operational step; no automatic update takes place.

No specific migration, retirement, or end-of-life instruction is documented for this function. After product updates, first check the current resource help and the fields visible in the tenant, then validate changes again on a limited pilot device.

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.