Does the SSL VPN client work without Admin rights after installation 9.407

Hi Stephan

In general the openVPN-Client needs elevated rights to set the route after the communication has been established.

The Sophos derivate "Sophos SSL VPN Client" brings an additional service, which accomplishes the needed route addition with System privileges.

Therefore after installation (of course done with adminrights) you don't need any elevated rights any more to connect to the UTM and establish the needed routing on the client. -> "Standard user rights", only.

Two missing features are left over to criticise at the Sophos client if you want to:

1. No official MSI-Package available
2. Config-Files are stored in the programs path where all users have reading access but no write or modify rights -> this is kind of unlucky in two ways.

But: Both features can be worked out/ changed with some effort.

Cheers, Janbo

Hi Janbo,

yes. I know this from Windows 7. But it is great that it now works on Windows 10.

I have solved the missing features with our software distribution:

• We published the driver certificate for the Sophos SSL VPN adapter via GPO to every client.
• Install the client with

 ".\Extern$\Msidata\sophos-ssl.exe" /NCRC /S

• and use this Reg to Change the Log and Config Dir

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\OpenVPN-GUI]
"config_dir"="%LOCALAPPDATA%\\Sophos\\Sophos SSL VPN Client\\config"
"config_ext"="ovpn"
"log_dir"="%LOCALAPPDATA%\\Sophos\\Sophos SSL VPN Client\\log"
"priority"="NORMAL_PRIORITY_CLASS"
"log_append"="0"
"allow_edit"="0"
"allow_service"="0"
"allow_proxy"="1"
"allow_password"="1"
"service_only"="0"
"log_viewer"="C:\\Windows\\notepad.exe"
"passphrase_attempts"="3"
"editor"="C:\\Windows\\notepad.exe"
"connectscript_timeout"="15"
"disconnectscript_timeout"="10"
"preconnectscript_timeout"="10"
"silent_connection"="1"
"show_balloon"="1"
"show_script_window"="1"
"disconnect_on_suspend"="1"

Then we copy the config files from the zip file to the config directory specified. 

Voila .. no more errors and deployable.

Best regards

Stephan

Hi Stephan

That's a cool approach!

We do it the same way with the reg-keys (with the difference that we use the roaming part for the config and the only the local part for the logs) - but compiled an MSI with the approch of AnonIT (http://anonit.blogspot.de/2016/03/openvpn-creating-msi-installer.html) using WIX (and a modified XML). That's much easier than it looks on first sight and you receive an MSI which can be deployed silently (/qn) or with AD-Software deployment (what we make use of).

Afterwards we deploy the config files via GPO "deploy files mechanism" during user logon but with system credentials -> because the users variables are needed to match the roaming profile path and the computer privileges to access a central share that's in turn not accessable for the users (holding all config files for all users).

But coming back to your original request:

Obviously you are really in it to handle drivers and installations. And you already work with the Sophos-Client. What again was the question you had regarding Windows 10? We still work with Windows 7 and only tested with Windows 10 and I dind't recognize any problems with standard user rights. -> I'm afraid I missed something I could run into in the future with the Win10 deployment.

Cheers, Janbo

Hello Janbo,

my first install failed on Windows 10. The ssl vpn connected but could not set the routes into our network. But i will try it again. 

Maybe the client team has a working Windows 10 installation.

How do you do that? -> "(holding all config files for all users)"

Did you manage to build a cron job that exports the config files? I only know the manual process.

Danke

Hi Stephan

No - we didn't manage an automated extraction of profiles up to now (but to be honest - we didn't try).

What we do is downloading them manually from the UTM in zip-format (the way you already described) and extract them to a windows share (dfs), which provides access rights to computer-objects, only.

Deployment runs via a GPO, which runs during user logon but using the system-context -> The system with computer-privileges takes care for copying the "right" config for the user (%username%) which logs on at that moment.

Outcome is that users don't have access to the config-share (even if they don't know that it actually exists) and can't access profiles/ certificates from other users.

The automated extraction of user-profiles from the UTM (cron job) sounds attractive on first sight - but we have to onboard users manually anyway, because we have to peer the TOTP-Token for the users when setting up a new user. During that process it is not that much effort to additionally extract the users config and copy it to the share.

BUT: I'm talking about the pilot phase at the moment -> I might have a different opinion in 2 Month from now ;-)

Cheers from sunny Hamburg, Germany

Janbo