Am 19.10.2022 um 01:01 schrieb Selva Nair:
Hi,
On Mon, Oct 10, 2022 at 3:14 AM Gert Doering <g...@greenie.muc.de> wrote:
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of using
auth-user-pass-optional + pushing "auth-token-user" from
client-connect
(and most likely also "from management") because we'll lock an empty
username, and on renegotiation, refuse the client with
Why is it not okay to support change of username?. I have a situation
where username change looks legitimate:
With our new PLAP (start from login screen) and "persistent
connection" support on Windows,
a connection may be started by one user and then "renegotiated" by
another who may enter
a different username and password from the initial connection (say
auth-nocache or 2FA
is in use).
In this case, the server will disable the tunnel (username tried to
change), the client will retry
asking the user for username/password input again. On inputting the
same credentials a
second time, the connection will succeed. This leads to poor UX.
If we can conjure up usernames (like with empty --> token-user) why
not allow other username
changes too?
In general the current authentication system in OpenVPN is ill equipped
to handle them. On renegotiation we only do auth but no read in ccd or
other other user specific data. So allowing a username change could in
many instances give the new user the permissions/IP etc of the old user.
There can be situations where this is okay and we can add options or
auth results that explicitly allow. In general a username change
probably leads authorisation problems. For the auth-token-user the idea
there is that you get a username on the first auth assigned that you
should use in the future but no actual user change.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
