Opened 4 years ago

Closed 4 years ago

#810 closed Bug / Defect (fixed)

OpenVPN 2.4 Interactive Service Cannot access user folder

Reported by: jiquera Owned by: Selva Nair
Priority: critical Milestone: release 2.4.1
Component: Generic / unclassified Version: OpenVPN 2.4.0 (Community Ed)
Severity: Patch Queue: New / awaiting ACK Keywords:
Cc: Selva Nair

Description

The new GUI suggests to store config files in c:\users\<user>\openvpn\config

However, the IService cannot reach that without impersonating the user first (which it doesn't) Which results in the following error:

You specified a config file location (...) relative to (...) which requires administrator access. add your account to "OpenVPN Administrators" group

The error is hard to read and not logged to the logfile.

Change History (38)

comment:1 Changed 4 years ago by Gert Döring

Cc: Selva Nair added

Well, this is not due to "cannot reach that" (the iservice is not actually reading the file), but due to policy reasons.

Only members of the "OpenVPN Administrators" group are allowed to install their own openvpn configs, while "normal users" can only start openvpn with configs installed by the system admin in the global openvpn config directory.

The GUI should print this error message quite clearly? (And of course it doesn't go to the openvpn log, as openvpn is not started)

comment:2 Changed 4 years ago by Selva Nair

To start arbitrary configs from user profile either the user has to be a member of the administrators group or of a special group named "OpenVPN Administrators".

The GUI detects this condition and should show a dialog like the following:

https://ibin.co/37cg7rulHuwu.png

Click "Yes" and it will open up a UAC prompt for admin access, add the user to the special group and then complete the connection. Clicking "No" will abort the connection.

The message you posted appears to be from interactive service itself and should not have happened as the GUI will not start such a connection until the user is authorized. Do you see a dialog like above?

Last edited 4 years ago by Selva Nair (previous) (diff)

comment:3 Changed 4 years ago by jiquera

that is... unexpected behavior as the logs do go to that directory. Does OpenVPN create this "OpenVPN Administrator" group? Or am I supposed to create it manually (it doesn't exist on my system)

Running Win7 Pro 64x btw

EDIT: No I do not see that dialog. I get the following screen:

https://ibin.co/37edJhxh1Y82.png

There is no "OpenVPN Administrators" group (and manually creating one doesn't seem to do the trick)

I am local admin (but I'm running under a policy, is there something that could be conflicting?)

The confusing part is, when i close the dialog everything disappears and I can't read it anymore. The only line written to the log is the "OpenVPN not started due to previous errors" line... and since there are no previous errors (as they are not written to the log it confused the hell out of me)

Last edited 4 years ago by jiquera (previous) (diff)

comment:4 Changed 4 years ago by Selva Nair

In v2.4, logs are written to OpenVPN\log\ inside the %userprofile% no matter where the config lives, as GUI and openvpn now run as user and can only write to user's profile. However, allowing a user to run an arbitrary config from their profile is something needs to be "authorized". Hence the check on whether the user is authorized: i.e., is a member of either the admin group or of a special group named "OpenVPN Administrators" by default (could be changed by the admin).

Do you see the dialog offering to add the current user to this special group (see the image in my previous reply)? This should popup whenever a config in userprofile is started and the user is not authorized. If you do see it, click yes and it will do the needful -- only need to be done once. If the popup is not shown something is wrong: you could try manually creating the group then adding your username to it.

comment:5 Changed 4 years ago by jiquera

you're too fast ;) I was still editing

comment:6 Changed 4 years ago by Selva Nair

I am local admin (but I'm running under a policy, is there something that could be conflicting?)

Could be.. If the GUI concludes that you are a member of the admin group (i.e the user can potentially can escalate privileges without needing a password), it will pass the config to interactive service without showing that dialog. This check in the GUI is done to precisely avoid the problem you are seeing --- that is to avoid the interactive service to reject the config with a cryptic message. However it seems the GUI thinks you are admin but the service doesn't. I've never seen that happen -- could be due to the policy restrictions.

The confusing part is, when i close the dialog everything disappears and I can't read >it anymore. The only line written to the log is the "OpenVPN not started due to >previous errors" line... and since there are no previous errors (as they are not >written to the log it confused the hell out of me)

The log is written by openvpn which is not even started at this point when the service rejects the config. For the GUI we currently do not have a way to persist the status log window -- generally its the same as what is in openvpn log except in such early failures.

The easiest solution would be to manually add a group named "OpenVPN Administrators" and make the user a member of it. The group doesn't need any special permissions; its used only as a validation that the user has been "blessed" by the admin to do anything they like with openvpn.

The error you get from the service is also written to the event log.

Last edited 4 years ago by Selva Nair (previous) (diff)

comment:7 Changed 4 years ago by jiquera

Creating an "OpenVPN Administrators" group and adding my account (which is in a domain) doesn't help. I guess the domain is not visible for the service or something...

For me it is not a big problem, as I can just use the system folder (although I prefer the user folder). Is this something you want to debug further (I'm willing to keep trying).

Another thing, I had the same config file in the system and in the user folder at some point. After reboot OpenVPN gave an error that that was not allowed. When i renamed the one in the system folder, I immediately got a blue screen. (is that something worth debugging?)

comment:8 Changed 4 years ago by Selva Nair

Looks like the problem is because of the way GUI and service does user lookup. The GUI qualifies username with domain but iirc, the service does not. I have to confirm this and if so will propose a fix. In any case make sure net localgroup "OpenVPN Administrators" lists the user as a member.

Multiple configs with same name are ok, the GUI will just warn about it and ignore the second one. But it scans the userprofile first which may not be what you want. Renaming the config when the GUI is running is also ok, the GUI rescans the config directory every time one clicks on the tray icon. If a connection is active when a config is renamed, a SIGHUP restart will fail as openvpn.exe cannot re-read the config, but nothing should crash because of that. Disconnect followed by starting the newly named config should work. All with the GUI running.

By blue screen you mean windows crashed? That's totally unexpected.

comment:9 Changed 4 years ago by Selva Nair

Owner: set to Selva Nair
Status: newaccepted

comment:10 Changed 4 years ago by Selva Nair

Milestone: release 2.4.1

comment:11 Changed 4 years ago by jiquera

Running net localgroup "OpenVPN Administrators" from the cmd does list my user name as part of the domain: DOMAIN\user

However, it doesn't change anything relating to this issue. Are you sure I don't have to set specific rights to this group?

The BSOD I can not reproduce. My guess is that it was an unfortunate interaction with Kaspersky which is known to harass my system. (I'm already happy it didn't screw up my disk encryption :p)

Last edited 4 years ago by jiquera (previous) (diff)

comment:12 Changed 4 years ago by Selva Nair

After reviewing the service code, I'm pretty sure this is due to the service checking the username locally instead of in the AD. I think you will see "user not found" logged by the service.

Will post a fix soon.

Edit: I meant logged to the event log by the service.

Last edited 4 years ago by Selva Nair (previous) (diff)

comment:13 Changed 4 years ago by jiquera

Today for some reason I did get the proper warning from the GUI. Asking if I wanted to be added to OpenVPN Administrators. After clicking yes I got a UAC prompt, which I allowed and then the message:

"Adding the user to "OpenVPN Administrators" group failed."

Just thought you'd like to know :)

comment:14 Changed 4 years ago by Selva Nair

The GUI checks the group membership using DOMAIN\username which could fail if the Domain controller was not reachable. That could also explain why it showed the prompt.

I am working on a patch for the service that avoids contacting the DC so that users logged in with cached credentials will not face this. The same could then be done for the GUI.

comment:15 Changed 4 years ago by jiquera

makes sense, let me know if you want me to test that patch for you

comment:16 Changed 4 years ago by Selva Nair

I have posted a patch to https://github.com/selvanair/openvpn (branch validate-user)
A prebuilt executable for the service with some instructions is [here](https://github.com/selvanair/openvpn/releases/tag/v2.4_validate)

Although the existing GUI should work if a DC is reachable, a patch for the GUI that relaxes that requirement is [here](https://github.com/selvanair/openvpn-gui/releases/tag/v11.4.0.2)

@jiquera Would appreciate if you can test it. To start from a clean slate please remove the group "OpenVPN Administrators" that you added:

net localgroup "OpenVPN Administrators" /delete would do it.

comment:17 Changed 4 years ago by jiquera

Test Results:

  • Followed the instructions of the prebuilt service
  • when starting the GUI again I get an error: service not running (task manager lists openvpnserv2.exe running instead of openvpnserv.exe)
  • after reboot this does not happen anymore
  • Connecting without access to DC results in request to add user to openvpn admin group and then fails to add
  • Connecting with access to DC succeeds
  • Followed instructions of the prebuilt GUI
  • Now connecting without access to DC succeeds as well

in the instructions of the service... shouldn't the restart service command be targeting openvpnserviceinteractive instead of openvpnservice?

Last edited 4 years ago by jiquera (previous) (diff)

comment:18 in reply to:  17 Changed 4 years ago by Selva Nair

Replying to jiquera:

Test Results:

  • Followed the instructions of the prebuilt service
  • when starting the GUI again I get an error: service not running (task manager lists openvpnserv2.exe running instead of openvpnserv.exe)

My mistake --- I wrote to start openvpnservice instead of openvpnserviceinteractive

  • after reboot this does not happen anymore

Good :)

  • Connecting without access to DC results in request to add user to openvpn admin group and then fails to add
  • Connecting with access to DC succeeds
  • Followed instructions of the prebuilt GUI
  • Now connecting without access to DC succeeds as well

in the instructions of the service... shouldn't the restart service command be targeting openvpnserviceinteractive instead of openvpnservice?

Yes it should, my bad...

Otherwise, all as expected. I will do some more tests and submit the patches for service and GUI. Thanks for your help.

comment:19 Changed 4 years ago by jiquera

You're most welcome and thanks for keeping up the good work on openvpn!

comment:20 Changed 4 years ago by Selva Nair

Priority: majorcritical
Severity: Not set (if unsure, select this one)Patch Queue: New / awaiting ACK

comment:21 in reply to:  4 ; Changed 4 years ago by adelphi

Patch is working on my site too. But:

Replying to selvanair:

However, allowing a user to run an arbitrary config from their profile is something needs to be "authorized". Hence the check on whether the user is authorized: i.e., is a member of either the admin group or of a special group named "OpenVPN Administrators" by default (could be changed by the admin).

It seems that nested groups are not supported here?
In my larger AD environment, users are already member of a DOMAIN\VPN group. If I add the DOMAIN\VPN group to the new local "OpenVPN Administrators" group, the GUI doesn't detect the membership and tries to add the user to the group. Any chance to fix that too?

comment:22 in reply to:  21 ; Changed 4 years ago by Selva Nair

Replying to adelphi:

Patch is working on my site too. But:

..

It seems that nested groups are not supported here?
In my larger AD environment, users are already member of a DOMAIN\VPN group. If I add the DOMAIN\VPN group to the new local "OpenVPN Administrators" group, the GUI doesn't detect the membership and tries to add the user to the group. Any chance to fix that too?

As mentioned in the commit message of the proposed patch., nested groups are not supported. That also means domain admins are not automatically recognized as members of local administrators group. Allowing this means access to the AD will be required if the nested group is not locally defined and could lead to erratic behaviour: that is, user will be authorized when a DC is reachable, fail when not.

Note that this group is used just a container for a list of authorized users. We could have used a simple list stored in the registry (HKLM) instead of a group. A group was chosen because the concept of granting rights through group membership is easier to convey and many users find managing groups less daunting than editing the registry.

comment:23 in reply to:  22 ; Changed 4 years ago by adelphi

Replying to selvanair:

Allowing this means access to the AD will be required if the nested group is not locally defined and could lead to erratic behaviour: that is, user will be authorized when a DC is reachable, fail when not.

Group membership also applies when the DC is not available! The group membership is cached in the user access token. Otherwise a lot of other things wouldnt't work on domain joined systems...

Not supporting nested groups makes the whole thing a nightmare on large enterprise ADs and is against all best practices.

comment:24 in reply to:  23 Changed 4 years ago by Selva Nair

Replying to adelphi:

Replying to selvanair:

Allowing this means access to the AD will be required if the nested group is not locally defined and could lead to erratic behaviour: that is, user will be authorized when a DC is reachable, fail when not.

I dropped the idea of checking for these groups in the token as that would not support adding user to the group on the fly. This feature in the GUI is very convenient for lay users, but for the token to see the change in group membership, the user will have to logout and login again.

Not supporting nested groups makes the whole thing a nightmare on large enterprise ADs and is against all best practices.

Agreed. We should have anticipated such expectations to popup once we chose group membership instead of a registry entry to store authorized users :)

What we could do to support nesting is to check the token first and if that does not find the group, check the current membership locally in "OpenVPN Administrators". Then domains can have a GPO to control it, while for non-domain users the direct check will catch membership changes without re-login.

Last edited 4 years ago by Selva Nair (previous) (diff)

comment:25 Changed 4 years ago by Selva Nair

New test binaries (service and GUI) based on patches that supports nested groups as well is here

These are based on https://github.com/selvanair/openvpn/tree/validate-user-v2
and https://github.com/selvanair/openvpn-gui/tree/validate-user-v2

comment:26 Changed 4 years ago by adelphi

Thanks! It did work perfectly in my environment.

New binaries tested on german Win10 64bit (1607) without administrative rights. Group nesting was done according to AGDLP rule:
Domain user account member of domain local "DL_VPN" group which is member of a global group "G_VPN" and finally member of the local "OpenVPN Administrators" group. No DC was available during connection. Connection has been successfull using cached access token.

comment:27 Changed 4 years ago by Selva Nair

@adelphi Thanks for testing. Will now submit the patch/PR for review.

comment:28 Changed 4 years ago by wow64

Ignore.. it works with AzureAD accounts (v2 branch).

Last edited 4 years ago by wow64 (previous) (diff)

comment:29 Changed 4 years ago by Selva Nair

I think it should work.
Could you please login as this AzureAD\User1 and run
whoami /groups
from a commandline? If the list of groups and SIDs that generate does not have machine_name\OpenVPNAdministrators then the user's token does not have the group and validation will not work.

Make sure changes to the AzureAD has propagated to the client and user is not using an old cached token.

comment:30 in reply to:  28 Changed 4 years ago by Selva Nair

Replying to wow64:

Ignore.. it works with AzureAD accounts (v2 branch).

Too late to ignore :) Glad to know it works, though..

comment:31 in reply to:  4 ; Changed 4 years ago by tschoening

Replying to selvanair:

However, allowing a user to run an arbitrary config from their profile is something needs to be "authorized".

There wasn't such a need in the 2.3 branch and still the GUI worked without administrative permissions and was able to create connections. Additionally, if the interactive service is not running, no such authorization is needed as well, which in my mind is a good thing. Having this authorization optional of some kind, e.g. depending on the service running or not, is a feature and should be seen as that.

https://community.openvpn.net/openvpn/ticket/839

comment:32 Changed 4 years ago by McNetic

I had the same problem with the current release, and tried the provided binaries and it works great. Thank you.

comment:33 in reply to:  27 Changed 4 years ago by distancesprinter

Replying to selvanair:

@adelphi Thanks for testing. Will now submit the patch/PR for review.

This fixed the problem for me too. How will we know if this will be in 2.4.1, and do we have any ETA on when 2.4.1 will drop?

Thanks!

comment:34 in reply to:  31 ; Changed 4 years ago by Gert Döring

Hi,

Replying to tschoening:

There wasn't such a need in the 2.3 branch and still the GUI worked without administrative permissions and was able to create connections.

For some limited set of "worked" - 2.3 can only configure the tun/tap interface for IPv4, but neither set up IPv6 nor install v4 or v6 routes. For many VPN setups this is close to "not working", though it pretends to.

Additionally, if the interactive service is not running, no such authorization is needed as well, which in my mind is a good thing. Having this authorization optional of some kind, e.g. depending on the service running or not, is a feature and should be seen as that.

Well, if you want IPv6, you need elevated privileges anyway - and if you run the GUI as admin, it won't use the iservice, so you get the choice.

For most normal environments, having the admin user decide at install time whether this user should be limited (= controlled environments) or be able to do what he wants is a useful thing.

comment:35 Changed 4 years ago by Gert Döring

Selva's patch has been applied to the master and release/2.4 branch.

commit e82733a1ab78062feca28578fe505b275a2356a6 (master)
commit a9743bf25e661d66ca7537adfe457e75afc947c4 (release/2.4)
Author: Selva Nair
Date: Sat Jan 14 16:16:29 2017 -0500

Fix user's group membership check in interactive service to work with domai

ns

so this will be in 2.4.1 - we have no clear timeline for this yet, but "soonish" (weeks, not months).

comment:36 in reply to:  34 ; Changed 4 years ago by tschoening

Replying to cron2:

Well, if you want IPv6, you need elevated privileges anyway

My VPN endpoints have now plans in supporting IPv6 in the near future.

  • and if you run the GUI as admin, it won't use the iservice, so you get the choice.

Running the GUI as admin is a bad behaviour and wasn't necessary in the past in many cases.

For most normal environments, having the admin user decide at install time whether this user should be limited (= controlled environments) or be able to do what he wants is a useful thing.

This argument doesn't hold, because the GUI is working partly without the service and in other cases you don't seem to care about admins too much as well:

https://community.openvpn.net/openvpn/ticket/838

comment:37 in reply to:  36 Changed 4 years ago by Gert Döring

Replying to tschoening:

Replying to cron2:

Well, if you want IPv6, you need elevated privileges anyway

My VPN endpoints have now plans in supporting IPv6 in the near future.

Well. And your VPN endpoints obviously do not have the need for extra routes - this is convenient for you, but a small minority. We need to make this work for all possible scenarios, and that was one of the biggest criticisms in 2.3 - routes not working, v6 not working, GUI needing privileges.

For most normal environments, having the admin user decide at install time whether this user should be limited (= controlled environments) or be able to do what he wants is a useful thing.

This argument doesn't hold, because the GUI is working partly without the service and in other cases you don't seem to care about admins too much as well:

https://community.openvpn.net/openvpn/ticket/838

I'm not saying we do everything right, or get it right the first time (and this is a different issue from 838, which has lots of historic baggage bundled with it, including maintainership changes, orphaned software, lack of documentation by previous maintainers, etc.)

But this is what we've decided that we want, after quite some discussion on the openvpn-devel list, IRC channel and GUI PRs - and this is what we'll stick with.

You are welcome to compile your own GUI - this is fairly trivial today - and change stuff to make it work better for your special needs.

comment:38 in reply to:  35 Changed 4 years ago by Selva Nair

Resolution: fixed
Status: acceptedclosed

Selva's patch has been applied to the master and release/2.4 branch.

commit e82733a1ab78062feca28578fe505b275a2356a6 (master)
commit a9743bf25e661d66ca7537adfe457e75afc947c4 (release/2.4)
Author: Selva Nair
Date: Sat Jan 14 16:16:29 2017 -0500

Fix user's group membership check in interactive service to work with domai

ns

so this will be in 2.4.1 - we have no clear timeline for this yet, but "soonish" (weeks, not months).

Matching patch for the GUI is now merged

Merge pull request #118 from selvanair/validate-user
Check group membership without needing connection to DC

Acked-by: Gert Doering <gert@…>

Will be in the next snapshot build and in 2.4.1

Note: See TracTickets for help on using tickets.