On Fri, May 1, 2020 at 10:56 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On Fri, 2020-05-01 at 18:39 +0100, Dave Love wrote: > > David Woodhouse <dwmw2@xxxxxxxxxxxxx> writes: > > > > > The three secrets it's looking for there are the *result* of > > > authentication. Whatever you have to do with certificates, passwords, > > > SAML and 2FA aren't relevant; it just wants three things: > > > > > > • The host you ended up authenticating to (after redirects, etc.). > > > • Hash of *its* SSL certificate. > > > • The 'cookie' that was the result of successful authentication. > > > > Thanks, rather late, for this. Should that have been obvious from the > > doc somewhere I didn't find? > > I don't think so. I try to be quite good at documenting OpenConnect > itself, but documentation on the NetworkManager-openconnect interaction > has been somewhat lacking. Users *mostly* shouldn't have to care about > that. I do think it would be a lot more helpful and intuitive if nmcli could let you step through the *normal authentication forms* via the CLI, just as OpenConnect itself does. It's rather counterintuitive that the GUI forms NM presents are completely different from the ones it presents from the CLI. I'm the pot calling the kettle black here, though, because I have a backlog of a whole bunch of things I've been wanting to add to the NM plugin, though: - Advanced configuration tab with settings for: pass TOS, disable DTLS/ESP, disable IPv6, force DPD interval - Option to save not just the passwords, but the actual cookie/secrets, and retry *those* on reconnect before falling back cleanly to doing a new authentication. - Fix the longstanding issue with not being able to run Trojan (e.g. HIP report, periodic TNCC) as an unprivileged user during connection - Better connection status information: show what ciphers are being used, TLS vs. UDP > > I adapted that, using "--protocol gp -q --usergroup=gateway" in the > > authN step and extracting the gateway from the named VPN config. It > > brings up the VPN, so I'm happy, but somewhat uncleanly. First, the > > authentication command produces > > > > GlobalProtect login returned unexpected argument value arg[19]=4 > > Please report 1 unexpected values above (of which 0 fatal) to <openconnect-devel@xxxxxxxxxxxxxxxxxxx> > > I think Dan's seen a few of those, and is on the verge of making not > print that message for that particular argument. Yeah. We should remove this one. I still don't understand what it means (use IPv4 by default?) but it's common as dirt on newer GP servers, and uninteresting. Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
