Skip to content

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 three parts: expose the DC as an Asset, 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. 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.

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

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.