Cannot launch OpenVPN GUI without admin privileges

[hakster]

I am running 64bit Windows 10 (1607 14393.576). I was running OpenVPN 2.3.13 (default install options and path) with no issues. I downloaded "OpenVPN 2.4.0 -- released on 2016.12.27" from the community section of the main web site. I installed it with all default options, except that under "Advanced" I de-selected "auto-start GUI upon user logon". It installed fine with no errors.

However, when I run the GUI, I get "CreateProcess? failed, exe=C:\Program Files\OpenVPN\bin\openvpn.exe", cmdline=openvpn --version dir=C:\Program Files\OpenVPN\bin".

The paths look correct, and have not changed between 2.3.13 and 2.4.0. Registry values under HKLS and HKCU look correct - but not 100% sure if relevant settings are in the right one or if this matters. The 3 OpenVPN services are installed, with the new one running - tried rebooting and restarting the running service, no change.

Also - running the OpenVPN GUI "as Administrator" everything works perfectly. Similarly, the command line also works fine "as Administrator". With admin rights, the command line fails with access denied on the route additions, but this may be expected.

[Selva Nair]

The title says "cannot launch GUI with admin.." but the description appears to indicate the issue is with running the GUI as user which is how its supposed to be used in 2.4.

So assuming that running the GUI as user failed in CreateProcess?, it looks like the user has no access to the installed location. The service is not used at this initial stage where only the version is checked.

Please test the following: open a command prompt as user (not an elevated prompt started as admin) and cd to C:\Program Files\OpenVPN\bin. Then run

.\openvpn.exe --version

[hakster]

Firstly, apologies for the typo in the subject line (and also on the last line of the description!) - as you spotted, rather than "with admin rights" it should say "without admin rights" in both cases. Everything works fine as it did in 2.3.x WITH admin rights - the above is all about when it is run WITHOUT (which is the new capability, and the new default).

When running an elevated cmd prompt, running .\openvpn.exe --version returned the expected text in the console window. When running non-elevated, it threw up a UAC prompt - if I said "No", then it said "Access Denied" on the console window, if I said "Yes", than another window seemed to flash for a second, but there was only a blank line on the original cmd console window itself. In both cases, the version text output was missing (unless it was part of the other window that flashed up - too quick to see).

Your helpful reply made me look at file system permissions, but my user (unelevated) did have read permissions to the OpenVPN folder under Program Files. I then spotted the problem - the openvpn.exe file had a little UAC Windows shield icon showing in the corner of the icon in Explorer (sorry if this has a more technical name). I checked, and it had "Run this program as an administrator" ticked under the Compatiblity tab. When I unchecked that option, the little shield disappeared, and everything started working. So that I think explains it.

