GlobalProtect gateway authorization fails

[Daniel Lenski]

On Wed, Jun 23, 2021, 5:41 PM O. William McClung <owmcclung at gmail.com> wrote:
> I could only get to the authentication (SAML login) by using -g and
> a gateway:
>
> $ gp-saml-gui -g -S us-central-g-universi.gpo2ojjg5cnn.gw.gpcloudservice.com
>
> and this led to "The application you have accessed is not registered
> for use with this service." I.e. I couldn't authenticate.

It appears that your VPN is one of the (relatively few) which don't
allow you to bypass the portal and SAML-login directly to the gateway.

> I didn't purge my package manager's /usr/sbin/openconnect but fixed that and now
>
> $ gp-saml-gui -p -S --clientos=Windows <my-vpn> -- --authgroup='US Central'
>
> uses /usr/local/sbin/openconnect -vvv --dump and produces https://bpa.st/D2QA .

Hmmm. It sounds like you've wrapped /usr/local/sbin/openconnect in
some kind of shell script which adds arguments like `--dump -vvv >
/tmp/openconnectdump`? If so, you need to be absolutely 100% certain
that your script correctly escapes arguments which it forwards to
OpenConnect.

Please add the `-v` flag to gp-saml-gui, and confirm that the SAML
'user' and 'prelogin-cookie' fields which it obtains *exactly* match
the versions sent in the 'POST /global-protect/getconfig.esp' request
(after URL-style percent-encoding). If there's any discrepancy,
there's a problem with your wrapper script.

Anyway… something unexpected is happening. In your latest
update, using the version of OpenConnect from merge-request !199, the
authentication is failing at an earlier point:

  1) Your original message: OpenConnect successfully signs into the
portal (POST /global-protect/getconfig.esp) and then fails due to not
knowing how to reuse the portal credentials in this case (which is what
MR !199 is supposed to fix).
  2) Latest update: OpenConnect fails during portal sign-in, with
error 512 (indicates that the username and prelogin-cookie weren't
accepted). Have you confirmed that this failure pattern is *repeatable*?

I looked at your detailed log and don't see any obvious reason for the
change in behavior. I haven't seen a correspondingly-detailed log for
the original case, so might be missing something there.

The most efficient way to narrow this down will be to git-bisect
(https://git-scm.com/docs/git-bisect) between the version of
OpenConnect from your original message, and the version from MR !199,
and figure out exactly where the failure mode changed from (1), which
should be *fixed* by MR 199, to (2).

-Dan