Closed andreas-p closed 7 months ago
This sounds like the wrong approach to me.
OpenVPN 2.6 and OpenVPN 3 Linux should support more ways of deferred authentication. The client can get an "authentication failure" with a request for further authentication; known as the dynamic challenge protocol. I don't have a perfect example to provide, but I believe it should be possible to test and build a test case out of the sample/sample-scripts/totpauth.py example.
So if the plug-in you use could be extended to support this approach, this should be possible to be done without modifying OpenVPN at all.
@dsommers AFAICS the scripts are called after common_name is set, i.e. username has already been retrieved.
@andreas-p you are mixing here some short coming of the OpenVPN server impelmentation with the protocol itself. The protoocl itself will already use empty user and empty password to indicate that no user/password has been provided.
I am not sure what providing some random username/password will accomplish here that gets ignored on the server anyway. And providing null data is just what the protocol already does when you do not have the auth-user-pass
option in your config.
@andreas-p common_name is not the same as username. common name comes from the certificate. There is an option username-as-common-name
for OpenVPN 2.x but these two are two different things.
@schwabe With "protocol" mentioned in the first post I meant not the OpenVPN-Protocol itself, but the user/passwd handling of openvpn3 itself. To make my statement more precise: I believe that deferred auth (from scripts or webauthn or so) is always performed after any normal auth, certificate and/or username/password, right? Which means I can't suppress the password by script.
Yeah you have to precoinfigure if you want to ask username/password or not by adding or not adding auth-user-pass
in the client config. I am not sure what problem you are trying to solve here on the client side.
So just to conclude here.
auth-user-pass
option in the client configuration will request the client to ask for user credentials before connecting. This option may not be needed in all configurations--verify-client-cert
option in the man page for details). Client configuration does not need to have certificate/key configured.Is something unclear here?
I'm converting this issue to a discussion, as this does not look like an issue OpenVPN 3 Linux need to solve programmatically.
To use an external auth solution, my vpn server is configured with management-client-auth and the clients have user-auth-pass. using the oauth2 management client from https://github.com/jkroepke/openvpn-auth-oauth2, I can authenticate using my oauth2 IDP. But auth-user-pass has one disadvantage: it will force the client to ask for username/password, which are never examined with oauth2 (and probably other management clients). Many clients can store name/password, and will never ask again for that useless input. Unfortunately, openvpn3 is explicitely designed differently, making it hard to have name/password provided automatically.
Thus I propose to invent a new option to openvpn3, which will leave the auth-user-pass client-server communication intact, but not ask for name/password, instead stuffing some random or null dummy data just to make the protocol happy.