Posted on 04-02-2014 11:13 AM
My searches have turned up nothing. Just looking for gotchas, do's and don'ts, etc.
Posted on 04-02-2014 11:16 AM
We have, initial deploys are fine but pushing out updates to GP is more tedious.
Posted on 04-02-2014 11:48 AM
@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.
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?
Posted on 04-02-2014 12:35 PM
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.
Posted on 04-02-2014 12:40 PM
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?
Posted on 04-02-2014 12:43 PM
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.
Posted on 04-02-2014 12:44 PM
Thanks. All I know is that it's on my upcoming projects. Is there any technical documentation you can link us to?
Posted on 04-02-2014 01:20 PM
Posted on 04-22-2014 04:32 PM
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.
Posted on 04-24-2014 11:06 AM
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>
Posted on 07-11-2014 12:22 PM
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.
Posted on 07-31-2014 10:25 PM
In response to myself, a reboot of the machine works.
Posted on 08-30-2015 10:00 PM
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?
Posted on 08-31-2015 12:30 PM
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.
Posted on 08-31-2015 03:01 PM
Thanks for the response, what version are you deploying? We're running 2.3.1-7 which appears to be the current version.
Posted on 09-01-2015 07:16 AM
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.
Posted on 09-01-2015 10:03 AM
Posted on 09-01-2015 01:40 PM
@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?
Posted on 09-02-2015 06:36 AM
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.
Posted on 09-02-2015 04:15 PM
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.
Posted on 09-03-2015 01:40 PM
Posted on 08-22-2017 11:19 AM
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.
Posted on 08-22-2017 03:01 PM
OK, so ignore my post. Looks like even their instructions do not work. :-(
Posted on 08-22-2017 03:38 PM
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.
Posted on 08-22-2017 03:56 PM
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.
Posted on 08-23-2017 06:45 AM
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:
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
Posted on 08-23-2017 07:40 AM
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.
Posted on 10-11-2017 06:24 AM
@typeraj I would like to find out how you guys were able to bypass the keychain access prompt. Can you provide more information?
Posted on 10-11-2017 01:55 PM
@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.
Posted on 10-24-2017 09:14 AM
@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.
Posted on 10-29-2017 05:39 PM
@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.
Posted on 03-20-2018 02:37 PM
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.
Posted on 03-21-2018 08:34 AM
@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.
Posted on 03-23-2018 11:08 AM
@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?
Posted on 03-29-2018 04:26 PM
@typeraj @alexyu650 : if you guys want to deploy client certificates and avoid the prompt for credentials, do the following:
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.
Posted on 06-01-2018 12:04 PM
Wouldn’t this "allow all apps" setting enable a rogue GP app to access the cert?
Posted on 06-01-2018 12:05 PM
edited previous post
Posted on 08-31-2018 02:34 AM
Posted on 02-11-2019 11:58 AM
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.
Posted on 04-17-2019 02:13 PM
@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.