If you are deploying Twingate onto a network using Active Directory, a few configuration steps in Twingate will help your users continue to use their AD services without issue.
If you need to join a computer to an Active Directory domain over Twingate then please be sure to follow the documentation for Windows Start Before Logon in addition to the steps described below. This will ensure that a Windows machine can connect and access your Active Directory Domain Controllers before the user has logged in to their device.
In order to use any services that require Active Directory authentication, you must enable clients using Twingate to discover and communicate with the domain controller. Any clients that need to use the domain in any way must have access to these Resources.
- Add a Resource with the DNS name of
yourcompany.comwith the name of your AD domain, and make sure it appears in your client Resource list
nslookup -type=any _ldap._tcp.dc._msdcs.yourcompany.com(Linux/Mac) or
nslookup -type=all _ldap._tcp.dc._msdcs.yourcompany.com(Windows), replacing
yourcompany.comwith your AD domain, this should return the domains and/or IPs for your domain controller(s)
- Add the domain controller IPs and domain names to Twingate as Resources, make sure they appear in the clients' Resource lists
This will enable AD authentication for any service that requires it.
Below is a notional example using
yourcompany.com as the AD domain
nslookup -type=any _ldap._tcp.dc._msdcs.yourcompany.com Server: 100.95.0.251 Address: 100.95.0.251#53 _ldap._tcp.dc._msdcs.yourcompany.com service = 0 100 389 zr5cdi61eltc73z.yourcompany.com. _ldap._tcp.dc._msdcs.yourcompany.com service = 0 100 389 a1ks10fndwoyhax.yourcompany.com.
In this situation, you want to add
a1ks10fndwoyhax.yourcompany.com and assign it to the Everyone Group.
For the example above, the final configuration in Twingate will look something like this:
Your company's AD domain.
Domain Controller 1
This resource and the next one are returned in the DNS SRV request in the instructions above. These addresses point to your domain controllers.
(Depending on your domain configuration, the number of domain controllers you have may vary.)
Domain Controller 2
See the note, above.
Domain Service Discovery
This allows service discovery on your AD domain.
Typically these resources should be assigned to the automatic "Everyone" group (or a group of all Windows users) to simulate your users being joined to a physical Windows domain network while connected to Twingate.
Once connectivity has been verified using the above steps, you may wish to restrict access to only required ports. For more information please refer to the Microsoft support document How to configure a firewall for Active Directory domains and trusts.
- NetBIOS name resolution will not work over Twingate without a domain controller acting as a directory service, as this requires broadcast communication over a LAN. Windows file sharing will still work through using the machine's IP or DNS name, as long as the user in question has access to the Resource.
- If your domain controller is in Azure and your Connector is deployed as an Azure Container, you must check the Custom DNS Server option when deploying and use one of the DC IPs. Make sure the subnet the Container is deployed is in the same VNet as the DC or can otherwise communicate with it. Azure Containers do not automatically inherit the right DNS settings otherwise. Alternatively, if deploying the Connector on a Linux VM instead, DNS will be configured correctly at start and should not need any special configuration.
- If AD is still not working correctly then one way to debug connectivity is to add
*.yourcompany.comas a resource and then test AD connectivity. Any AD traffic that is not captured by the more specific rules described above should be listed in the Resource Activity list in the Twingate Admin Console.
Updated 10 days ago