On Wed, May 31, 2023 at 3:48 AM Popp, Thomas <thomas.p...@akquinet.de> wrote: > The Cisco VPN server I try to connect to expects the correct authgroup to be > send as <group-select> in the initial POST request, like: > > <config-auth client="vpn" type="auth-request" aggregate-auth-version="2"> > ... > <group-select>correct-auth-group</group-select> > ... > </config-auth> >
<snip> > I also failed to manipulate the initial POST request form with the > --form-entry parameter, like > --form-entry main:group-select=correct-auth-group > or > --form-entry init:group-select=correct-auth-group > > I came to realize, that openconnect is designated to send the <group-select> > node, as can be seen in the code of auth.c in line 929: > https://gitlab.com/openconnect/openconnect/-/blob/master/auth.c#L929 > > However, it doesn't and I can't tell why. Any idea how to fix the problem? The way this works is a bit subtle. Providing `--authgroup Foo` on the command-line does not directly set `vpninfo->authgroup`, which means that the `<group-select>` node never gets set in the *initial* XML POST request (root tag is `<config-auth type="init">`). Rather, OpenConnect expects that the *response* to the initial POST will include a list of *allowed* groups. Something like this: <form>…<select name="group_list" label="GROUP:"><option>Foobar</option><option>Baz</option>…</select></form> After receiving that list, OpenConnect attempts to match the `--authgroup Foo` from the command line to the allowed list (https://gitlab.com/openconnect/openconnect/-/blob/master/main.c#L2762-2776), and assuming a successful match it will send the `<group-select>` in its *subsequent* XML POST (root tags will be either `<config-auth type="init">` or `type="auth-reply"`). I have never seen a Cisco server that actually requires the `<group-select>` to appear in the *initial* POST request, and am skeptical that this is what your VPN actually requires That would not allow the client to discover the allowed groups on initial connection, because the allowed groups won't be known to a client until it has connected and retrieved the list at least onece. > Otherwise the server will send a wrong <sso-v2-login> path in the reponse. > > However, openconnect v9.12-0+3.1 seems to ignore the --authgroup parameter > for that purpose. Assuming that this worked without issue on older versions of OpenConnect, I suspect that the problem you are encountering is actually the same as in https://gitlab.com/openconnect/openconnect/-/issues/620#note_1415467462, namely that the server is confused by OpenConnect v9.12 offering newer SSO-based auth modes, or *STRAP* HTTP headers. Try adding `--no-external-auth` to the command-line and see if that makes a difference? _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
