Handle management-client-auth after plugin

[joanandk]

I am using openvpn 2.7 in server mode with openvpn-auth-ldap and openvpn-auth-oauth2. My intention is
to have username + password authentication first, if this succeeds, then oauth2 authentication.
To achieve this, I use
plugin openvpn-auth-ldap.so ldap.conf
and
management /run/openvpn/server.sock
management-hold
management-client-auth

The client has auth-user-pass option set.

This works well if one enters the correct username and password and then the tfa in oauth2, the tunnel is up.

If the user enters the wrong password, the user can request mfa information.

Shouldn't this be blocked on the server side?

Expected behavior
On the server side: If the password from the client is wrong, block further authentication methods if --auth-user-pass-optional is not set.

Version information (please complete the following information):

• OS: Debian Trixie
• OpenVPN version: 2.7_rc5

[schwabe]

You are using management-client-auth, which allows the management interface to do the authentication. Mixing management interface based auth with other authentication approaches like scripts and plugins has not been tested very well or at all.
IIrc we require all methods to eventually succeed but we do not enforce that one (e.g. plugin) needs to succeed before another (management).
Normally you would do both pending-auth (ie oauth2) and user-pass via management or both via plugin/scripts.

[joanandk]

@schwabe
Thanks. I was assuming that plugin and management port setting are not "blocking" each other.

If we have two plugins. I suppose that is also executed if the client asks to do so, and evaluated afterwards?

[cron2]

There is no "the client asks to do so". The client sends username+password, and then the auth machinery is run, possibly sending back a challenge request.

The "multiple auth methods are configured" is not a very well defined scenario. I seem to remember that we decided to go for "all methods are run, always, and all need to succeed" - so no short-circuiting (which would tell an attacker if username+password are correct, because you'd only get 2FA if you guessed the first part correctly).

So for more complex requirements I guess there is no way around extending one of the existing plugins to fully cover your use case, or fully cover it via management interface or script.

[joanandk]

the client asks to do so

Sorry for the wording. I have seen that openvpn3 connect did the following: first it asked for username+password. I provided the wrong password. It said "Authentication failed". But it still opened the URL to openvpn-auth-oauth2 plugin. I have opened a ticket there and am waiting for their answer.

Thanks and BR

[schwabe]

This might as well be just a race condition. If the ldap plugin does deferred auth, its result might take longer than the management to the URL. So this behaviour is expected. The server log should tell you what really happens. And as said to avoid this scenario is to do both stops by something that first checks passwords and then, and only after password check succeeded, sends the URL.

[joanandk]

If the ldap plugin does deferred auth

Isn't deferred auth disabled per default? If the plugin uses deferred auth, is it possible to override it via server configuration?

Thanks and BR

[schwabe]

@joanandk you want deferred auth. Without deferred auth the whole OpeNVPN process and all packet forward stops until the plugin has a verdict.

You are trying to fix a symptom here. What you would actually need is that management interface gets told the status of the plugin when it is ready. But that is unlikely to happen as mixing management and plugins/scripts is a very rare and obscure usecase.

[joanandk]

I have done some tests. It seems that openvpn-auth-ldap (2.0.4) does not do deferred auth. As soon as the ldap verification is running, I see packets loss until the ldap query is finished or times out.

This might as well be just a race condition.

If I interpret the log

connection.log

correctly, openvpn does send "AUTH_FAILED', but still continues with management command. Can you shed some light why the continuation of the management is necessary? I could imagine that you want to do other stuff than just killing the connection?

Thanks and BR

[schwabe]

Let me remind me what I wrote before:

You are trying to fix a symptom here. What you would actually need is that management interface gets told the status of the plugin when it is ready. But that is unlikely to happen as mixing management and plugins/scripts is a very rare and obscure usecase.

The management is only expected to send the client-pending-auth when it want the client to do this kind of authentication. Normally you would check user+pass via management and only if that succeeds send a client-pending-auth command OR you would have a plugin/script that does auth+pass first and then depending on the result send an auth-pending command (like in the example totp.py).

Doing one half of the authentication in management and the other half in a plugin/script is a usecase that is not well supported and you are seeing the problem when trying to do it anyway here.

[joanandk]

Hi,
Using the plugin provided by openvpn-auth-oauth2 solves the issue I have encountered.

Thanks for you support.

BR