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.

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!