Onprem AD/gpupdate

Ziti Overlay
1

We have a ziti environment, on 1.7.1

I have a basic service setup, that mimics emoscardini’s approach ( Conneting Remote Endpoints with a On-Prem AD - #6 by emoscardini )

For argument’s sake, we have hosted tenant environments, and we’ll call the tenant…dundundun … ’tenant’, and the base domain is domain.root - so tenant.domain.root

Intercept.v1

  "data": {
    "portRanges": [
      {
        "high": 138,
        "low": 138
      },
      {
        "high": 53,
        "low": 53
      },
      {
        "high": 389,
        "low": 389
      },
      {
        "high": 445,
        "low": 445
      },
      {
        "low": 1024,
        "high": 65535
      },
      {
        "high": 88,
        "low": 88
      },
      {
        "high": 636,
        "low": 636
      },
      {
        "high": 123,
        "low": 123
      },
      {
        "high": 135,
        "low": 135
      }
    ],
    "addresses": [
      "*.tenant.domain.root"
    ],
    "protocols": [
      "tcp",
      "udp"
    ]
  },
  "tags": {}
}

Host.v1

  "data": {
    "forwardProtocol": true,
    "forwardAddress": true,
    "forwardPort": true,
    "allowedAddresses": [
      "*.tenant.domain.root"
    ],
    "allowedPortRanges": [
     {
        "high": 138,
        "low": 138
      },
      {
        "high": 53,
        "low": 53
      },
      {
        "high": 389,
        "low": 389
      },
      {
        "high": 445,
        "low": 445
      },
      {
        "low": 1024,
        "high": 65535
      },
      {
        "high": 88,
        "low": 88
      },
      {
        "high": 636,
        "low": 636
      },
      {
        "high": 123,
        "low": 123
      },
      {
        "high": 135,
        "low": 135
      }
    ],
    "allowedProtocols": [
      "tcp",
      "udp"
    ]
  },
  "tags": {}
}

Remote client workstations running the latest ZDEW.

Almost everything works; DNS resolves, and in particular, SRV records resolve, all Test-NetConnection tests are happy etc.

However, gpupdate /force is stubbornly broken, with the typical unhelpful messages

image
image1112×293 13.7 KB

Probably the most significant difference in our approach is that we're using a gateway host in the tenant windows/dc lan. Within the tenant LAN, we have a VM (just plain old Ubuntu) running ziti-edge-tunnel with the host-side identity. This is due to some of the dogshit applications the clients run in their Windows environment, we need to keep Ziti off of Windows - no fault of Ziti at all, simply the fact it adds another network adapter - but that's by the by.

If I step around Ziti’s DNS resolver on the remote client, by adding an NRPT rule that points to one of the Ziti IPs, ie

Get a Ziti IP

Resolve-DnsName -Name tenant.domain.root
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
tenant.domain.root                             A      60    Answer     100.64.0.6

Then add a wildcard to Windows NRPT

Add-DnsClientNrptRule -Namespace ".tenant.domain.root" -NameServers "100.64.0.6" -Comment "test"

Then gpupdate can work - but that’s less than ideal.

The tldr is - I'm missing something! - I just can't figure out what.

I have tried removing the port ranges and just using 1-65535, but that doesnt appear to change anything.

Other than ziti logs complaining about bloody wpad.tenant.domain.root, there is nothing in the logs when running gpupdate. It's as if the Windows workstation has cached something and preemptively decides not to bother trying.

Does anyone have any experience with this?

2

Hi @strongwazz, I don't have a great environment that I can use to mimic yours to test or prove anything out with. My expectation is that some sort of "underscore" domain is not getting intercepted properly. If it were me I would:

  • install wireshark
  • replicate the issue capturing all interfaces
  • look for failures to _ldap._tcp.dc._msdcs.<domain> or _kerberos._tcp.dc._msdcs.<domain> or SOME sort of domain like that which isn't getting intercepted. It's possible these intercepts will need to be added manually, (i got them from chat gpt btw so if this info is bad - sorry ? :slight_smile: ) If you see them, they look like they won't be 'normal' wildcard domains that'd match *.tenant.domain.root

That's really all I can probably do to help you. I don't have a windows domain that I can test with easily at this time. Hope that helps?

3

Hey @TheLumberjack
Thanks for that.

Are we saying that the _ldap etc, dns with underscores, fails the wildcard logic? Interesting.

Will have a play
Thanks!

4

I'm not saying that. I'm saying a wildcard match only matches the first "subdomain".

If you have *.domain.com, then "server.domain.com" is matched but NOT "_ldap.server.domain.com" (as that's two levels deep). Looking at the format of the examples I sent you they are far more than "one level" deep: _ldap._tcp.dc._msdcs.<domain>.

5

Gotcha.
All good - I have a solution now.
It was simply adding upper and lowercase variants for everything, as well as the non-wildcard variant

 "allowedAddresses": [
  "*.tenant.domain.root",
  "tenant.domain.root",
  "*.TENANT.domain.root",
  "TENANT.domain.root"
]

Once the upper/lower case variants were all there, everything started working.

That was discovered from nltest, where

nltest /dsgetdc:tenant.domain.root #worked

nltest /dsgetdc:TENANT.domain.root #did not

So yeah - she's singing now! :heart_eyes:

The upper/lower case thing - maybe Windows AD naming conventions at play in our case, unsure.

1 Like