Anyone deployed Palo Alto GlobalProtect?

[stevehahn]

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

[philwillchen]

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

[bentoms]

@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]

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]

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]

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]

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

[philwillchen]

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

[patrickhlee]

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]

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]

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]

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

[paulnz]

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]

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]

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

[adhuston]

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]

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

[paulnz]

@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?

[adhuston]

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]

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:

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]

@adhuston Thanks for the feedback

@jreinstedler Awesome, I will give that a try.

[jason_bracy]

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]

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

[typeraj]

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]

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]

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]

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]

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

[typeraj]

@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]

@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]

@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]

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]

@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]

@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]

@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]

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

[chris_hansen]

edited previous post

[simon_brown]

deleted

[11locsMC]

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]

@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,