Expected Behaviour of 'domain join' design guide deployment/wildcards in intercept config

1

Making this as a separate thread to my IAM/Agent questions.

Looking at this doc. I can see this as being similar to what we would need to achieve for our use case, but I want to confirm an understanding on how it works and its impacts.

The Ziti docs describe the ability to use wildcards in intercept configs & the design guide shows using *. as the address to be intercepted. This makes sense as the DC locator service could pick any DC in the domain to access for auth or to browse the domain namespace. The design guide also shows all ports (1-65535) being added, presumably also to account for the 'quirks' of windows RPC and its dynamic port behaviour.

Would this not effectively make the 1 service not just be for Domain Auth/Join, but also for any service within the zone? I.e If a service is configured to *.contoso.com, 1-65535 for DC auth, the user would also get access to https://someapp.contoso.com (with no ability to separate/prevent access).

If this is the case, how does routing work with multiple networks? I.e if multiple sites or zones each have domain controllers (or apps) in the same domain, and each site has a local edge router, and the identities of all such edge routers were added to a service policy for AD access - would all edge routers assume they can access all AD servers? or is there some implicit smarts/magic under the hood.

I.e with the service configured using *.contoso.com a site A with Edgerouter-East, DC-east1.contoso.com & DC-east2.contoso.com & a Site B with Edgerouter-West, DC-west1.contoso.com & DC-west2.contoso.com, and Edgerouter-East & Edgerouter-West in the same service policy . If a client with a desktop tunneler made a request to DC-east1.contoso.com, is it guaranteed to go through Edgerouter-East (if so, how? - is there a config separate to the service policy or is there some overlay network magic doing this). or is it required that all edge routers in a service policy can access any service directly on the underlay network. Similar for a https://someapp.contoso.com only hosted in Site A, will all requests be routed through Edgerouter-East, or does there need to be a route on the underlay from site B?

Is there a potential conflict between control plane DNS and the wild cards in the intercept config? ie if the control plane was hosted at ziti.contoso.com, would that conflict with the *.contoso.com service definition? (i.e would the control plane need to be changed to be like ziti.something.contoso.com or ziti.contoso.net instead)

2

Hi @Bailey-Coole,

When you forward the address at the far side, you also need to specify the 'allowed' addresses as well. So it could, yes, but it also could not. For example when you toggle the 'forward address' in the ZAC you'll need to specify the allowed addresses. You could choose to constrain this however you wish (or not).

image
image590×241 17.8 KB

This is exiting the "101 level" of OpenZiti and entering complex levels quickly... :slight_smile: If you have the exact same domain and require it to be routed to different locations, I think that'll be an issue without some other sort of differentiator. Nothing comes to mind as to how you would accomplish this with one single service. With mutliple services, it seems trivial to implement since each service would be bound by a different router. You clearly could not enable both services at the same time from the same 'client' machine. That would make the behavior non-deterministic and not what you want at all. OpenZiti clients don't support turning off individual services at this time, so you'd also need a second identity and you'd enable/disable the identity accordingly... But that should work (i think). I'll offer a caveat too, i have not tested this, but it seems like it'd be fine assuming I understand what you're looking for. I reserve the right to be mistaken! :slight_smile: So while I'm not :100:, I'd think this would be pretty easy to deal with on the whole... I think....

I feel like a diagram would probably help me. I feel like I'm getting a wee bit lost here. I think my prior reply answered many of the questions in this paragraph but not this one...

No, it's not required, but I mean, if you try to offload from a router in SiteB to a server that is only in SiteA, obviously that won't work without some underlay route, right? :slight_smile: I feel like maybe I'm missing something on this question?

This can happen yes. When using tunnelers, we specifically exclude intercepting the exact address specified by routers or the controller so that it's not possible mess up that DNS resolution. You'll see something like:

ziti-tunneler.log:[2025-04-15T13:11:45.524Z]   DEBUG tunnel-sdk:ziti_tunnel.c:127 ziti_tunneler_exclude_route() excluding ec2-3-18-113-172.us-east-2.compute.amazonaws.com from tunneler intercept

in your logs

hth

3

Yeah, we have an interesting use case where I can see Ziti potentially being a great solution for our org, but to get stakeholder approval for the PoC we need to make sure the architecture is suitable. It has been quite frustrating that most of the proprietary SD-WAN vendors just hide behind "its all magic just buy it and pro services will make it work", so being able to do the leg work early here is a nice change.

I'm also trying to get my head around what is 'intended behavior'/design patterns are early so I don't spend too much time troubleshooting something that 'doesn't work that way ' later.

The intent/preference would be to have each site 's edge router emit traffic for hosts/services at that site, and avoid needing to have/use dedicated site-site underlays. Of course if the overlay can't achieve the routing, then the underlays would need to be designed to 'fix that' - and would be a key design input early.

This is the tricky bit with AD. Since if a client was to NSLOOKUP the AD domain, the DNS servers in an AD integrated zone will return all domain controllers, and then the client picks which it intends to contact. On a traditional VPN, you can add the VPN subnets to AD sites and services and encourage clients to target specific DCs, but since there isn't an equivalent overlay IP for the tunneler(?) I don't think the client can be 'pushed' to a specific DC/site, and the network design (overlay or underlay) will need to accommodate.

Is mixing and matching Address formats between intercept and host config allowed? Because if so having the intercept config by domain and the edge router allowed address be via IP makes this quite 'clean', due to each site having its own IP space.

Ask and ye shall receive (Also awesome drawio stencil library btw).

image
image1915×1208 277 KB

The intent of the policies in blue is to allow access to the AD domain for all Users. The policies in yellow are meant to allow User A access to the somApp.contoso.com app. The concern is that the wildcard in the intercept config may be overly permissive, and allow UserB access to somApp.contoso.com unintentionally.

The other potential side effect is that it would make an external hosted app using a corp domain but not within the corp network (i.e an external SaaS app with a SaasApp.contoso.com vanity domain) impossible (?) to access, since I can't see a way in the docs to add exceptions to the intercept config.

The more I'm reading the docs and drawing this out, its starting to feel that using a wildcard in the intercept config for this is a bit of an antipattern, and it would make more sense to just define Intercepts for each AD DC. The counter to this is then the client wouldn't necessarily be pushed to split all DNS requests to the *.contoso.com zone to the Ziti resolver, which may cause issues accessing SRV records/the AD integrated zones. I imagine this too could be solved using an intercept for UDP port 53 and sending all DNS to an internal DNS server, but I'm not sure if this would create a chicken/egg issue where the tunneler can't reach a DNS server to locate the controller/a public router because its trying to send all DNS requests via the overlay that it hasn't yet joined.