Anyone deployed Palo Alto GlobalProtect?

stevehahn
Contributor

My searches have turned up nothing. Just looking for gotchas, do's and don'ts, etc.

108 REPLIES 108

philwillchen
New Contributor III

We have, initial deploys are fine but pushing out updates to GP is more tedious.

bentoms
Release Candidate Programs Tester

@philwillchen, please elaborate. Looks like I might be doing this for iOS & OSX this month.

I asked on MacE months ago, but got no reply.

https://groups.google.com/forum/m/#!topic/macenterprise/DYsDkunPlg0

As much detail as possible please, we're moving from IPSEC using the builtin VPN client. So worried this will be a step back.

Is it a PKG? Does it have any dependencies? Remotely manageable? Is the iOS app something you've played with?

philwillchen
New Contributor III

It is a pkg just based on experience for updates to GP you had to install manually or else there would be two instances running and a lot of angry users. It actually wasn't that big of a PITA since we're a small company. Currently we are running 1.2.8-5 and it seems to be pretty stable.

Additionally PA support is pretty horrible in regards to mac support.

bentoms
Release Candidate Programs Tester

Thanks @philwillchen, we'll be deploying to 200 global mac clients.

By 2 versions, is the app bundle need as per the version number? Do the supply an uninstaller?

philwillchen
New Contributor III

What version of GP? We were just given 2.0.1 yesterday but have no intentions of deploying it at this time.

As far as the uninstaller it is part of the installer.

bentoms
Release Candidate Programs Tester

Thanks. All I know is that it's on my upcoming projects. Is there any technical documentation you can link us to?

philwillchen
New Contributor III

https://live.paloaltonetworks.com/servlet/JiveServlet/previewBody/2020-102-19-14175/GlobalProtect-Configuration-Rev-I.pdf

patrickhlee
New Contributor

Starting to look into this too and found this guide below. There's a section called "Deploy Agent Settings Transparently" in the link below that discusses setting keys in the plist /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist. However, it's not really clear what the plist structure should look like.

https://www.paloaltonetworks.com/content/dam/paloaltonetworks-com/en_US/assets/pdf/technical-documentation/pan-os-60/GlobalProtect_Admin_Guide_v6.0.pdf

dfuhriman
New Contributor

We're going through this ourselves. The structure of the plist is pretty simple (at least in our simple setup – no internal gateways, etc.). Most of the configuration is set by policy on the gateway.

Unfortunately, the client doesn't seem to respect managed preferences (we pushed it out via ConfigurationProfile). We'll probably just symlink from /Library/Preferences. It's a suboptimal result, but we'll live with it.

May try to open an RFE with PAN.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Palo Alto Networks</key>
        <dict>
                <key>GlobalProtect</key>
                <dict>
                        <key>PanSetup</key>
                        <dict>
                                <key>Portal</key>
                                <string>your_portal_hostname</string>
                                <key>Prelogon</key>
                                <integer>0</integer>
                        </dict>
                </dict>
        </dict>
</dict>
</plist>

krispayne
Contributor

Can anyone elaborate more clearly on what they've done to successfully deploy PAN GlobalProtect?

I package it up in Composer and deploy it to a test machine and the agent never connects or looks for my pfx cert in keychain.

krispayne
Contributor

In response to myself, a reboot of the machine works.

paulnz
New Contributor II

We've deployed GlobalProtect for our users however, when a user logs in a GlobalProtect window pops up asking for the user's VPN login credentials. This window pops up at every login until a user makes a successful connection to the VPN.

I can't see a setting in the UI or plist to modify this behaviour to prevent the pop up window. Has anyone got a solution to this?

Thanks,
Paul

stevehahn
Contributor

We're having this issue as well; my understanding is that this is a bug that was squashed in the latest update to the GP client, but I can't verify as I haven't tested it yet.

paulnz
New Contributor II

Thanks for the response, what version are you deploying? We're running 2.3.1-7 which appears to be the current version.

adhuston
Contributor

I've used the installer that you download form the portal site, then capture the /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist in a separate package. Then I turn around and deploy both packages. The first time the PAN VPN is launched it should start up with the portal address already filled in. As for updates, we've turn on automatic updates on our Palo so that the clients get updated when they connect.

Andy

stevehahn
Contributor

@paulnz We're still on 2.2, so sounds like the rumors of a fix were greatly exaggerated. :(

paulnz
New Contributor II

@stevehahn Do'h!

@adhuston This is the pop up window we see on each login until the user makes a single successful connection to the VPN.

1 user logs in 2 The agent appears in the menu bar
3 the pop up window appears

Do you not see this window in your deployment?

afe6847a83ae4dd58f417dbff4d48456

adhuston
Contributor

Hi paulnz,

Yep, we do see that authentication window when someone logs in. Unfortunate side affect of the application. We just try to make sure that the portal address is filled in so that end users only need to put in their credentials. We tried adding a login task to kill the service, but it keeps respawning and keeps popping up the authentication window. So much for a on demand service I guess. I would like it so much better if you could launch it interactively.

Andy

jreinstedler
New Contributor III

We're moving to GP VPN here as well and have felt the pain of the app auto-launching since we started using this.

After getting fed up with it and realizing we're not using on-demand, I went ahead and fixed it my own way:

