Authentication/deployment method for desktop agent with general users

1

The docs describe a number of concepts and configuration methods quite well, and through manual interaction with the desktop app I can see a Poweruser with a work instruction being able to use it, but is there a typical deployment method for general end users/a business suitable deployment?

The requirement would be to wrap up the desktop agent (ZDEW) with an installer script and be able to automaticaly ddeploy to users via an MDM, and have the agent working/services accessible once a user hits their desktop.

The Third Party CA method looks promising - issue a x509 device or user auth cert through enterprise PKI to managed devices and have clients self registe - since this is similar to how many VPNs are deployed and scales well.
However the docs for the windows agent only show GUI methods for importing the cert (no guidance on how to automaticaly do so from an install script) - and it appears the agent can't use windows cert store/ certs anyway - which prevents accessing most enterprise/MDM deployed certs?

SSO using OIDC is the other option presented in the docs, however it seems the URL also needs to be manualy set through the GUI, and also that signing in is a manual task for the user (not seeing an option to silently/automaticaly log the user in using i.e their Entra PRT or similar).

Is there an intended architecture/method in OpenZiti to have an agent deployable and 'ready to go' from an MDM for wide spread use, or any docs reqgarding pre-configuring the agent at all (registry keys, command references or an ADMX?) Or is the focus on the project more targeted at supporting Developers/Power users only?

2

Hi @Bailey-Coole, welcome to the community and to OpenZiti!

Thanks for that feedback. I don't think any "typical end users" (non-power-user) have had any issues with using any of the clients to date. We use OpenZiti internally of course and have HR/Sales/Finance/Help Desk all using it quite successfully and not all of them would be considered "power users". NetFoundry the company also has customers with thousands of individual clients and I'm sure not all of them are power users. However, I think I get your point. You're looking to make it even easier maybe even to the point of "no touch".

There are quite a few options to do the steps from a script. I'll describe a couple and you can follow up if you like... All OpenZiti identities are described in a json file. The file needs to have certain entries. The format of the file is pretty simple but I don't believe we have it documented anywhere... You could easily craft that file and put it into the location where identities are stored, currently the system profile (but will likely move to PROGRAMDATA at some point).

The file format looks like:

{
  "ztAPI": "https://ec2-3-18-113-172.us-east-2.compute.amazonaws.com:8441",
  "ztAPIs": [
    "https://ec2-3-18-113-172.us-east-2.compute.amazonaws.com:8441"
  ],
  "id": {
    "cert": "-----BEGIN CERTIFICATE-----\nMIIDmTCCAYGgAwIBAgIDB2FIMA0GCSqGSIb3DQEBCwUAMHgxCzAJBgNVBA
    "key": "-----BEGIN PRIVATE KEY-----\nMIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgnTo/cQ+/P5+
    "ca": "-----BEGIN CERTIFICATE-----\nMIIF5DCCA8ygAwIBAgIRAIN5uqTEgZ5nxKlrVRivaCMwDQYJKoZIhvcNAQEL
  }
}

The identity file can contain URI references (file://) such as:

  "id": {
    "key": "file:///Windows/System32/config/systemprofile/AppData/Roaming/NetFoundry/mm.key",
    "cert": "file:///Windows/System32/config/systemprofile/AppData/Roaming/NetFoundry/mm.cert",
    "ca": "file:///Windows/System32/config/systemprofile/AppData/Roaming/NetFoundry/mm.ca"
  },

If you put a file into C:\Windows\System32\config\systemprofile\AppData\Roaming\NetFoundry that references a key/cert and has the proper CA field (which you get from the controller), then you can manually generate these identity files if you wish.

If you have a .jwt for the user, it is pretty easy to use the ziti-edge-tunnel binary and 'add' the identity via command line:

& 'C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\ziti-edge-tunnel.exe' add --jwt c:\temp\new-id.jwt -i new-id.json

You can also add an identity by url this way and not require the jwt but as you noted, external auth does require the user to initiate and complete the OIDC flow:

& 'C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\ziti-edge-tunnel.exe' add --url https://ctrl.zrok.clint.demo.openziti.org:8441 -i id-by-url

I have no exeprience with MDM myself and I've never tried to deploy a client using it. I do think it's pretty easy to script the deployment of an identity, but it might take a back-and-forth of you asking us questions to get you to success, if you don't mind having the dialogue I'm sure we can find some solution (if the stuff I wrote above doesn't already get you there)

Let me know if that helps and if you have follow-up questions, I'll try my best to help out

3

On top of what @TheLumberjack says, I would only add that using MDM for deployment/automation is something I know several NetFoundry customers have done, much of it done with the help of @NicFragale. This is also helped with some of the automation we have built for working with external CAs - https://support.netfoundry.io/hc/en-us/articles/360048210572-How-to-Register-Endpoints-with-Certificates-from-Another-Authority.

4

Ok, this is promising - so it looks like the functionality exists but, but the documentation hasn't caught up yet.

The cert method does looks promising if it can be configured using config files instead of just the GUI, but it might take some tinkering to figure out if a private key can be exfiltrated from the cert store and inserted into the config.

I think 'no touch' is the better way to describe what we are going for, due to the combination of remotely deploying devices with Windows Autopilot, and needing essentially 'always on' network connectivity to internal services - We have had luck with MS AOVPN and Palo GP for this since they can be fully deployed from MDM/Intune. We had trailed some SASE clients that did need to be explicitly authed, but even with SSO we found this caused problems (user's would not see or would close out the sign in prompt, or the prompt triggered during device provisioning phase so wasn't ever seen by user etc).

Also, is syncing Identities from Entra part of Ziti, or netFoundry only?

5

There's an issue for supporting functionality like this without exporting. It's not quite as simple and straightforward as it sounds for everyone, just because OpenZiti tunnelers, by their nature (taking IP-based underlay traffic and sending over the overlay), need to operate at a system-wide level. I am pretty sure one can mark keys as exportable when importing them manually, I don't know if the flows you have access to would allow for it but do let us know what you discover? :slight_smile:

Sync'ing identities from Entra is a NetFoundry Enterprise-style add-on. It's not the sort of thing that OpenZiti is looking to solve really, I'd be surprised if the OpenZiti project would deliver such a thing. That's more automation around OpenZiti.

6

Yes will do, I'm going to go tinker for a bit with the agent. I also found another thread here of what seems someone else hitting the same issues. I think I have a plan based on what's been shared so far, but need to build more of a test network deployment first.

Ah. Would a typical Ziti implementation be expected to rely solely on manual identity/access management within the app (or 'home-grown' automation). Or is there more of a soft expectation there that business customers should use the paid product if wanting to centralise IAM? I don't think this is too critical to our use case, just trying to understand the design intent/typical deployment.

7

I think the only honest answer really is, "it depends". I think OpenZiti is solving the zero trust overlay problem. How that overlay is provisioned is entirely up to each individual instance, so there's no one 'right way'. It has APIs so that people can integrate with it and automate these sorts of provisioning, but OpenZiti itself hasn't tried to be that (at least not yet). The idea is to allow people the flexibility to implement what they want/need.

There are plenty of business customers using the open source project already. That thread you found is one of them. I would say it's more of a "if you want to do all this sort of thing on your own, have at it" type of attitude, and if not, well then, maybe NetFoundry has a solution for you. OpenZiti's license is very open, it's fully programmable, it's open source, but at the end of the day there needs to be value that NetFoundry can provide above and beyond the OpenZiti project itself as well.

So it'd be great if everyone used an OpenZiti overlay provided by NetFoundry, (there are numerous benefits to a business after all, to allowing the inventor/subject matter experts run the overlay) but we don't make these types of decisions to actively 'paywall' features. If it belongs in OpenZiti, we add it to OpenZiti based on the sort of ethos I laid out above.

hth

1 Like