We’ve been using Palo Alto’s GlobalProtect with Azure SAML successfully for the past 4 years. We have a single portal with multiple gateways deployed globally. We recently started upgrading our Palo Alto firewalls from 9.1.x to address the certificate issues and discovered that GlobalProtect broke when we hit 10.2.x. We were getting the infamous “Failed to get client configuration” error. The firewall was unable to determine the username to use for the LDAP query to get the group membership.

Ultimately we had to go back to our Azure SAML configuration and modify the username attribute such that the SAML response would return “domain\username” format.

Cheers!

Update: March 2, 2024

It’s turn’s out that prior to 10.2 the user domain was being learned from a certificate on the client. We issue certificates to all our devices as a second factor, third factor really when you think about MFA. I don’t believe Palo Alto has any intention on “fixing” the issue, hence you need to update your SAML attributes to return “domain/username” in the username attribute.

It turns out that in the year 2022 upgrading from PAN-OS 8.0.x requires a TAC case and an older content update file that’s not readily available on Palo Alto’s Support website.. Hopefully this will save someone else the down the road.

I recently needed to press an older PA-220 that had been in laying around in a lab into a production environment due to the supply chain debacle that we’re all currently living in. I reached out to my reseller and had the firewall fully licensed and was able to apply those licenses to the hardware. In preparation of the deployment I tried to bring the PA-220 up to PAN-OS 9.1.14. And was unable to upgrade past 8.0.20 even with the device being fully licensed.

When I tried to upgrade from 8.0.20 to 8.1.23 I would get an error during the software install, “Failed to install 8.1.23 with the following errors. SW version is 8.1.23 Error: Upgrading from 8.0.20 to 8.1.23 requires a content version of 769 of greater and found 655-3816. Failed to install version 8.1.23 type panos“

Even though the device was fully licensed there were no Dynamic Updates available to download or install. I even tried to manually download them from the Palo Alto support website and install them and that was met with a different error when trying to commit the change.

I opened a case with Palo Alto Support and eventually they provided me content update 8424-6791 which I was able to manually install and apply, after which I was successfully able to upgrade to 8.1.23. I was then able to download and apply the latest and greatest greatest content updates from the webUI and eventually upgrade the firewall to 9.1.14.

Cheers!

When possible it’s always a good idea to test any software upgrades, because you just never know what your going to get. That was the case recently when I upgraded our test PA-220 from 9.1.7 to 9.1.12-h3 and seemingly breaks all GlobalProtect VPN functionality. The portal doesn’t respond on TCP/443 at all, so it looks like the firewall itself is dropping the traffic.

The issue turned out to be Strict IP Address Check which was just “resolved” or enabled in 9.1.12.

AN-175934 Fixed an issue where packed-based zone protectio settings (such as
Strict IP Address Check) were not applied to return traffic.

When I disabled Strict IP Address Check on the zp_untrusted zone protection profile GlobalProtect started working again.

What is Strict IP Address Check?
Check that both of the following conditions are true:

• The source IP address is not the subnet broadcast IP address of the ingress interface.
• The source IP address is routable over the exact ingress interface.

If either condition is not true, discard the packet.

Looks like a bug to me.

Cheers!

Here’s a quick note for anyone looking to understand how they can allow either the standard samAccountName (username) or the userPrincipalName (usually the email address) to be used by users when logging into the GlobalProtect VPN client when authenticating against Windows Active Directory via LDAP.

I will assume that you already have basic username authentication working. So this post will outline how you can add the ability for users to use the userPrincipalName as opposed to their samAccountName (username).

Step 1. Assuming you already have an Authentication Profile setup to authenticate usernames (samAccoutName) you’ll need to clone that profile and then update the Login Attribute to “userPrincipalName”.

Step 2. Create an Authentication Sequence that includes both your Authentication Profiles, the original profile along with the profile you created in the step above. In the example below I’m using “auth_ldap”.

Step 3. Update your GlobalProtect Portal Configuration Client Authentication to reference this new Authentication Sequence. Network -> GlobalProtect -> Portals, edit your configuration and update the authentication profile to “auth_ldap”.

Step 4. Update your GlobalProtect Gateway Configuration Client Authentication to reference this new Authentication Sequence. Network -> GlobalProtect -> Gateways, edit your configuration and update authentication profile to “auth_ldap”.

Step 5. Commit your changes.

With that all done you can now test, using either your samAccountName (username) or your userPrincipalName (usually the email address of the user).

Cheers!