Re: OpenConnect - GP - Auth issue with automation.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux