Conneting Remote Endpoints with a On-Prem AD

Good day!
This is not a question, but rather sharing with you some insights, recently I had to connect some remote servers located into a Cloud Provider with an OnPrem Domain Controller, so here’s my solution if you ever face that issue:

  1. Put the Controller and PublicEdgeRouters DNS information into the hosts files, so they can know what’s the IP or where to find them.
  2. Startup the windows service.
  3. You need to modify the DNS servers to use the Domain Controller IP as the new DNS (I’m assuming you already created the Endpoint, Services and Appwan into your Ziti network).
  4. As the ziti-tun interface has less priority than the Ethernet/Wireless ones, Windows never use them to query the DNS Enrollment, unless we force that out setting the DNS address into the ziti-tun interface:

Set-DnsClientServerAddress -InterfaceAlias ziti-tun -ServerAddress $AD_DNS_SERVER

Where $AD_DNS_SERVER is the IP of your PDC. You can specify multiple DNS Addresses as well:
Set-DnsClientServerAddress -InterfaceAlias ziti-tun -ServerAddress ("$AD_DNS_SERVER1",$AD_DNS_SERVER2",...)

And there you go, enrollo you servers into the Domain Controller as they’re local.
Easy, fast and secure!

Happy Hacking!

1 Like

Very cool! You need an ip intercept service for each domain controller too, right?

Are you sure about that? At one time the metric was higher than all other interfaces?

@natashell

This seems like a setup that would break easily if anything inside of the infrastructure changed, like the DC names or IPs.

When using ZDE(or ziti-edge-tunnel) wouldn’t it would be more stable to use a wildcard(*.domain.com) service setup instead of altering the DNS of the tunnel interface?

The newer versions of ZDE(ziti-edge-tunnel) support tunneling the SRV record lookups, so you can join/query/use domain services. FYI, The wildcard setup does require that the far end(wherever you are egressing the traffic) is able to lookup records.

@emoscardini, any chance you have a recipe / set of steps for doing this to share? That sounds great.

Sure!

This topology is using ZTHA(ziti host access) → ZTNA(ziti network access)

Let’s assume you already have a Ziti Network deployed with a registered identity for the client with an attribute named “ad_clients”, a couple edge-routers deployed for public access with an attribute called “public_routers” & a couple routers inside the destination network deployed and configured with tunnel binding enabled & the resulting identities with the attribute named “ad_router_identities”. The domain you want to connect to is “mynet.contoso.com

Example diagram:

This setup will use the ZDE(Windows) as the ZTHA & client and an Edge Router deployed into the remote network as the ZTNA egress pointing to the domain server.

:exclamation: It’s imperative that the Routers in the remote network have the ability to lookup domain DNS names, so usually those Edge Routers are pointing their DNS configuration directly to a local domain controller.

The main distinction for using wildcard is the service configuration, so here they are expanded.

Here is an example intercept.v1 configuration for the AD service that will be used by the client in this instance. The addresses being intercepted will be *.mynet.contoso.com:

{
   "addresses":[
      "*.mynet.consoto.com"
   ],
   "portRanges":[
      {
         "high":138,
         "low":138
      },
      {
         "high":53,
         "low":53
      },
      {
         "high":389,
         "low":389
      },
      {
         "high":445,
         "low":445
      },
      {
         "high":65535,
         "low":1024
      },
      {
         "high":88,
         "low":88
      },
      {
         "high":636,
         "low":636
      },
      {
         "high":123,
         "low":123
      },
      {
         "high":135,
         "low":135
      }
   ],
   "protocols":[
      "udp",
      "tcp"
   ]
}

An here is an example host.v1 configuration for the AD service that will be used by the egressing router identities in this instance. The allowed addresses & ports must match the intercept configuration & forwarding must be enabled for address/port/protocol for this to function properly:

{
   "allowedAddresses":[
      "*.mynet.contoso.com"
   ],
   "allowedPortRanges":[
      {
         "high":138,
         "low":138
      },
      {
         "high":53,
         "low":53
      },
      {
         "high":389,
         "low":389
      },
      {
         "high":445,
         "low":445
      },
      {
         "high":65535,
         "low":1024
      },
      {
         "high":88,
         "low":88
      },
      {
         "high":636,
         "low":636
      },
      {
         "high":123,
         "low":123
      },
      {
         "high":135,
         "low":135
      }
   ],
   "allowedProtocols":[
      "udp",
      "tcp"
   ],
   "forwardAddress":true,
   "forwardPort":true,
   "forwardProtocol":true
}

Here are the commands to create all of the necessary logical components via Ziti CLI:

Create the intercept.v1 config:

ziti edge create config ad_intercept intercept.v1 '{"addresses":["*.domain.com"],"portRanges":[{"high":138,"low":138},{"high":53,"low":53},{"high":389,"low":389},{"high":445,"low":445},{"high":65535,"low":1024},{"high":88,"low":88},{"high":636,"low":636},{"high":123,"low":123},{"high":135,"low":135}],"protocols":["udp","tcp"]}'

Create the host.v1 config:

ziti edge  create config ad_host host.v1 '{"allowedAddresses":["*.domain.com"],"allowedPortRanges":[{"high":138,"low":138},{"high":53,"low":53},{"high":389,"low":389},{"high":445,"low":445},{"high":65535,"low":1024},{"high":88,"low":88},{"high":636,"low":636},{"high":123,"low":123},{"high":135,"low":135}],"allowedProtocols":["udp","tcp"],"forwardAddress":true,"forwardPort":true,"forwardProtocol":true}'

Create a service making sure to associate the above configs:

ziti edge create service ad_service --configs ad_intercept,ad_host

Create the edge-router-policies to allow client to reach the public edge routers:

ziti edge create edge-router-policy client_public --identity-roles '#ad_clients' --edge-router-roles '#public_routers'

Create the service-edge-router policy to allow all routers to host the service:

ziti edge create service-edge-router-policy allow_all --edge-router-roles '#all' --service-roles '#all'

Create the service bind policy to associate the service with the hosting edge router identities:

ziti edge create service-policy ad_bind Bind --identity-roles '#ad_router_identities' --service-roles '@ad_service --semantic AnyOf '

Create the service dial policy to allow the client access to the service:

ziti edge create service-policy ad_dial Dial --identity-roles '#ad_clients' --service-roles '@ad_service' --semantic AnyOf

Once this the above is complete the remote client should have access to the AD services.

Just in case you need to the commands to also create the client & routers:

Create identity for the client:

ziti edge create identity device my_ad_client --role-attributes ad_clients

Create public edge routers:

ziti edge create edge-router public1 --role-attributes public_routers
ziti edge create edge-router public2 --role-attributes public_routers

Create the private edge routers:

ziti edge create edge-router private1 --role-attributes private_routers
ziti edge create edge-router private2 --role-attributes private_routers

Update the identities created in the above router create with the correct role attributes:

ziti edge update identity private1 --role-attributes ad_router_identities
ziti edge update identity private2 --role-attributes ad_router_identities

Hope this helps.

3 Likes

Woah that’s awesome, thank you. I had a redditor doing pen testing work and was asking about this same topic. Thanks again.

No problem!

Also, as a troubleshooting measure, you can use this command on the client(Windows) to see if everything is working before attempting to use or join a remote domain:

Resolve-DnsName _ldap._tcp.dc._msdcs.mynet.contoso.com -Type SRV

In conjunction with the wildcard configuration, the ZDE(ziti-edge-tunnel) will tunnel SRV queries to the terminating end of the connection. The above command should test that & return the list of controllers that you’d use to join the AD domain. If that doesn’t work, domain services are likely to not work. Most of the time this due to a mis-configuration of the logical components or the egressing side isn’t capable of finding the DNS record requested.

1 Like

This is super helpful, thanks for the recipe!

The only issue I’m having, is how the ADCU (The service to join to the DC), ignore the ziti-tun (Even with that configuration) and instead try to reach out the external DNS so even when doing nslookup and stuff works, you can’t join the domain as it ignores the DNS and keep using the declared in the main interface.

Changing the priority dind’t help either :frowning: