search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.88k stars 3k forks source link

Feature Request: Allow OpenVPN server to override common name/username of a connection #299

Open jkroepke opened 1 year ago

jkroepke commented 1 year ago

Community Note

I'm creating this feature request based the discussion from

I would like to share my use-case to give an better understand what I'm currently try to do:

OpenVPN 2.6.0+ give me the capabilities to delegate the authentication to external SSO/IDP by using the deferred auth mechanism. Currently, I'm develop a server-sided program with allows OpenVPN SSO Authentication with initially supported AzureAD and could also support Keycloak later. The auth flow based on the OAuth 2.0 device authorization grant flow.

In that case from OpenVPN point of view, the connection from a user is initially credentials-less/identity-less. (it up the admin later to use an additional client-certificate). Client credentials (username/password) are not entered at OpenVPN anymore, instead the server send a browser based login page to the client using the OPENURL feature..On the login page, the user enters username, password and MFA. Since the login is inside the browser, additional protection like conditional access can be applied (depends on the feature set of the IDP).

On server side, the auth-user-pass-verify script continues pulling the IDP endpoint and wait until the user is logged-in or the timeout is reached.

Path to the auth-user-pass-verify: https://github.com/jkroepke/openvpn-auth-azure-ad/tree/v2. The v2 is not released yet. v1 is using the OpenVPN management interface together with abusing the dynamic challenge method which I would like to deprecate.

After reading the discussion to [Openvpn-devel] TLS: do not lock empty usernames, I though If changing the username is a no-go in after a successful initial authentication, what about changing the username on a initial authentication and push the information back the user? In my case, the auth-user-pass-verify script gets the information which user has logged-in. If the script cloud override the username on the connection, the idea could benefit together with the username-as-common-name option from a lot of existing OpenVPN features like ccd, auth-token or connection statistics and there is a 1:1 relation between the authenticated user and the logs on the OpenVPN server.

It should resolve the caveats from the discussion, since the username is changed on an authentication level and can be locked as currently designed.

jkroepke commented 1 year ago

Please let me know, If I should repost this on the openvpn-devel mailing list. I'm way more familiar with GitHub.

schwabe commented 1 year ago

pushing the username to the user is by no mean reliable. auth-token-user exist but only a subset of clients versions actually supports it. And on a lot of clients that support auth-token user, expiry of the auth-token by receiving AUTH_FAILED,SESSION will lead to the client requesting username/password as at the time auth-token was introduced it was only used in 2FA contexts with user/password. So these clients have a hardcoded assumption that auth-token expiry is equal to rerequesting username/password.

Also we need to be careful with setting the username. Deferred auth completion takes places after we lock the username. So we have to very careful consequences with setting the username later.

So we could introduce something like set-auth-username that could go into client-connect/ccd/client-auth response that would override the username and set it to something else. And then we probably need something like a flag of allow-old-username.

The problem about changing username is not necessarily that we don't want/allow it. But currently that it opens a bag of other issues that come with allowing it. So far I am not sure what a good solution would be here.

jkroepke commented 1 year ago

auth-token-user exist but only a subset of clients versions actually supports it.

At least for my use-case, this isn't a problem. I have also a dependency against SSO OPENURL, which also only a subset of clients understand.

I understand that auth-token was introduced for MFA authentication. But since users can configure deferred auth and SSO/OPENURL without writing a management client, auth-token could also use a "remember me" functionality to skip the whole SSO login process on TLS soft reset (reneg-sec).

Something like set-auth-username looks good to read, but I'm far away to understand the consequences here.

jkroepke commented 10 months ago

Another use-case for override clients username would be statistics.

If client certificates are omit (because of WebAuth), then OpenVPN status looks like:

root@localhost:~# cat  /var/run/openvpn-server/status-tcp8001.log
OpenVPN CLIENT LIST
Updated,2023-12-27 08:10:21
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
UNDEF,219.93.0.130:48881,1784,3808,2023-12-27 08:10:02
UNDEF,219.93.0.130:58579,1558,3660,2023-12-27 08:10:16
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.36,UNDEF,219.93.0.130:58579,2023-12-27 08:10:19
10.8.0.37,UNDEF,219.93.0.130:48881,2023-12-27 08:10:20
GLOBAL STATS
Max bcast/mcast queue length,2
END

Since we do not specify a username anywhere, which can later be used as CN, it is not clear which user is which client (Common Name = UNDEF)

andreas-p commented 8 months ago

@schwabe You're mentioning CHANGING the username, but apparently it is still unset when the deferred auth takes place. So to keep the the "bag of other issues" as small as possible, checking for previously unset username might help. Deferred auth isn't really complete if the user is only authenticated as "some unnamed dude we know".

schwabe commented 8 months ago

@andreas-p internally that is still changing from the empty username "" to some other username. The username gets transmitted very early in the OpenVPN handshake and OpenVPN currently sticks that username whether it is empty or something else. Allowing to change from "" to another username still needs to check if that is well handled and not same parts of OpenVPN still use "" or (printed as UNDEF but really "") as username.

jkroepke commented 8 months ago

Could be a display name field a possible solution? An additional, server exclusive field used in log output and stats?

aprudnev commented 8 months ago

Actually, it is important. We just created POC of WebAuth and OpenVPN (using Ping Federate as IdP). It works well. But when we try to match IP assigned to the session, and user's name, we have a problem, and it is serious. User's name is reported by plugin (openvpn-auth-oauth2). IP is reported by openvpn. There is not a single field which allows to match. And it is absolutely critical to know user name in every openvpn log message.

it can be any name, better sub (from the token), but it is not critical - critical is to always have some name from the OIDC token in OpenVPN expecially in the messages related to IP assignments. As it is a very common case - track IP / time / port to the end user who used it (we have such trackings every few month, for example).

aprudnev commented 8 months ago

Other interesting problem related to logout (as usual, login/connect is way easier vs logout/disconnect). We want to clear session on explicit disconnect - if user disconnected he DISCONNECTED. ideally I would like to send user to logout page of our / his IdP. I do not see how to do it.

Else user stay connected even if disconnected - if someone takes his device and click on VPN he will be connected even if his MFA device is not there. Which violates security. At least, user need a choice to just 'disconnect temporarily' and 'logout from SSO session'.

schwabe commented 8 months ago

@aprudnev That is more a problem of your authentication stack than OpenVPN itself. For what you are describing you probably want to use an authentication backend that generates the auth-token itself and tracks/logs it and can invalidate it rathre than to rely on auth-gen-token which does not have that invalidation support.

aprudnev commented 8 months ago

This is partially true. Our POC uses openvpn-auth-oauth2 plugin. It all works pretty well, but we (still, even as I added 'use user name as common name' option) still do not see exact user name in the logs (system still report me name from the certificate), and it is a huge security issue. If someone uses certs / 1 cert per client, it makes perfect sense, but it is actually OIDC token which provides proof of authentication.

So for invalidation, the only issue we see is that we would like to have a way to call some URL on disconnect, exactly as we called other URL on connect for authentication. We expected this problem, and It is possible that it have easy solution, it is too early to consider anything (as our POC went alive just today). But this is a very common problem with all SSO / OIDC systems, so it is possible that some support in the server may help here, I just do not know yet. As I said, we just started to work on this, and we did not find / use all possible options. Both problems (user names in the logs; session disconnects as full disconnect) was expected and well predicted, as they are very common for SSO systems.

schwabe commented 8 months ago

I think the openvpn-auth-oauth2 plugin should just log username and so on for that connection. Yes setting the OpeNVPN username would be nice in this scenario but that does not excuse the plugin from not properly logging all the required information.

aprudnev commented 8 months ago

It logs username. BUT, it is absolutely critical to link IP assigned by OPENVPN (and session) with user name. One of security requirements is all access events must be logged, together with - external IP, user-s name. internal IP, in and out time. IT is necessary to investigate any security event / violation / etc. We managed to do it for OpenVPN @ PFSense (except, it do not send client-s IP by Radius and it actually is a big problem), and here , in test system which runs OVPN 2.6.8 + openvpn-auth-oauth2 with PingID/PingFederate as IdP. we see user names in one place, and IP and session, in another, without an easy way to link these events. OVPN reports user name as certificate CN or empty (if I add an option to use username as common name). And it makes security violated

On Mon, Feb 26, 2024 at 9:41 PM Arne Schwabe @.***> wrote:

I think the openvpn-auth-oauth2 plugin should just log username and so on for that connection. Yes setting the OpeNVPN username would be nice in this scenario but that does not excuse the plugin from not properly logging all the required information.

— Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/issues/299#issuecomment-1965827588, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2RZKTLQQ4QCBAGPADK6LYVVWY7AVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHAZDONJYHA . You are receiving this because you were mentioned.Message ID: @.***>

schwabe commented 8 months ago

@aprudnev OpenVPN provides that information in its logs and also to plugins.

aprudnev commented 8 months ago

