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? Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