Now, I did NOT set this property on the file in C:\Program Files\OpenVPN\bin\openvpn.exe. However, I did set it on a shortcut pointing to this file when I used to run 2.3.x (the reason being that I use the command line since the GUI did not use to support 2FA via the static challenge, and I didn't want to have to right-click run as admin each time). What I did NOT know then, but can confirm now, is that when you change this "run as admin" flag on a shortcut, it sets it on the file itself (not nice in my view)! So that was the root cause. I am not 100% sure, but I believe that this flag persisted across the upgrade I did from 2.3 to 2.4. Of course, it is a matter of debate whether that is a defect in the installer to not reset that - probably not, if it is a meta OS property that the user has previously set explicitly.

Finally - as I said, with that change made, everything works OK. However, when using the command line, I have spotted a difference when running with admin and without admin. Without admin, there are a lot of route addition failures, but the routes ARE still somehow added. So this may be just cosmetic, and expected. I have attached some output of the "without admin" case below:

Wed Jan 04 10:59:49 2017 Route addition via IPAPI failed [adaptive]
Wed Jan 04 10:59:49 2017 Route addition fallback to route.exe
Wed Jan 04 10:59:49 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Wed Jan 04 10:59:49 2017 ERROR: Windows route add command failed [adaptive]: returned error code 1
Wed Jan 04 10:59:49 2017 C:\Windows\system32\route.exe ADD 10.254.128.0 MASK 255.255.128.0 10.254.2.1 METRIC 101
Wed Jan 04 10:59:49 2017 ROUTE: route addition failed using CreateIpForwardEntry?: Access is denied. [status=5 if_index=17]
Wed Jan 04 10:59:49 2017 Route addition via IPAPI failed [adaptive]
Wed Jan 04 10:59:49 2017 Route addition fallback to route.exe
Wed Jan 04 10:59:49 2017 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Wed Jan 04 10:59:49 2017 ERROR: Windows route add command failed [adaptive]: returned error code 1
Wed Jan 04 10:59:49 2017 C:\Windows\system32\route.exe ADD 10.1.0.0 MASK 255.255.0.0 10.254.2.1 METRIC 101
Wed Jan 04 10:59:49 2017 ROUTE: route addition failed using CreateIpForwardEntry?: Access is denied. [status=5 if_index=17]
Wed Jan 04 10:59:49 2017 Route addition via IPAPI failed [adaptive]

[Selva Nair]

Those route addition failures are real and routes are not added. When openvpn is started from command line as a limited user, interactive service is not in use and tasks like adding routes will fail. When started from the GUI it uses the interactive service and although openvpn will run as user route addition is done by the service and would work.

The GUI now supports static and dynamic challenge response. If there are other desirable features missing from the GUI please submit a feature request here or to the GUI github page ​https://github.com/OpenVPN/openvpn-gui/issues

[Gert Döring]

Selvanair, thanks for taking care of this - I find it amazing that the shortcut "run as admin" flag could "survive" the upgrade, but maybe it did not and was re-applied when clicking the shortcut for the first time...

Anyway, it's good that this could be sorted out and is not a bug in our new and shiny new no-privs-needed setup!

[Selva Nair]

I find it amazing that the shortcut "run as admin" flag could "survive" the upgrade, but maybe it did not and was re-applied when clicking the shortcut for the first time...

I was surprised too but not anymore. The run-as-admin flag is saved in the registry with the full path of the executable and its not removed when the executable is deleted. So the setting is remembered even after the upgrade.

At least this causes an error and thus alerts the user. More of a concern is about users who have done he same to the GUI. Probably not too many as we had provided a manifest to run as admin. If the GUI was set to run as admin using the compatibility mode, it will survive the upgrade. Though everything will work fine, iservice will not be used and the user will continue to run openvpn as admin.

[hakster]

Thank you very much for the quick responses and details - very helpful.

[Selva Nair]

@mattock: can we do anything in the installer to avoid such persistent "run-as-admin" flag on executables/shortcuts?

[Samuli Seppänen]

@selvanair: The "run as admin" flag does not seem to be stored in the registry, even though some sources on the Internet claim that. These are the results of my practical tests:

1. I took the sha1sum of a .lnk file before and after setting the "Run as admin" flag on it, The hash changed, and going back and forth produced the same hashes consistently. So the hash was not just changing due to a new timestamp or such. So something (=the flag) in the .lnk file was changing.
2. I also compared (diff) a registry dump before and after changing the .lnk file, and there was no difference

Then I tested creating a copy of the .lnk file, setting the "run as admin" flag on the copy and then copying the copy over the original; as would be expected, the original file (now copy of the copy) had the "Run as admin" flag set. This was with a .lnk file that only existed on a single user's desktop.

However, the NSI installer in openvpn-build uses "SetShellVarContext all", which means that when it creates shortcuts it puts them to C:\Users\Public\Desktop. These shortcuts are not synchronized to each individual users' desktops, but they do show up in there automatically. Removing the shortcut actually means removing the file from C:\Users\Public\Desktop, which means that unprivileged users are unable to do it.

Now, If I copy, say, OpenVPN GUI.lnk, to a user's desktop, then a second shortcut pops up to the desktop. This second shortcut is independent of the public ("All users") one, and has different "run as admin" flags and all.

It seems that there's not much we should or could do here. If the user has made a local copy of the shortcut on his/her desktop, then all bets are off. If there is no local copy, then any changes we make to the global shortcut under C:\users\Public\Desktop should be immediately visible.

[Selva Nair]

@samuli: My tests showed it gets added to the registry. I think the difference is whether the flag is set on a shortcut (that's what I tested) or exec itself (not tested). If a user who has no write access to the executable does it on a short cut they own, its saved in HKCU; if an admin does it on a global shortcut or "apply for all users" (or some such) is selected it goes into HKLM.

Could you please try setting run as admin flag on the global shortcut and check name-values under regkey HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers ? There is also similar entries in HKCU which gets set if its for one user

[hakster]

Hello,

I don't mean to intrude on an internal Dev discussion, but please let me share my findings on my own Windows 10 client PC in case it is of use, after my realisation that it was my own manual run-as-admin setting on a shortcut to the version 2.3 openvpn.exe that persisted after I installed 2.4 that had caused the issue, along with selvanair's helpful pointers before and after.

I think the run-as-admin is definitely stored in the registry, at least on my Windows 10 PC, as outlined by selvanair.

The way I confirmed this: take any .exe (I coped the openvpn.exe to my desktop) and call it something like zzzzz.exe. Search for "zzzzz" in the registry - should be nothing found. Make the .exe itself run-as-admin (right-click properties) and repeat the registry string search, and now you should see a key with the name of the full path to the .exe and value "~ RUNASADMIN" in either: HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion?\AppCompatFlags?\Layers (if making the change only for your own user) or in HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion?\AppCompatFlags?\Layers (if making it for all users).

Then just rename the file from zzzzz.exe to zzzzza.exe - the run-as-admin shield icon vanishes - rename it back to zzzzz.exe it is comes back - hence the persistence across OpenVPN upgrade. Also, if you create a shortcut to the exe (eg. still on the desktop), and set run-as-admin on the shortcut (which is what I had done, mistakenly thinking it would not touch the original .exe itself, just my invocation of the exe) you can see the shield icon change on the original exe itself.

However, for what it's worth, in my opinion, I agree it's not clear what you can or should do here. It is likely there will be others who have done what I have done and the run as admin might persist - but since this is a meta OS setting, not clear the OpenVPN installer should "clean up". Once this behaviour is understood, it is easily worked around, and we could, if we wanted to, easily deploy a wrapper or post-install step ourselves and edit the registry to remove this flag for our end users.

Thanks again for the help, and version 2.4 is excellent with this feature and the challenge support.

[hakster]

Sorry - seems I submitted in parallel with selvanair, didn't see his reply when I Sent mine!

[Samuli Seppänen]

I did additional testing and hakster is correct: if openvpn-gui.exe is copied (not linked) to the desktop, then "Run as admin" is stored in the registry. Which makes sense, as meddling with an executable would break its digital signature (in addition to being a bad idea in general)

My earlier tests were done on shortcut files (.lnk), where the "Run as admin" flag is stored in the shortcut file itself. Thus there is no change to the registry.

As requested by selvanair above, I also set the admin flag on the global openvpn-gui.exe shortcut (C:\Users\Public\Desktop\OpenVPN GUI.lnk). This had no effect on the registry, as would be expected from the above.

[Selva Nair]

My version of Windows (Win 7 enterprise) behaves differently.

To set the run as admin flag on the global short cut (shown on desktop) I had to click on the "Change setting for all users" button (UAC pops up). Then I get the flag set as in the image shown below.

Then the following registry key gets set which refers to the executable in Program Files, not the shortcut. This one toggles on and off as the "run-as-admin" check is toggled on the short cut.

For some reason I cannot set run-as-admin flag on even user-owned shortcuts without clicking the "Change settings for all users" button and giving admin password.

Is there some setting by which this info gets stored in the shortcut and not go to the registry?

[hakster]

selvanair - my Windows 10 Pro system behaves like yours, in terms of the shortcut - setting run-as-admin on a shortcut to an exe creates an absolute path registry entry to the actual exe itself (rather than the shortcut) - ie. same as doing it on the exe itself.

Now, I have discovered yet another thing I did not know before - if you create a shortcut to an exe, you can set run-as-admin in TWO different ways. You can either go to right-click Properties on the shortcut and go to the Compatibility tab, and set it there. That is what I was doing, and that sets it on the exe itself (by which I mean, it sets it in the registry pointing to the full path of the exe - the exe is not actually modified). However, you can also go to the Shortcut tab, Advanced, and set it there too. That seems to set it only for the shortcut, not the actual exe. I wonder if samuli did it that way, and selvanair and I did it the other way, hence the different behaviours.

However my system does allow me to either set the flag for my user or all users using the first method via the compatibility tab. selvanair, I wonder, though this is a guess, if one of the various UAC related group or security policies is affecting this. I'm not an expert, but there are several of these. You said you had a Win 7 Enterprise OS, so perhaps you have some of these defined via GPO?

[Selva Nair]

@hakster: Aha -- now looking at it, the advanced option method does ring a bell but for some reason I used only the compatibility tab for these tests. Thanks for pointing this out.

[Samuli Seppänen]

As hakster suspected, I used "Shortcut -> Advanced -> Run as admin", and that is enough to explain the different behavior. I also failed to mention that my tests were done on Windows 7 Pro.

[Selva Nair]

So that makes things much clearer. For users who've set the runas-admin flag via the advanced tab, upgrade will overwrite it, others will have to manually remove the flag.

Let's resolve this as a user question and close the ticket.