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.

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

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).

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.