topic Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO in General Topics

Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Chacko42 — Thu, 24 Jan 2019 20:13:38 GMT

Hi Community,

my customer wants to use Globalprotect for on demand login with a MFA radius server.

Everything fine - configured is and it works.

Now, we want to use Globalprotect as an internal UserID source.

So every GP-Client needs to do Userlogon SSO when connected to internal network (should be completely transparent to the users). But only on demand, the users should decide to connect to GP-Portal to initiate a VPN connection to external gateway.

Because we cannot expect from the endusers, to choose this GP-Portal for VPN connect, and the other one for internal GW connection, we need to use only one portal for this need.

Is that possible? How to configure it? Auth Sequence with first SSO, second RADIUS? How to do User-Logon SSO when connected interanl and only on demand when connected to external ?

Best Regards

Chacko

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

OtakarKlier — Thu, 24 Jan 2019 20:56:41 GMT

Hello,

Check out these videos, I think they are what you are looking for.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm2uCAC

Regards,

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Mick_Ball — Fri, 25 Jan 2019 08:29:18 GMT

Have you looked into using regions in your external gateway config.

Regions take priority over "Gateway Priority" so add all internal gateways to your portal config but add regions to the internal ones.

Available on 8.sumfink

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Mick_Ball — Fri, 25 Jan 2019 09:29:40 GMT

Hmmm... just re read your post... so you want users to auto connect when on the lan but on demand connection when not on the lan....

this is before you even consider what auth methods to use...

i dont get it... sorry. would you not be better off with captive portal when on the lan?

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Chacko42 — Fri, 25 Jan 2019 14:16:30 GMT

Well, we want to user internal Globalprotect to get more resilient UserID information and to prevent policiy-mismatches, when the users aren't spamming any Kerberors tickets - so internal Globalprotect with mode "User Login" and Kerberos SSO would be the way to go.

But the same users/devices should be allowed to do internet stuff when beeing external and they should decide when to use VPN, so this is a thing for "on demand" mode.

We cannot expect, that the users will be happy with using different portals - that must work transparently.

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Mick_Ball — Fri, 25 Jan 2019 15:42:20 GMT

I can't think of a solution to this.

almost... as you can have regional gateways for different auths depending on your location and you could have 2 portals, one internal and one external and let your DNS point you to the correct one..

but even then, you will need to manually connect to the internal portal to get the setting put back to always on...

Good Luck...

Mick

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Chacko42 — Mon, 28 Jan 2019 15:40:38 GMT

Thanks, I guess I need to try this out.

Problem is the connect mode - I would need userlogon for sso and on demand for external auth.

I will check this out and call out for our Palo SE if it doesn't work - this should be a common setup I assumed

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Jan_Linhart — Wed, 31 Mar 2021 08:56:11 GMT

Hi @Chacko42

Any news about this setup? I have exactly the same use case to solve.

Thank you,

Jan

Re: Globalprotect: Externel On Demand logon with RADIUS, internal SSO

Chacko42 — Wed, 31 Mar 2021 09:35:54 GMT

Hi Jan,

internal host detection won't work with on demand setup.

So the customer needs to choose.

From my point of view, always on is the only secure version and on-demand should be avoided.