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