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

[Popp, Thomas]

Thank you for your answer.

> 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"`).

Thanks, I was assuming this. So apparently I have the problem, that Openconnect does not do this subsequent POST request.

What's happening is, that the server does send a list of groups in the select form. Openconnect recognizes those, by prompting me to type in my selection if I do not use the `--authgroup`-parameter. It does recognize the `--authgroup`-parameter by skipping this prompt.
However, after the prompt (or skipping it) Openconnect does not do any further requests to the VPN server (at least `--dump-http-traffic` does not print any) but instead picks the url from the `<sso-v2-login>` from the first response and tries to open a browser with it. In this url however there is the wrong authgroup coded in (since it is from before selecting anything).

What could be the reason for Openconnect not to do the subsequent request? Is there something missing from the server response? Does Openconnect maybe pass on sending a second request if the server already send a `<sso-v2-login>`-field in the first request?

> 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?

It does not work with older clients and `--no-external-auth` unfortunately does not help.


Von: Daniel Lenski <dlenski at gmail.com>
Gesendet: Dienstag, 6. Juni 2023 22:13
An: Popp, Thomas <Thomas.Popp at akquinet.de>
Cc: openconnect-devel at lists.infradead.org <openconnect-devel at lists.infradead.org>
Betreff: Re: Send --authgroup as <group-select> in initial POST request 
 
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7746 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20230612/da1c9ccd/attachment-0001.p7s>