Hi Dan I really appreciated the deep explanation regarding the portal and gateway. We already have a working solution using "--usergroup=gateway" I will follow your suggestion and authenticate the GW only. Thank you Best Regards Carlos On Mon, 8 Jun 2020 at 20:23, Daniel Lenski <dlenski@xxxxxxxxx> wrote: > > 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
