Trying to figure out the best way to restrict ui access / network joining capabilities for standard users. everything i can find says that unless you allow the ui to escalate via uac that the standard user cannot make changes. i’ve just test this on a windows 11 pro, non domain joined machine and this is not the experienced behavior. the ui launches with no prompt and the user is able to connect, disconnect and forget from existing networks and new ones as well. not sure if this behavior is different on a domain joined machine or if this is a windows 11 issue, have not tested on 10 yet. my current fix is to change the directory permissions on the %program files(x86)\Zerotier folder so that the non admin user cannot read / execute anything in the ui folder. not sure if the user would be able to download the ui elements and run them from another location allowing them to make changes without admin privileges.
Hi!
Unfortunately, I don’t think there is much you can do about it the way the client is installed and managed today and if the user has “local admin rights” it’s even harder to stop.
I’ve been thinking about ZT in corporate environments and possible management via AD. I remember some discussions with the Wireguard guys about this and nowadays you can do a headless wg installation that includes limited control with policies.
A good start would be if one could install a zt headless client, ie without access to the GUI and the cmd tools, in some kind of locked down or access contoll protected mode using password, global/local policy, access controll via the zt controller, whatever.
I guess I can just manually remove the ui elements or restrict access to them. I’ll have to test on a domain controlled machine. Might be able to do some kind of restriction via gpo. Unfortunately, if access to the ui / controls can’t be restricted, using it on a desktop won’t be feasible. A shame really. The software works so well. Time to turn on the lab I guess…
Yeah, unfortunately it’s pretty symptomatic for OSS network solutions, often with minimal focus on the interface and operational needs in corporate environments. Please feel free to get in touch again if you find a good way to solve it. Have a nice weekend!
looked at that. the behavior i’m seeing is that the token file is automatically copied to the user when the ui is launched without uac prompt. even after deleting the token file from the user, simply launching the ui exe automatically copies the token back.
Hi and thanks for the info!
I’m aware of the possibility of using file configuration, but in my case I am looking for a more streamlined standard installation procedure for use in an enterprise environment.
One could of course start a customer project and develop an installation package that could be controlled using windows gpo or similar. However, I think this might be better suited for ZT Inc to make it into a standard package but I’d be happy to come up with suggestions and ideas though.
Have a nice weekend!
EDIT:
By the way, do you know if the settings offered with file configuration can also be controlled using the standard API?
I’m not sure what the issue is. Is it hard or not possible to run the installer as a user other than the end user?
Does that user have Administrator privileges?
They do not have administrator rights and I do not want them to be able to make changes, but the ui launches without uac prompt and allows them to join new networks and forget / disconnect existing networks.
@zt-travis, the main purpose of group policies controlled by active directory is the ability to install and manage software on multiple clients all together, especially in big numbers. This is how Windows is managed in the vast majority of enterprise environments.
However, an option where you are able to install a windows client without the GUI and tools would be a great start. Is it feasable do you think?
You can still leave and join networks without the GUI. If you have permission.
The question is how do we stop non admin users from doing this. if this is something that cannot be easily accomplished then there is no way this can be used in any environment at the station or server level that requires any kind of security. there would literally be nothing that would prevent a user (or someone with a stolen / compromised device) from simply connecting to another network and exfiltrating while all of the traffic at the firewall level looks ok because its zerotier and we allowed it.
WireGuard stores by default its configuration and private key in a dpapi encrypted vault. ZT could do the exact same thing by copying the entire concept from the WireGuard repo as a template.
Wanted to give an update to this. There was indeed a permissions issue on the authtoken.secret AND identity.secret files that was unintentionally making them world readable to everyone with access to the system. This prevented the UAC dialog from popping up because elevated privileges were not needed to access and copy the file.
1.10.4 has now been released and it resolves this issue. We consider this a security issue and thank you for bringing it to our attention. We’re currently awaiting a CVE number to publish this security issue & it’s associated fix under. Thanks again for pointing this out.
@zt-grant new patch seems to have restricted access correctly. only issue now is that if an unprivileged clicks the icon and uac prompts for authentication, saying no puts you in an endless loop and putting in credentials allows the user to then make changes.
You’re correct. There is an additional issue there. I’ve opened an issue in the appropriate repository
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.