Feature Request: Allow OpenVPN server to override common name/username of a connection #299
Comments
|
Please let me know, If I should repost this on the openvpn-devel mailing list. I'm way more familiar with GitHub. |
|
pushing the username to the user is by no mean reliable. 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 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. |
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 Something like |
|
Another use-case for override clients username would be statistics. If client certificates are omit (because of WebAuth), then OpenVPN status looks like: 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) |
|
@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. |
|
@andreas-p internally that is still changing from the empty username |
|
Could be a display name field a possible solution? An additional, server exclusive field used in log output and stats? |
|
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). |
|
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'. |
|
@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. |
|
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. |
|
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. |
|
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
- no way to find who had IP 10.25.25.106 today at 18:00 PST (for example).
…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
<#299 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQ2RZKTLQQ4QCBAGPADK6LYVVWY7AVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHAZDONJYHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@aprudnev OpenVPN provides that information in its logs and also to plugins. |
|
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
<#299 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQ2RZMGMA5EWSNVI4OG4E3YVVZSDAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHA2DQNZXGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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 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:
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. |
|
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). |
|
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. |
|
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
<#299 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQ2RZJUHVEDY54ER2KLGSTYVXILZAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGQ3DKNZUGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@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. |
|
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? |
|
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
- 4 ovpn services per appliance, and no one is exposed to internet
scanners). This OIDC POC is pilot project to see, how can we move from
radius to webauth, and just first results are very positive, but this all
is not for most companies who better pay for the licenses and professional
support. I do not expect conflict of interests here, vice versa.
…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
<#299 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQ2RZNJ4Z7LNEYRE6N3P4LYVYN4XAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGMYTIOJRGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@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. |
jkroepke
changed the title
|
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
<#299 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQ2RZPSWXDAULOKDOQPAJTYV3JTZAVCNFSM6AAAAAAWJRDC2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGM2TSMRYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@aprudnev what you want exists, solution like Access Server or other commercial solution have all that information. |
|
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! |
|
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. |
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
OPENURLfeature..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-verifyscript 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, theauth-user-pass-verifyscript gets the information which user has logged-in. If the script cloud override the username on the connection, the idea could benefit together with theusername-as-common-nameoption from a lot of existing OpenVPN features likeccd,auth-tokenor 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.
The text was updated successfully, but these errors were encountered: