Help with configuration profile for GlobalProtect

jhuls
Contributor III

I'm attempting to create a configuration profile for GlobalProtect so that users don't have to enter the vpn server address. When testing the following which was added to a configuration profile in Jamf, it still prompts. Any ideas?

And, yes, I have our real address in the one I'm using.

<?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>vpn.server.edu</string>
                <key>Prelogon</key>
                <string>0</string>
            </dict>
        </dict>
    </dict>
</dict>
</plist>
71 REPLIES 71

mmunoz
New Contributor

Hi everyone, so been trying to set this up for a few days and can't figure it out. the documentation from PA is not really clear, so far I have tried everything that was suggested here but no luck. And when I made changes to the Plist the address only gets added after a reboot. am I missing something?

Saikat
New Contributor III

@mmunoz I tried the above process and it worked well all OS. We kept 10.10 only excluded. Please let me know if this works for you.

Saikat
New Contributor III

2e0646ec7fe74e60b4fee52ff4d775a3

sdagley
Esteemed Contributor II

Anybody else seeing GlobalProtect 5.2.5-84 triggering a "You are making changes to System Certificate Trust Settings" authorization prompt at the first connection attempt after initial install (so @franton's removal of the GPService keychain isn't applicable) on Big Sur systems?

TechM
New Contributor III

@sdagley so it sounds like you are talking about something I encountered in 5.1.7 (see screenshot). We opened a case wit PA and they came back with Apple's macOS Big Sur 11.0.1 Release Notes (not realizing the intended audience is the vendor not the end user). It states:

Security

New Features

         macOS Big Sur 11 beta improves system security by requiring an administrator password when a certificate trust settings change is made in the admin trust domain. Running as the root user alone is no longer sufficient to modify certificate trust. User trust domain settings continue to require confirmation by entering the password for the user’s account. This change may affect you if one of the following is true:

o    You have written scripts which call /usr/bin/security add-trusted-cert -d ... as root.

o    Your process runs as root and calls the SecTrustSettingsSetTrustSettings function to trust a certificate.

         Workflows that add trust settings in the admin trust domain, such as for an enterprise root certificate, may require modification if the user can’t authenticate as an administrator at the time settings are changed. (21855995)

Workaround: Use Apple Configurator 2 to create and install a configuration profile containing your root certificate.

 

Our ask of PA:

 

Proposed Solution: For PA to use Apple’s suggested workaround. One of the following solutions should suffice:

  1. Provide a signed configuration profile containing 1 payload: the required root certificate
  2. Provide the required root certificate to be used in our own signed configuration profile

 

Then they came back and said they don't provide those solutions or file types. And I then replied with their own KB where they do in-fact offer config profiles and instructions on how to create them. and then reiterated...


Palo Alto is performing an action where scripted actions that are no longer supported by Apple due to increased security. The provided workaround for the vendor is clearly stated and should be provided to their customers by one of the two methods discussed already.

 

Screen Shot 2021-08-27 at 10.29.27 AM.png

 

Interestingly in our 5.2.8 testing, we have not seen this prompt for the system level cert. So maybe they fixed this?

sdagley
Esteemed Contributor II

@TechM I never followed up my post in this thread, but I solved the problem by extracting the PaloAltoCA certificate from a Mac that had already connected via GlobalProtect, and then added a Certificate payload with that certificate to the Configuration Profile we deploy to approve the GlobalProtect System Extension.

As for why you didn't see the cert prompt with 5.2.8, had those Macs previously connected with any other version of GP? I don't believe that cert changes between client versions, but will depend on GP host server.

tender
New Contributor III

Yes @sdagley I have the same issue. Did you figure it out?

thanks!

tend·er (tĕn′dər) noun: One who tends something.

sdagley
Esteemed Contributor II

@tender It appears that prompt is a requirement on Big Sur now based on the responses I received to my question.

tender
New Contributor III

@sdagley: It was something on the VPN backend setting. The root cert was configured to install and disabling that resolved the issue.

tend·er (tĕn′dər) noun: One who tends something.

tfish
New Contributor

@tender Do you know to go about disabling the installation of the Palo Alto root cert?  Thanks in advance!

sdagley
Esteemed Contributor II

@tfish Way would you want to disable the installation of the Palo Alto root cert? That's probably  necessary for GlobalProtect to establish a connection.

