GlobalProtect agent download from direct URL

[FabienJ]

Hi everyone,

Do you know if it's possible to block the download of the globalprotect agent via the direct URL ? 

The goal here is to force users to authenticate in the portal web page to be able to download the agent.

Ex. for the 64bit agent :

https://<my-portal-address>/global-protect/getmsi.esp?version=64&platform=windows

If yes, could you please share the steps to solve it ?

Thanks a lot !

Fabien.

[FabienJ]

Hi Guys,

First, many thanks to @Remo and @ansharma for your time.

@Remo using your first ugly method, it sounds like it's working at the end ? You have an URL blocking page when you try to reach the downnload URL ?

You just can't get user mapping info ? Can't we tune the User-ID ACL on the zone to make this less ugly 🙂 ?

@ansharma it's a pretty interesting workaround, I need to try this one after my holidays 🙂

As you said, all vendors are using this way to delivers agents (Vsphere, AnyConnect and so on ...) but I think it's not a good thing to imitate.

My SE also suggested something that should work with hardware models, using vsys, one hosting the captive portal, then another vsys hosting the global protect portal and the agent.

...A feature request should happen soon 🙂

Thanks again !

[FabienJ]

@BPry researchers 🙂

[Remo]

---

@BPry wrote:

@Remo,

Since you are setting the GlobalProtect redirect flag you won't be able to actually get to the client download package, that redirect will force you over to the server that you set and that's where the Captive Portal piece comes in to actually get this to work. 

---

True, I somehow missed this point 😛

But this solution will force users, who connect first to the GP Portal, to log in twice - because the ip-user-mapping is not created when a user logs in to the GP Portal ...

I think we see it all in the same way: it is not really a really a problem and definately not a security issue...

... but with the GP Portal login I think that the login should be also required for downloading the software or is there another reason for a GP Portal with login form?

[ansharma]

@Remo Yes, using my method the user would have to login again but it's not because of the user-ip mapping. Authentication policy is a new feature (starting 8.0) and works slightly different from the former captive portal, although it uses captive portal as one of the pieces of configuration. 

The user would be logging in again because there are 2 independent set of authentications happening. One at the portal login page and another using the Authentication policy.

In congruence with you and @BPry, receiving GP agent directly (without having to login) does not really post a security risk. The portal authentication's real job is not to deliver GP agent, instead it's focus is during the actual VPN connection.

Regards,

Anurag

[ksauer507]

Wow thanks this thread saved my bacon this morning.

Had a user who called and said they were kicked out of the VPN this morning.  So I walked them through Windows Quck Assist to get connected. Oddly when clicking connect in GlobalProtect nothing happened.  I noticed in services.msc there was no PanGPS service at all!!!! Like how was she ever working to begin with in the last few weeks?

So in appwiz.cpl I go to "change" to repair Global Protect and sure enough it cant because its not connected in the first place to find our DFS file share!

So your link saved my bacon and I was able to throw it into chrome to download it, use my LAPS UI and get them a local admin password and walk them through the install.  They connected immediately and then I instructed LAPS to recycle the local admin password.

Awesome link, I'd never want to block it.