Opened 13 years ago

Last modified 2 years ago

#170 new Feature Wish

client up script does not see username/password env

Reported by: ksh Owned by:
Priority: minor Milestone: release 2.7
Component: Generic / unclassified Version: OpenVPN 2.2.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

The openvpn client does not see $username and $password ENV variables after successful authentificiation.

Even with script-security 3 the client is not supposed to see them.

This could be a requirement for a scripting backend solution after successful authentification.

Change History (7)

comment:1 Changed 13 years ago by David Sommerseth

Milestone: release 2.2.1
Type: Bug / DefectFeature Wish

The --up hook is to be run on the client side primarily, or on server side (but much less often), to run some extra configuration steps after the tun device have been configured by OpenVPN.

The username and password variables are only available on the server side, via the --auth-user-pass-verify script hook and/or the To be very honest, I struggle to see any use cases where the remote password is interesting for the local client. Username might in some few cases be somewhat useful, but still I struggle to see the real use case.

comment:2 Changed 13 years ago by ksh

well, the use case would be a VPN (client) solution where you need the username & password to execute some client side script after successful auth.

Imagine a solution where you want to implement an automatic VNC/RDP connect to a machine or establish a Single Sign-On (SSO) solution where you want to establish the trust to a certificate through the script. Usually it would be enough to enter the u/p once and let the script do the work. Of course i could hack the source but I see a real need for this sort of feature.

Anotehr example, why bother the user to enter passwords twice if the remote machine is, for instance, running the OVPN.

comment:3 Changed 11 years ago by Samuli Seppänen

This might be useful when used with Kerberos, for example. It's not clear if this use-case is compelling enough to warrant adding this feature. Also, the security aspects will need to be evaluated before anything is implemented.

comment:4 Changed 10 years ago by Samuli Seppänen

Anyone who thinks this would be useful feature please raise your hand. Otherwise there is a risk that this ticket will be just closed as "wontfix".

comment:5 Changed 9 years ago by giggls

Hand raised :)

Seriously I just stumbled upon this while trying to set up a scenario, where kinit (from kerberos) should be called right after a sucessfull VPN connection has been established.

It is really annoying to type the same password twice in a row. First for openvpn authentication and then again for kinit. A workaround might be using the auth-user-pass option, but I do not like the Idea of a file with a plaintext authentication password in it.

comment:6 Changed 9 years ago by David Sommerseth

I would not recommend making OpenVPN call kinit. That is just an ugly workaround. What is needed is proper GSSAPI support - which is what OpenConnect? already support.

Use case:

  • Computer is configured with recent enough kerberos 5 software which supports KDC HTTPS proxy [1]. This support is already available in RHEL7/CentOS7/SL7 and newer Fedora releases (at least after F21). FreeIPA 4.2 also supports such setups out of the box. Setting up kdcproxy is really straight forward, and the traffic can also easily be proxied over multiple HTTPS proxy servers putting the kdcproxy service which talks to the real KDC behind well protected firewalls.
  • krb.conf points at an https server which acts as a KDC proxy
  • User logs in on the computer using his Kerberos username and password, gets a ticket automatically over https
  • User starts the OpenVPN connection using GSSAPI authentication, and does not need to provide any username or password. OpenVPN server authenticates the client's ticket against the KDC.

The advantage here is that OpenVPN does not see any password at all and the password is never passed over any network, due to the design of Kerberos.

Once this is in place, we can certainly look at extending the GSSAPI authentication to also ask for username/passwords if no kerberos ticket is available, and thus get a ticket upon successful authentication. But with a properly configured setup with KDC proxy, that isn't really needed.

As a side note, I am already looking into adding GSSAPI support. But there's a lot of work left. I hope that I can get more time in the not so far future to complete this work.

[1] https://github.com/npmccallum/kdcproxy

Last edited 9 years ago by David Sommerseth (previous) (diff)

comment:7 Changed 2 years ago by Gert Döring

Milestone: release 2.7
Note: See TracTickets for help on using tickets.