On 25/01/17 21:28, Scott Crooks wrote: > Greetings everyone, > > I'm doing some testing with moving our current OpenVPN solution to 2.4 > to utilize the benefits of the `auth-gen-token` parameter that was > recently introduced. I'm a little confused about how it works in > relation to the `reneg-sec` variable. We're using the free Authy OpenVPN > plugin (https://github.com/authy/authy-openvpn) for 2FA. > > Our authentication follows the following chain: > > 1. User must present valid client certificate (duplicate-cn in our case) > 2. User must present valid Authy token from their mobile device / browser > 3. User must present valid login credentials that are validated against > our LDAP backend > > Authy's documentation specifically says to set `reneg-sec` equal to '0' > so that renegotiation never happens; however, this was written with > OpenVPN 2.3 in mind. My questions are: > > 1. Since `auth-gen-token X` generates a token valid for X seconds, does > this mean I can turn renegotiation back on? From initial testing > (OpenVPN 2.4 on Windows 10), I set `reneg-sec` to something low (30 > seconds) to see what happened. The user is again presented with a > password prompt, which shouldn't happen.
Correct, this should NOT happen.
> 2. Does having `auth-nocache` on the client side conflict with
> `auth-gen-token` ? Do I need to remove `auth-nocache` from the client
> side to utilize the benefits of `auth-gen-token` ?
Yes, this is a bug I detected very late in the RC releases. I tried to
fix it, but first attempts exploded in my face. And haven't had time to
dig into this further.
When --auth-gen-token is enabled, the server pushes --auth-token with
some random credential it saves for this particular session. When the
client receives --auth-token push-reply, it replaces the current
password value in the user/password storage with the token value. On
next re-authentication, the client will then send username + token value
(instead of password with expired OTP). The server then matches this
token ("password") against the locally stored token in the session object.
What happens is that when --auth-nocache is used, it basically tells the
"retrieve user credentials function" to ignore whatever is stored in the
password field (where the token now resides) in the user/password
storage. And since it realises it doesn't have a password, it asks for
it again.
This is very basically what happens. And the fix is in theory very
simple (disable --auth-nocache if server have pushed --auth-token) - but
those places I tried to disable --auth-nocache didn't work or it made
things even worse in some cases (where --auth-token was not pushed).
So I have it on my TODO list ... now that people actually do test the
--auth-gen-token feature, I'm definitely going to look into it a bit sooner.
Anyhow ... quick-fix/workaround: Don't use --auth-nocache
--
kind regards,
David Sommerseth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