sdagley
Esteemed Contributor II

@tender Thanks for that info. I'll have to get with our GP team to find out if they're doing the same, and if that certificate is really required. Hopefully it can be deployed via a Configuration Profile if it is.

Jamie_Boyd
New Contributor

@Saikat I get an error when running that command.
Running command /usr/libexec/PlistBuddy -c "Add :Palo Alto Networks:GlobalProtect:PanSetup:Portal string myvpn" /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist ; /usr/bin/su - "/usr/bin/stat -f%Su /dev/console" -c "/usr/bin/pkill -l -U /usr/bin/stat -f%Su /dev/console GlobalProtect" ; /bin/sleep 3 ; /usr/local/bin/jamf recon...
Result of command:
su: unknown login: /usr/bin/stat -f%Su /dev/console

saikat_tripathi
New Contributor II

@Jamie.Boyd you made a mistake in the command. Please see the command line below.

/usr/libexec/PlistBuddy -c "Add :Palo Alto Networks:GlobalProtect:PanSetup:Portal string servername" /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist ; /usr/bin/su - "/usr/bin/stat -f%Su /dev/console" -c "/usr/bin/pkill -l -U /usr/bin/stat -f%Su /dev/console GlobalProtect" ; /bin/sleep 3 ; /usr/local/bin/jamf recon

Jamie_Boyd
New Contributor

Thanks @saikat.tripathi. I'm copying and pasting the command directly into Jamf, and changing the portal string to my vpn name. Can you tell me where the difference is? It looks exactly the same to me.

sdagley
Esteemed Contributor II

@saikat.tripathi @Jamie.Boyd The forum software tends to mangle code if one doesn't use the ` (backtick) escape character at the beginning and end of the code. Better yet is to put the script fragment in a separate block by using the ``` (triple-backtick) on a new line, followed by the script lines, and closed by another ``` on a new line. Or just type the code, select it, then use the icon above the Post Response field that looks like >_ to mark the selection as a code block.

You might also find creating a Script in Jamf Pro for this rather than stuffing it into a Files and Processes -> Execute Command makes life easier since you're not limited to a single line for the entire command.

kostas_athanas1
New Contributor

To suppress the keychain system popup for GP 5.2.x you need to export the PaloAltoCA from keychain, upload it in a configuration profile with cert payload, mark it as Allow apps to access and scope it to your device(s). This isnt documented anywhere but was the obvious change that prompted that popup

For its VPN and content filter settings I have been battling with the incompetent Palo Alto support to issue the settings required but this is what they said: "Upon checking found that the JAMF is not the supported MDM from the PaloAlto. The supported MDM are the AirWatch ,Microsoft Intune ,MobileIron ,Google Admin console"

So i asked them for the MobileIron and Airwatch settings.... not heard back yet. I will post here the settings if they ever supply them...

gregsheppard
New Contributor II

@gregsheppard It's a handy guide for sure, but I don't see anything about the certificate prompt we're all getting...

sdagley
Esteemed Contributor II

@TechSpecialist Are you referring to the prompt for System Certificate Trust settings? If so, extract the PaloAltoCA certificate from a Mac that had already connected via GlobalProtect, then add it a Certificate payload in the Configuration Profile you deploy to approve the GlobalProtect System Extension.

Just saying thanks! This worked for me!

bwoods
Valued Contributor

@sdagley is correct put just add that PA cert to a configuration profile. 

markopolo
Contributor

Hoping to resurrect an old thread here. 😏 I can't get GlobalProtect (v. 5.2.12) to recognize my config profile that is structured like this:

<?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>
				<array>
					<string>portal-1.mycompany.com</string>
					<string>portal-2.mycompany.com</string>
				</array>
			</dict>
		</dict>
	</dict>
</dict>
</plist>

Any idea what I might be doing wrong? The Managed Preference takes precedence over the ones in /Library/Preferences and ~/Library/Preferences, right?

sdagley
Esteemed Contributor II

@markopolo Trying to use a Configuration Profile to configure the portal settings for GlobalProtect is like micturating into the wind. Save yourself some frustration and use @franton 's technique posted below on ‎12-19-2020 06:26 PM for using defaults write to create the .plist into /Library/Preferences/

The one thing that became clear to me was that Palo Alto absolutely does not care to change/fix the Mac configurations. That being said, we could never get it to work if we entered more than one portal, so we picked one and wrote a page for our users on how to add the others (we have four).

Currently, we're using the config profile for the system extensions and using the plist method that @sdagley references - works perfectly for us (still only one portal, though).

pueo
Contributor II

@markopolo 
Not sure if my experience can help but here we go!

I do recall it taking some time to figure out all the settings. I also used the GP documentation to set everything up.
In total I used 5 profiles.  I like to keep mine separate incase a change has to be made.

  1. App & Custom Settings - Gateway
  2. Content Filter
  3. Notifications
  4. Sytem Extension
  5. Disk Access

I do recall our Networking team having issues with a user selecting which certificate required but they made a change an our users do not get prompt to choose a cert.

GP has been pretty stable for us.  A few quirks here and there but nothing large scale.
Here is our Gateway setting Profile.  All other settings are pushed down from GP Server once the user connects. 

<?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>PanPortalList</key>
	<array>
		<string>xxxx.xxcloudservice.com</string>
	</array>
       <key>Prelogon</key>
        <integer>0</integer>
	<key>User</key>
	<string>$USERNAME</string>
	<key>WebKitCacheModelPreferenceKey</key>
	<string>1</string>
	<key>WebKitWebGLEnabled</key>
	<string>:false</string>
	<key>user-credential-saved</key>
	<string>true</string>
</dict>
</plist>

 

tender
New Contributor III

I was using a JAMF profile to configure the portal address but changed to using defaults write because issues reported by users. When using the profile, the portal was configured but users were not able to add additional portal addresses. Changing to defaults write solved this for me.

defaults write /Library/Preferences/com.paloaltonetworks.GlobalProtect.client PanPortalList -array-add portal.address.com;

tend·er (tĕn′dər) noun: One who tends something.

franton
Valued Contributor III

Been a while since I last responded to this. Some notes:

1) Palo Alto changes the format of it's configuration files between releases. 5.1.x has a different format to 5.2.x which is different to 6.x

2) As a result, I start with the installer and a completely blank uncontrolled mac to capture what it's setting and it's formatting. That method has proved effective in helping generate config profiles for the URL settings.

3) Palo Alto provides some pre-built and signed .mobileconfig files for things like split tunnel DNS. Badger the heck out of your network team for Palo Alto documentation access. I've done a lot of this work blind and I really could have used that information.

4) That covers the URL side of things. Palo Alto still has this annoying habit of some of it's preferences won't read out from profiles but will read from the plist file directly hence the defaults write approach. That's a rabbit hole in advanced syntax I don't want to go near again.

Still all easier than a lot of other VPN clients. ;)

 

Much appreciated! 

Ours worked for 5.x.x but now that we are on 6.x.x - our configuration profile adds the URL but it doesnt launch the pop-up window to sign-in. 

If we try it without the configuration profile, 6.x.x works (pop-up window appears) and we would need to enter manually.

 

Do you happen to have Configuration Profile for 6.x.x?

 

Extra info:
If we use old GP 5.x.x with configuration profile, the prompt pop-up works but we would need manually update it.

jsnyder
New Contributor II

I'm starting to test GlobalProtect 6.1.0 because I've been struggling with getting the portal address populated without a reboot. The 6.1.0 documentation references this url for configuration in Jamf Pro:

Deploy the GlobalProtect Mobile App Using Jamf Pro (paloaltonetworks.com)

I'll be testing this out this week.

jsnyder
New Contributor II

This worked really well in my testing. It was clean and didn't require the user to interact with anything other than entering their username and password.

Policy for Package, Script, Inventory:

https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/mobile-endpoint-management/...

Configuration Profile for System Extension and PPPC:

Enable System and Network Extensions on macOS endpoints Using Jamf Pro (paloaltonetworks.com)

Configuration Profile for Notifications:

No link but just used a bundle id of "com.paloaltonetworks.GlobalProtect.client"

 

In case you missed it, this was with the 6.1.0 package.

Steven_Xu
Contributor

on version 6.1.0, deploy the application custom profile with preferences domain com.paloaltonetworks.GlobalProtect.client works.

<?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>PanPortalList</key>
	<array>
		<string>vip1.gptest.com</string>
		<string>vip2.gptest.com</string>
	</array>
</dict>
</plist>