Did a usual Composer pre-capture and then did the following...
-Installed the latest version of GP available on our PANs (2.3.0-28)
-Dropped a known good/working (see @dfuhriman's post) /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist into the correct place and set permissions/ownership - this places our VPN address in the app automatically.

Captured the changes and then...
-Deleted the LaunchAgent called "com.paloaltonetworks.gp.pangpa.plist" from /Library/LaunchAgents - this is what starting the app.

Here's a look at the result in Composer:

13907c654304473c8b24c47ca12d659c

Packaged the App and dumped into Admin...

Since doing this, I've tested and deployed it, and watched the app not auto-start anymore.

paulnz
New Contributor II

@adhuston Thanks for the feedback

@jreinstedler Awesome, I will give that a try.

jason_bracy
Contributor III

I know that this is old, but we are just looking to deploy Global Protect for Always on VPN. I found this page:
Deploy Agent Settings to Mac Clients

Thought that might help out other users searching on here.

jason_bracy
Contributor III

OK, so ignore my post. Looks like even their instructions do not work. :-(

typeraj
New Contributor III

Hi Jason,

Is there a particular part of the deployment that is not working for you? We've just finished deploying into our environment so happy to share our experience.

Raj

jason_bracy
Contributor III

The app just would not read the deployed plist file. I finally found that there is a second file installed in the users Preferences folder called "com.paloaltonetworks.GlobalProtect.plist". This file only lists the Portal address. Moving this to the /Library/Preferences/ allows the Portal to be pre-populated for the user.

I am now testing deploying this settings file alongside the GlobalProtect client to a few other users.

adhuston
Contributor

I found that it's best to deploy the plist prior to installing the PAN VPN client. That way when the installer runs and pops up the dialog to sign in for the first time it will find the plist and put in the portal address. You can do that pretty easy with the following script:

!/bin/sh

portalAddress="pan-vpn.address.com"
echo '<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>Palo Alto Networks</key><dict><key>GlobalProtect</key><dict><key>PanSetup</key><dict><key>Portal</key><string>'$portalAddress'</string><key>Prelogon</key><integer>0</integer></dict></dict></dict></dict></plist>' >> /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist

exit 0

jason_bracy
Contributor III

Tried that. No matter what I did it would not pre-populate the address. even with a restart in between installing the plist and the Client. Had to use this:

#!/bin/sh

echo '<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Portal</key>
    <string>pan-vpn.address.com</string>
</dict>
</plist>' >/Library/Preferences/com.paloaltonetworks.GlobalProtect.plist

Notice the name of the file is different.

alexyu650
New Contributor III

@typeraj I would like to find out how you guys were able to bypass the keychain access prompt. Can you provide more information?

typeraj
New Contributor III

@alexyu650 We ended up deploying the certificate to the login keychain instead of the system. It still prompts the user the first time it needs to access the cert but not after that.

alexyu650
New Contributor III

@typeraj Did you guys use a configuration profile to drop the cert into the login keychain or did you guys use a script? I currently can't get it imported using a script.

typeraj
New Contributor III

@alexyu650 Actually we kinda used both - we created the config profile in the Web App, exported it as a .mobileconfig and pushed that to a tmp folder on the users machine. We then have a script that encodes the .mobileconfig in base64 and then installs it using the profiles command.

chris_hansen
Contributor

Grr. The cert admin prompt. This is my answer to https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Requests-System-Keychain-Access-on-Mac-OS-X/ta-p/53332
I put a trusted cert somewhere and then run (as root)

security import /path/to/mycert.p12 -k "/Library/Keychains/System.keychain" -P TheCertSecretWord -T /Applications/GlobalProtect.app/Contents/Resources/PanGPS

This imports the cert to the system keychain and adds the trust for the PanGPS binary.

I'm still struggling with the whole package, and this thread has been a godsend. It will be worth it for the prelogon promise of always-on VPN.
Also special thanks @rtrouton for https://derflounder.wordpress.com/2011/03/13/adding-new-trusted-root-certificates-to-system-keychain/ with command line fu and ways to get rid of the cert after the import.
However, if the process has to repeat after every upgrade, not sure if I want to delete it.

jason_bracy
Contributor III

@chris.hansen I just add the Trusted Certs to a configuration profile. No need to manually install. Our GP Always On VPN looks for a Machine Cert which is obtained from AD by another configuration profile. So there is no need to tell the Global Protect app to use a specific cert as that is handled by the GP infrastructure.

Hope that helps.

alexyu650
New Contributor III

@jason.bracy I did the exact same thing at my last deployment of GP I included the cert needed in a config profile but when the GP app started, it always prompted for the admin name and password. Did you not get the same issue?

bradtchapman
Valued Contributor II

@typeraj @alexyu650 : if you guys want to deploy client certificates and avoid the prompt for credentials, do the following:

  • Install the root and intermediate certificates in the login keychain;
  • Install the client certificate in the keychain with a non-exportable private key, and with permission set to "Allow all applications access to this item."

The last bit is important; with 'allow all' set, users will never be prompted to enter their keychain password. This is happening because applications are being told by the security framework to request an entitlement to use that private certificate (adding themselves to the private key). This is usually a one-time deal, but if you update the application then it has to request a new entitlement. Why is this significant? Think of a rogue app masquerading as "GlobalProtect" and trying to steal the existing entitlement.

chris_hansen
Contributor

Wouldn’t this "allow all apps" setting enable a rogue GP app to access the cert?

chris_hansen
Contributor

edited previous post

simon_brown
New Contributor III

deleted

11locsMC
New Contributor

Commenting in 2019 to say that this thread was very helpful.
Just packaged PA in Self Service with the provided plist script from this thread which does successfully pre-populate the portal address. The script runs "before" the package and that's working out well.

jalbert
Contributor

@11locsMC I am trying to deploy GlobalProtect 4.1.11 now and encountering difficulties. Can you provide which script you had used (there are a few different ones here).

I cannot get it to work if even if I run the script before the install, nothing is populating in the address.

Thank you,