Can OpenVPN use mapped attributes from OIDC as user name in it's logs? Of course, if it provides IP and session start/end to the plugin, plugin can log it too (and plugin can, maybe better of all, make logouts and/or invalidate sessions if they are idle for some time), but OpenVPN already try to log client-s name (I see that it use CN from certificate, or use user name if it runs user-s authentication thru the Radius), so it is very logical to use sub or username from SSO token for the same purpose.

I was able to get username in plugin logs; get IP-s in openvpn logs; no way to link them together yet (at least I did not see how can I do it).

On Mon, Feb 26, 2024 at 10:05 PM Arne Schwabe @.***> wrote:

@aprudnev https://github.com/aprudnev OpenVPN provides that information in its logs and also to plugins.

— Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/issues/299#issuecomment-1965848775, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2RZMGMA5EWSNVI4OG4E3YVVZSDAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHA2DQNZXGU . You are receiving this because you were mentioned.Message ID: @.***>

jkroepke commented 8 months ago

Hi all,

first of all, I hope we can discuss this feature request more on a technical level rather than on a emotional level.

Discussion around the auth-token is more a thing, that should be solved inside openvpn-auth-oauth2. I had a recent discussion here, but I like more the current idea, that auth-token acts more as an Kerberos ticket. And sorry here for the overload, but it looks like I have to document more precisely which feature from OpenVPN can be used in which scenario. For any future discussion points around re-authentication, please create a issue openvpn-auth-oauth2.

I would like to go a step to the initial root cause, that management clients/plugins are unable to set an username/common name for a connection.

I fell that the username/common name is missing in the OpenVPN logs is not a deal breaker. And I would agree with you @schwabe, having the username in the OpenVPN is more "nice-to-have". I can add the client IP to the logs as well, since the ClientIP+Port can be used as ID between both solutions.

This real issue is, without an username:

That is more a problem of your authentication stack than OpenVPN itself.

You are correct. It's an problem the authentication stack. But the problem can be resolved if OpenVPN server would provide a capability to set an Display Name / Username on a connection. If the Feature Request is implement, the problem is resolved, too.

OpenVPN fully supports WEBAUTH. It offers a modern authentication and is a good replacement for PKI based authentication. The SSO provider can offer any modern authentication as well. For example: FIDO2 Token, WebAuth, MFA via Push or biometric (e.g. Fingerprint). The SSO Provider can decide different action. For example: Deny logins outside of Germany or deny login on company unmanaged devices.

Manage a separate PKI for OpenVPN would be obsolete.

The standalone WEBAUTH authentication system currently lacks the comprehensive features offered by VPN configurations utilizing client certificates. I'm interested in exploring how WEBAUTH can be enhanced to incorporate all the functionalities available in OpenVPN, ensuring that users can leverage the full spectrum of features even when exclusively using WEBAUTH for authentication.

schwabe commented 8 months ago

So your real issues are basically a problem for your setup since you still rely a lot on OpenVPN's internal management features and having them work with these features, we probably need to implement a feature to set a username.

The reason that this hasn't been really done yet is that our own implementation that heavily uses webauth and external auth system also does the same heavy lifting for the other features. Instead of relying on ifconfig-pool-persist and client-config-dir, these client specific settings are also provided by the backend via the management interface. So we only use the auth-token as assigning the client a session id and basically do everything else in the backend.

So in summary, yes this is a valid feature request. But currently the lack of this feature has little consequence for most people using very advanced authentication stacks as they are not depending on the internal features that require support for that. So it currently does not get the attention that it might need. As in most OSS projects features request etc get attention priority if a developer/submitter is interested in them (either personal or because their company is interested in that feature).

jkroepke commented 8 months ago

Thats fair. And I guess all discussion points are covered for now.

Who is interested into this feature could leave a vote in form as a 👍 on the original post, to track the amount of interests.

aprudnev commented 8 months ago

Good discussion, thanks.

One more. maybe last, notice. It can be very useful if openjvpn can use groups or roles, provided by plugins like oauth2 one, to decide on IP setup. For example, we may want to assign different IP pools to the regular users and/or DevOps users. Today we do it by - configure few OVPN instances, configure few RADIUS instances, have different groups allowing access, and so on. Which is a lot of headache. This can be (maybe) done by using certificate based authentication, but it is not easy to combine with MFA which is , today, security requirement. So, if plugins can provide not just username/displayname, but something which can be used for configuration, it can be even better.

And yes, using WEBAUTH opens a huge set of options not available by traditional authentications. So it is a very big step forward.

On Tue, Feb 27, 2024 at 4:44 AM Jan-Otto Kröpke @.***> wrote:

Thats fair. And I guess all discussion points are covered for now.

Who is interested into this feature could leave a vote in form as a 👍 on the original post, to track the amount of interests.

— Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/issues/299#issuecomment-1966465743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2RZJUHVEDY54ER2KLGSTYVXILZAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGQ3DKNZUGM . You are receiving this because you were mentioned.Message ID: @.***>

schwabe commented 8 months ago

@aprudnev what you are describing is way beyond what openvpn internally does. But this can implemented with an external authentication like I described. In fact, the commercial OpenVPN Access Server implements all these features with OpenVPN but managing all this things outside of OpenVPN itself. And it is unlikely that these features make it into OpenVPN itself since people either have a full custom solution like Access Server or a small setup that does not require this.

jkroepke commented 8 months ago

@schwabe

With openvpn-auth-oauth2 in mind, there could be also an interest conflict between this feature request and commercial offerings from OpenVPN Inc.

And I expect that close to all OpenVPN core maintainer are employees of OpenVPN Inc.

I may ask myself, if even an external contribution that implements the request from me had the chance getting accepted?

aprudnev commented 8 months ago

AS supports saml only, so they can be interested in idc/oauth integration into AS version, too. (SAML is actually terrible protocol, very annoying to configure and support and not easy to scale).

As for us, we use ovpn mostly with pfsense virtual appliances (which are de facto freebsd). We run AS in past but dropped it because of high price and, more important, absence of many features like 'clients ip in radius rq', 'exposure of https port to Internet', 'single service per system' (we run 2

On Tue, Feb 27, 2024, 10:04 Jan-Otto Kröpke @.***> wrote:

@schwabe https://github.com/schwabe

With openvpn-auth-oauth2 in mind, there could be also an interest conflict between this feature request and commercial offerings from OpenVPN Inc.

And I expect that close to all OpenVPN core maintainer are employees of OpenVPN Inc.

I may ask myself, if even an external contribution that implements the request from me had the chance getting accepted?

— Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/issues/299#issuecomment-1967314915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2RZNJ4Z7LNEYRE6N3P4LYVYN4XAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGMYTIOJRGU . You are receiving this because you were mentioned.Message ID: @.***>

schwabe commented 8 months ago

@jkroepke sure external patches are accepted. I am just pointing out that almost everyone who developed for OpenVPN was part of a company and even other companies that would integrete OpenVPN in their products like Astaro in the past would choose the same approach like Access Server would use. So the effort in bringing this into OpenVPN itself from developers just hasn't been there. If someone would pick up that topic and provide patches then we would pick that up.

aprudnev commented 8 months ago

Having more functions outside of core code is, maybe, good idea, as we see the same in K8S, for example. Problem is that information must be available between components. If core assigns IP or makes a decision to do it, it needs all information from the plugin (all attributes of the connection). If a plugin or script does it, it needs all information from the core. Just now, information is separated - plugin have attributes but do not know, what core did (assigned IP, called script, and so on), core has not information from plugin. Logs are just one example of 'collateral damage' because of this.

Let's say, we want to assign VLAN and IP based on user's attributes (roles, groups, similar) - a very common and reasonable task, actually. It does not matter which exact component does it - it matters that this component needs all available information. And just now, no one such component exists.

On Tue, Feb 27, 2024 at 11:07 PM Arne Schwabe @.***> wrote:

@jkroepke https://github.com/jkroepke sure external patches are accepted. I am just pointing out that almost everyone who developed for OpenVPN was part of a company and even other companies that would integrete OpenVPN in their products like Astaro in the past would choose the same approach like Access Server would use. So the effort in bringing this into OpenVPN itself from developers just hasn't been there. If someone would pick up that topic and provide patches then we would pick that up.

— Reply to this email directly, view it on GitHub https://github.com/OpenVPN/openvpn/issues/299#issuecomment-1968359280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2RZPSWXDAULOKDOQPAJTYV3JTZAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGM2TSMRYGA . You are receiving this because you were mentioned.Message ID: @.***>

schwabe commented 8 months ago

@aprudnev what you want exists, solution like Access Server or other commercial solution have all that information.

jkroepke commented 8 months ago

I would appreciate that any future discussion, which are not in scope on the initial post are continue in a separate issue..

@aprudnev since you are prefer mail anyways, you can also use the mailing list: https://openvpn.net/community-resources/mailing-lists/

thanks!

choseh commented 7 months ago

Hi everyone, we're having the same requirement here and would appreciate an option to override the username. We're currently on an ldap setup that assigns users on ipsets based on their group memberships but want to move to Entra-ID/Azure auth. Cuirrently there is no safe way to pass the username to the second "get-group-membership-and-assign-ipset" script. Only option would be to run multiple instances of the oauth2 script which is not a great option. Please reconsider adding an option.