You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When executing plugins, OpenVPN currently iterates over all plugins and invokes each configured plugin, regardless of the result of the previous plugin execution. This could be potentially useful if there was an indicator of current state being passed onto subsequent plugin executions, but there's nothing visible in plugin calls as to what has already been run and what the outcome of any previous call has been, so it's not clear on why there's isn't a fast-fail with an abort of the loop when error == true.
Using the following plugin configuration as a multi-plugin use-case, with LDAP authentication being performed on user connect, then a subsequent multi-factor authentication challenge using Duo, if the LDAP authentication was to fail for an incorrect password but valid username, the Duo plugin would still be invoked and try to perform an MFA challenge through the likes of a push notification to a user's device.
Even where the user was to accept the MFA push from Duo, OpenVPN would (correctly) reject the authentication attempt for the first plugin call having failed, so the Duo push would have been unnecessary, and could potentially lead to MFA-challenge fatigue with a remote attacker repeatedly attempting connections with a valid username, or just a forced lock-out from repeated unacknowledged MFA calls even where the LDAP verification failed.
In the above scenario there's value in having OpenVPN abort plugin execution on first failure, but are there any use-cases where this behaviour wouldn't be desired? Would changing the flow in this area necessitate a new configuration flag (e.g. plugin-outcome-handling with options of fast-fail or fall-through, defaulting to fall-through for backwards compatibility), or would breaking out of the loop as soon as the error flag is set without any other conditions be a valid thing to do?
The text was updated successfully, but these errors were encountered:
When executing plugins, OpenVPN currently iterates over all plugins and invokes each configured plugin, regardless of the result of the previous plugin execution. This could be potentially useful if there was an indicator of current state being passed onto subsequent plugin executions, but there's nothing visible in plugin calls as to what has already been run and what the outcome of any previous call has been, so it's not clear on why there's isn't a fast-fail with an abort of the loop when
error == true
.Using the following plugin configuration as a multi-plugin use-case, with LDAP authentication being performed on user connect, then a subsequent multi-factor authentication challenge using Duo, if the LDAP authentication was to fail for an incorrect password but valid username, the Duo plugin would still be invoked and try to perform an MFA challenge through the likes of a push notification to a user's device.
Even where the user was to accept the MFA push from Duo, OpenVPN would (correctly) reject the authentication attempt for the first plugin call having failed, so the Duo push would have been unnecessary, and could potentially lead to MFA-challenge fatigue with a remote attacker repeatedly attempting connections with a valid username, or just a forced lock-out from repeated unacknowledged MFA calls even where the LDAP verification failed.
In the above scenario there's value in having OpenVPN abort plugin execution on first failure, but are there any use-cases where this behaviour wouldn't be desired? Would changing the flow in this area necessitate a new configuration flag (e.g.
plugin-outcome-handling
with options offast-fail
orfall-through
, defaulting tofall-through
for backwards compatibility), or would breaking out of the loop as soon as the error flag is set without any other conditions be a valid thing to do?The text was updated successfully, but these errors were encountered: