Active Directory Domain Controllers
This guide covers how to make an on-premises Active Directory Domain
Controller (DC) reachable through XplicitTrust, so that domain-joined Windows
clients can perform domain logon, Group Policy processing, and access
SYSVOL/NETLOGON and mapped network drives over the tunnel.
The setup has a few parts: expose the DC as an Asset, make sure its DNS Server listens on the tunnel IP, point split DNS for the AD domain at it, and — easily overlooked — add the AD domain name itself to the asset's DNS Names.
Automated setup in the Admin Console
Once the agent runs on the DC in Asset Mode (step 1 below), the Admin Console recognises it as an Active Directory Domain Controller. The asset's side panel then shows a Domain Controller setup section at the top, naming the AD domain. Click Set up to open it. It lists the following steps:
| Step | What it does |
|---|---|
| Reserve UDP ports from the DNS Server | The Microsoft DNS Server reserves a large range of UDP ports for itself. This excludes 51800–60000 from it so the agent can use those ports. Restarts the DNS Server. |
| Don't announce the tunnel IP via DNS | Keeps the tunnel IP out of the addresses the DNS Server publishes for itself, so devices outside XplicitTrust are not sent to an address they cannot reach (see Multiple Domain Controllers and unreachable addresses). Restarts the DNS Server if something changes. |
| Make the DNS Server listen on the tunnel IP | Step 2 below: if the DNS Server does not answer on the tunnel IP, the tunnel IP is added to its listen addresses and the DNS Server is restarted once. |
| Use this server as DNS server for the AD domains | Step 3 below: adds the DC as split DNS server for the selected domains. |
| Add the server's FQDN and the domain names to DNS Names | Step 4 below: puts the DC's full name first in its DNS Names, followed by the selected domain names. |
All steps are selected by default, and hovering over a step explains it. Steps already in place are marked with a check and skipped. A domain already served by another DNS server is shown as such and left unselected. Apply only carries out the selected steps and never undoes anything. The agent applies the steps on the server itself with its next configuration update; until then they are shown as being applied by the agent. Once everything is configured, the section shows All steps in place.
The automated setup requires agent version 1.133 or later on the DC. The following sections describe the same steps for doing them by hand and for troubleshooting.
1. Expose the Domain Controller as an Asset
Install the XTNA-agent on the Domain Controller in
Asset Mode. The DC receives a tunnel IP (for
example 100.100.0.2). Grant the relevant clients access to it through a
Policy.
2. Make the DNS Server listen on the tunnel IP
When the agent comes up in Asset Mode the DC gets a new tunnel adapter and
tunnel IP (for example 100.100.0.2). For the AD-zone lookups that clients send
over the tunnel to be answered, the Microsoft DNS Server service on the DC
must be listening on that tunnel IP. Whether it starts doing so on its own after
install is inconsistent — sometimes the service binds to the new address
automatically, sometimes it keeps listening only on the addresses it had when it
started — so always verify it explicitly.
Why it's sometimes bound and sometimes not
The DNS Server binds to interface addresses according to its Listen on setting. With All IP addresses it picks up the tunnel IP — but generally only the next time the service re-enumerates interfaces, i.e. after a restart. The tunnel adapter usually appears after the DNS Server has already started, so until the service restarts (or the host reboots) the new address may not be bound. If Listen on is set to Only the following IP addresses, the tunnel IP is never added until you add it by hand.
Check the bound addresses from the DC:
dnscmd /info /ListenAddresses
If the tunnel IP is missing (or no explicit list is configured yet lookups arriving over the tunnel go unanswered), fix it one of two ways:
- restart the DNS Server so it re-enumerates the interfaces and binds the tunnel
IP —
Restart-Service DNS; or - in DNS Manager → server Properties → Interfaces, select Listen on: All IP addresses (or add the tunnel IP to the explicit list) and apply.
Telling this apart from a DNS-name problem
From a connected client, query the DC's tunnel IP directly:
Resolve-DnsName dc01.example.local -Server 100.100.0.2. If the DC's tunnel
IP doesn't answer at all, the DNS Server isn't listening on it (this step).
If it answers here but normal lookups still fail, the problem is split DNS or
the DNS Names pin instead (steps 3 and 4).
3. Configure split DNS for the AD domain
On the Account → Settings page, add the Domain Controller as a
split DNS server for your Active Directory
domain (for example example.local). Clients that can reach the DC via a
Policy will then send all *.example.local lookups to the DC over the
tunnel.
4. Add the AD domain name to the asset's DNS Names
On the Domain Controller Asset, in the DNS Names field, add both:
- the DC's host FQDN — e.g.
dc01.example.local - the AD domain (apex) name itself — e.g.
example.local
The full host name must come first. Windows derives the Kerberos name for LDAP from it, and with a short name or the domain name first, Group Policy fails over the tunnel.
Don't forget the bare domain name
Windows uses the AD domain name itself as a server and DFS target for
domain-wide operations — \\example.local\SYSVOL and
\\example.local\NETLOGON (read on every logon for Group Policy) are
domain-based DFS paths, and the domain name is also used for
domain-controller location.
Split DNS only steers subdomains of the AD domain
(dc01.example.local) to the DC; the bare apex example.local is not
covered. Unless you add it explicitly as a DNS Name, lookups for the
domain name fall through to the client's normal DNS — typically the local
router — which cannot resolve the internal AD zone. Group Policy,
SYSVOL/NETLOGON and any domain-based mapped drives then fail at logon.
Adding the apex as a DNS Name pins example.local → the DC's tunnel IP in
the agent's hosts file, so domain-wide operations resolve to the reachable DC
over the tunnel.
Symptoms when the apex is missing
On the client, mapped network drives come up late or not at all after logon, and the Windows Event Log shows NETLOGON 5719 (the secure channel to the domain could not be set up), SMBClient 30800 (the server name — the bare domain — cannot be resolved), and GroupPolicy 1129 (no network connectivity to a domain controller).
List the FQDN first
Enter the DC's full name first (e.g. dc01.example.local), before any
short name (dc01) or the domain name. The first name in DNS Names is the
name Windows gets back when it looks up the DC's tunnel IP in reverse.
Windows builds the Kerberos service name for LDAP from that reverse lookup.
With a short name first, it requests ldap/dc01/example.local, which a
Domain Controller does not register. The LDAP bind for Group Policy then
fails over the tunnel only, while drives, SYSVOL and NETLOGON keep
working. gpupdate reports that Windows could not authenticate to the Active
Directory service (LDAP bind failed), and the GroupPolicy log shows events
7017 / 7326 with error 1326.
Multiple Domain Controllers and unreachable addresses
The AD domain name normally resolves to all Domain Controllers, and each DC publishes its on-premises LAN (and possibly IPv6) addresses. Only addresses that are reachable over the tunnel will work; any others are still tried by Windows and fail, which makes domain operations slow or flaky.
To avoid this, make sure the names that domain-joined clients use resolve to a
tunnel-reachable address. For a single tunnel-reachable DC, the DNS Name pin
from step 4 already takes care of this. If clients should use several DCs,
expose each of them as an Asset (and add the domain apex to each). If your
internal DNS hands out addresses that are not routed through the tunnel (a DC's
LAN IP, or AAAA/IPv6 records), restrict or suppress them for these names.
Recommended: avoid the logon race
Windows reconnects mapped network drives very early during logon. Even with the tunnel and split DNS configured correctly, the drive reconnect can fire before they are ready. Enable the Group Policy Computer Configuration → Administrative Templates → System → Logon → Always wait for the network at computer startup and logon** so that logon waits for the tunnel and split DNS to come up.
Verify
After connecting the client, flush the resolver cache and confirm that both the domain name and the DC FQDN resolve to the DC's tunnel IP:
ipconfig /flushdns
Resolve-DnsName example.local
Resolve-DnsName dc01.example.local
Get-SmbMapping
Both names should return the DC's tunnel IP (e.g. 100.100.0.2), and
Get-SmbMapping should list the network drives as OK.