Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Jakob Curdes]

Hi,

On Thu, Mar 10, 2022 at 4:23 PM Gert Doering  wrote:

Hi,

On Thu, Mar 10, 2022 at 12:51:51PM -0500, Selva Nair wrote:
> I missed this follow up on the devel list. Please see my reply to
> openvpn-users. If @ doesnt work there is no easy fix short of
patching the
> GUI.

We're planning a 2.5.x release "some time next week" (partly prompted
due to the OpenSSL release on 


tuesday).  So now's a good time for GUI
fixes :-)


See PR 483 

@Jakob Curdes   This could be tested using 
the CI executable here:

https://github.com/OpenVPN/openvpn-gui/suites/5617977743/artifacts/182849130
(for 64 bit Windows). No need to install --- just unzip into a temp 
folder and double click on the included openvpn-gui.exe.


Selva


Hello Selva, hello all,

I have tested the executable in the circumstances described earlier. I 
confirm the problem described (username/password auth succeeds, but 
second auth with 2FA data fails as the backslash in the username is not 
escaped this time) is solved using the binary provided. I also confirmed 
this in issue #483  .


Thank you all for your quick work. This will help us rolling out 2FA to 
a bunch of users!


Regards, Jakob

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Selva Nair]

Hi Jacob,

On Fri, Mar 11, 2022 at 3:52 AM Jakob Curdes  wrote:

> Hello Selva, hello all,
>
> I have tested the executable in the circumstances described earlier. I
> confirm the problem described (username/password auth succeeds, but second
> auth with 2FA data fails as the backslash in the username is not escaped
> this time) is solved using the binary provided. I also confirmed this in
> issue #483  .
>
> Thank you all for your quick work. This will help us rolling out 2FA to a
> bunch of users!
>
Thanks for testing.

Selva

>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Enable deferred auth for multiple plugins (RFC).

[Pete Nelson]

On Thu, Mar 10, 2022 at 12:18 PM Gert Doering  wrote:

> The actual plugin calls are no longer done with the "do them all"
> function plugin_call() (or plugin_call_ssl()) but plugin.c/plugin.h
> is changed to expose the "call one" function plugin_call_item(), and
> verify_user_pass_plugin() calls this for each loaded plugin,
> keeping track of "overall" state.
>
> key_state_test_plugin_auth() is introduced to do the
> "key_state_test_auth_control_file()" test for all plugins, and
> return "FAIL if one fails, PENDING if one is pending, SUCCESS
> if one was pending and succeeded now".
>

Since the handling is changing from "do them all' to "call one and FAIL on
first failure," may I suggest a feature enhancement?

Linux PAM uses auth plugins too, and each plugin has a control flag of
required, requisite, sufficient, or optional.  To date, OpenVPN handles
auth plugins as if each were required (proceed with next regardless of
failure), but with this patch, that will change to requisite (fail
immediately on first failure).  What if, as part of the openvpn plugin
config, we could set the behavior explicitly, much like PAM allows?

For reference:
http://linux-pam.org/Linux-PAM-html/sag-configuration-file.html

This would allow OpenVPN to handle alternate authentication paths, such as:

> plugin sufficient /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
> plugin requisite /usr/share/openvpn/plugin/lib/openvpn-auth-ldap.so login
> plugin required /usr/share/openvpn/plugin/lib/openvpn-auth-duo.so login
> skey=abc ...
>

This setup would succeed immediately if the user successfully authenticates
with a local account; otherwise it would require LDAP and Duo MFA, but
would not query Duo if LDAP failed.

Such control would be constrained by the deferral mechanism, as the
deferred result cannot be immediately evaluated, so I think it makes sense
that all deferred plugins are assumed to be required and must follow any
plugins marked as requisite/sufficient.  Alternatively, if a deferred
plugin is marked as sufficient or requisite, it could hold further
processing until the deferred result is returned, but that negates much of
the asynchronous advantage that deferral gives us.

So that config files don't need updating between versions, I think it's
also wise to use a default flag if one is not specified.  I would suggest
non-deferred results default to requisite and deferred to required.  Or if
you want strict compatibility with existing behavior, you could default all
to required.

On that note, regarding serial vs. parallel launching of multiple deferred
plugins, unless PAM-like control is implemented and plugins are allowed to
be sufficient or requisite, I vote for launching them all in parallel and
returning FAIL if any one fails.

Thanks,
--
Pete
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel