Install Windows Client as NON-Administrator?

[AaronSmith]

I've set up a proof of concept OpenVPN Access Server for work, and so far it's been really nice. One sticking point is with the installation of the windows OpenVPN Connect client. I like that users can simply log in to the website and get an installer package that includes everything they need to connect, but the problem is that the install requires administrative privileges. For domain joined systems, including laptops, users do not have access to admin accounts. Is there a way around this? I was thinking maybe we could pre-install a generic OpenVPN client and then users could simply download the .ovpn file specific to them, but there doesn't appear to be such a thing. The closest I found was OpenVPN GUI, which appears to be just a taskbar program, but also apparently requires admin rights even to run.

[novaflash]

It is impossible to install OpenVPN without admin privileges, sorry.

GPO policies can do it, though; those have the required privileges.

You can also preload a generic client; it's in /usr/local/openvpn_as/etc/exe - it has no configuration of any kind.

[AaronSmith]

It is impossible to install OpenVPN without admin privileges, sorry.

GPO policies can do it, though; those have the required privileges.

You can also preload a generic client; it's in /usr/local/openvpn_as/etc/exe - it has no configuration of any kind.

Well, that might be do able. I'll try that. It might be possible to have users download their .ovpn and put it in the config folder. Is it possible to have a generic .ovpn on each machine? We aren't relying on the certificates for authentication, I have it set to use RADIUS, which does authentication to a One Time Password token provider. If we could have the config already set up, then users would only need to launch the already installed OpenVPN client, then enter their username and OTP to connect.

[AaronSmith]

I installed a copy of that generic OpenVPN connect on a test client and it worked rather well. I wasn't aware that it had an import function that a user can use to just go out and get their OpenVPN configuration with. That might just be the ticket! Thanks!

[novaflash]

Great, good to hear. Just as an aside, the import feature can be toggled on/off with a command line parameter, by the way. See https://docs.openvpn.net/under-the-hood ... ent-basic/ to learn how.

Also, every user account has its own unique set of certificates and you can't mix up credentials and certificates. A set of certificates imported from a server for user A won't work with credentials for user B, for example. The server-locked profile is the solution to that; it just contains information to confirm the identity of the server and to negotiate with the server for a connection profile that contains certificate for the specific user you're logging on as at that moment, and once the connection is dropped, that temporary connection profile is deleted from the client. The client is then again ready to accept a connection for another user, any user, on that Access Server, provided you specify the correct credentials.

It is possible to completely ditch certificates but this lowers security rather a lot - don't do that.

If user a works on machine x all the time, then what you've just tested and used is perfectly fine. If you expect machine x to be used by users a, b, c, d, and e, then you can either import profiles for each one, or use a server-locked profile instead. When you download the connect client from the access server's web interface while logged on as a standard user that has no autologin privileges, it will automatically come pre-loaded with a server-locked profile.

[AaronSmith]

Also, every user account has its own unique set of certificates and you can't mix up credentials and certificates. A set of certificates imported from a server for user A won't work with credentials for user B, for example. .

This has not been my experience. On my test client, where I installed the generic OpenVPN Connect client, I imported a profile by logging in as User A, and then connected as User A. I then went through the process again on my laptop, but this time signed in as User B. I checked the Access Server and saw that a new certificate was created for User B. I then went BACK to my original test client (the one that presumably has a certificate for User A), launched OpenVPN connect and entered the credentials for User B...and it logged in and connected me just fine....

Edit: I should note that the users in this case are two users that are setup with VPN tokens via our OTP server that works via RADIUS. User B, in the case above, had never logged in to OpenVPN until I set it up on my laptop. And when I say "A certificate was created", I'm merely assuming this because I was given the option to revoke it from the OpenVPN admin interface.

[novaflash]

Most likely you used the import from server feature which selects the server-locked type. If you save a user-locked profile from the web interface to your hard disk and then import it, it will be a user-locked profile with the restrictions I described.

[AaronSmith]

Ah ok. I did indeed use import from server. That seems like the easiest way for users to get OpenVPN set up. Since we're using OTP tokens for authentication, I'm not overly concerned with the profiles being locked to a user as the VPN tokens can fill in for that job.

[Daimroc]

Ha ve you tried to set the subetnet topology? In this case I run the OpenVpn client with a non administrator privileges and it works.

[novaflash]

Ha ve you tried to set the subetnet topology? In this case I run the OpenVpn client with a non administrator privileges and it works.

This has nothing to do with this case, but thank you for your input.

I'm locking this topic since it is resolved.