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 <dlen...@gmail.com> Gesendet: Dienstag, 6. Juni 2023 22:13 An: Popp, Thomas <thomas.p...@akquinet.de> Cc: openconnect-devel@lists.infradead.org <openconnect-devel@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.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?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
