On Mon, Jun 8, 2020 at 1:31 AM Carlos R Tasinafo <renatot@xxxxxxxxx> wrote: > Hello there. > I wonder if someone could help me with our scenario. This is a detailed and well-researched problem statement. Nicely done. > By reading the documentation / Code I believe that this behaviour > would be related to this commit: > https://gitlab.com/openconnect/openconnect/-/commit/0303569d286d360da905b3c014daa99c65075524 Possibly related, yes. Basically, the GlobalProtect servers simply don't provide us with enough information or consistency to be sure where to fill in the token. > My question: > Is there a way to force the authentication sequence like - Pass/OTP > for Portal && PASS/OTP for GW ? Could I do this using "form-entry" and > modifying the labels on the firewall ( I have management on FW )? Yes, you could induce this behavior by modifying the labels, maybe… but how should the two OTPs be treated? Do they get the _same_ "one"-time password entered twice? Do you need to generate a new OTP the second time? > I wouldn't like to point the authentication directly to the GW using > usergroup if there is a better way Hmmmm… why NOT? ¯\_(ツ)_/¯ My recommendation is ALWAYS to bypass the GlobalProtect portal (https://gitlab.com/openconnect/openconnect/-/issues/147) interface wherever and whenever possible, and go straight to the gateway. Probably the worst part of the GlobalProtect VPN design overall: the portal and gateway interfaces are configurable separately, and most admins don't realize this, and this consistently bedeviling efforts to interact with them in a sane and consistent way. If it's *possible* to bypass the portal (and on most GP VPNs it is), then you should. The portal adds no security — in fact, it detracts from it, because it's typically possible to bypass, and often the authentication requirements of the gateway differ, and admins don't know this. The portal adds complexity and variability, and almost nothing that's actually useful to the end-user (see https://gitlab.com/openconnect/openconnect/blob/master/auth-globalprotect.c#L438-444). > If there is nothing else to do, what do you guys suggest ? > I was thinking about to hijack the cookie on the portal ( with option > --cookieonly) and use it in another attempt ( not sure if it would > work ). This will not work. The various cookies which you can obtain from the portal are not the same as the final "authcookie" which is used to start the VPN tunnel on the gateway, and which can persist for multiple uses. (See discussion on https://gitlab.com/openconnect/openconnect/-/merge_requests/109.) The naming similarity is unfortunate, but it's mainly GlobalProtect's own fault for using names like portal-prelogonuserauthcookie, portal-userauthcookie, and authcookie. Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
