Active Directory Users and Computer (ADUC) is slow over Twingate

Applicable to

Twingate Component: Client

Platform: Windows

Environment: Domain-joined Windows machines running the Twingate Client, on or off the corporate network

Overview

Opening Active Directory Users and Computers (ADUC) while the Twingate Client is running can take significantly longer than it does with the Client stopped. This is a result of how Windows resolves names when more than one set of DNS servers is configured, and it is expected behavior rather than a fault in the Client. This article explains what causes it, how to confirm it, and the supported workarounds.

Symptoms

• dsa.msc takes anywhere from tens of seconds to several minutes to open while the Twingate Client is running, and opens normally when it is stopped

• The console stays slow when expanding containers or switching domains

• Other Active Directory operations on the same machine may also be slow, including domain logon and Group Policy processing

Cause

The Twingate Client handles DNS through its own resolver so that private Resources resolve correctly. DNS queries sent directly to the DNS servers assigned to your physical network adapter do not complete while the Client is running. This is the same behavior described in Using nslookup with Manually Defined Nameserver Fails on Windows with Twingate Client Running.

Windows queries the DNS servers on every network adapter in parallel and tracks each adapter separately. Before it can report that a name does not exist, it waits for every configured DNS server to either answer or time out. The queries sent to the adapters the Client is handling do not return, so Windows waits out the full timeout, which is approximately 12 seconds.

This affects only lookups that find no record. A name that resolves successfully returns at normal speed, because the first successful answer ends the lookup.

ADUC locates a domain controller before it can display anything, and that process deliberately queries a number of names that are not expected to exist. Each of those costs the full timeout, and they add up to the delay you see. Connecting to a domain controller directly skips that phase, which is why the workaround below is effective.

Because these queries are dropped below the layer packet capture tools attach to, they do not appear in a capture taken on the affected machine. A capture that shows nothing is consistent with this cause, not evidence against it.

Confirming this is the cause

Run the following in PowerShell on the affected machine while the Twingate Client is running. Substitute your own Active Directory domain name. The hostname is intentionally one that does not exist.

ipconfig /flushdns
Measure-Command { Resolve-DnsName -Type SRV "_ldap._tcp.doesnotexist.example.local" -ErrorAction SilentlyContinue }

A TotalSeconds value of approximately 12 confirms this behavior. A value well under one second means something else is causing the slowness.

Resolution

There is no Client setting that changes this behavior. The options below are ordered by how quickly you can act on them. Option 1 is the fastest to try and changes nothing on the machine. Option 2 is the recommended approach if you administer Active Directory regularly. Option 3 is the most effective at eliminating the delay but leaves configuration in place that has to be managed.

Option 1: Connect to a domain controller directly

Launching ADUC with an explicit server skips the domain controller location phase, which is where the failed lookups originate.

dsa.msc /server="domain controller IP"

An IP address is preferred over a hostname, since a hostname still has to be resolved. This resolves the slowness for most users and changes nothing on the machine. ADUC performs some name resolution after it connects, so heavily nested or multi-domain environments may still see some delay.

Option 2: Use an administrative host

If you administer Active Directory regularly, running ADUC from a jumpbox or administrative host on the same network as the domain you are managing is the approach we recommend. It avoids the behavior described above entirely rather than working around it, requires no per-machine configuration, and keeps Active Directory tasks local. It also aligns with Microsoft's guidance on secure administrative hosts.

Option 3: Direct your Active Directory namespace to the Twingate Client with an NRPT rule

The Name Resolution Policy Table (NRPT) is a Windows feature that sends lookups for a specific namespace to a specific set of DNS servers. Adding a rule that points your Active Directory namespace at the Twingate Client's DNS proxy stops Windows from querying the physical adapter for those names at all, so there is no timeout to wait out.

This is the most effective of the three options, and the only one that leaves lasting configuration on the machine. Read the note below before applying it.

Run in an elevated PowerShell session. Replace the namespace with your own Active Directory domain, keeping the leading dot.

Add-DnsClientNrptRule `
    -Namespace ".ad.example.com" `
    -NameServers "100.95.0.251","100.95.0.252","100.95.0.253","100.95.0.254" `
    -DisplayName "Twingate AD DNS"

Verify the rule is active and test:

Get-DnsClientNrptPolicy -Effective
ipconfig /flushdns
Measure-Command { Resolve-DnsName -Type SRV "_ldap._tcp.doesnotexist.ad.example.com" -ErrorAction SilentlyContinue }

In testing, this reduced the same lookup from approximately 12 seconds to well under one second, and ADUC opened immediately.

To remove the rule:

Get-DnsClientNrptRule | Where-Object { $_.DisplayName -eq "Twingate AD DNS" } | Remove-DnsClientNrptRule -Force
ipconfig /flushdns