On Wed, Jun 23, 2021, 5:41 PM O. William McClung <owmccl...@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 _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
