Send --authgroup as <group-select> in initial POST request

[Daniel Lenski]

On Wed, May 31, 2023 at 3:48 AM Popp, Thomas <Thomas.Popp at 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?