Duo SSO and Palo Alto GlobalProtect not working with domain groups

[firewallfrank]

I have Duo SSO working with Palo Alto GlobalProtect but I am unable to utilize domain groups. If I apply a domain group in my GP gateway I am unable to connect and I receive an error stating ‘matching client config not found’.

[ButlerKD]

FCalderone,

That sounds like you need to configure under “Firewall - Network Tab - GlobalProtect - Portals - GlobalProtect Portal Configuration - Agent” a specific client config that is tied to your LDAP security group for your domain users who are to have access to the GlobalProtect VPN connection, and are also defined in the Duo Admin panel under the specific policy(ies) associated with GlobalProtect.

Hope this helps.

• Kevin

[Amy2]

Thanks for giving such a concise, clear answer here, Kevin!

FCalderone, I also found a help article in the Palo Alto knowledge base that confirms the steps Kevin has shared here if you need more context or guidance: Connection to GlobalProtect is Failing with Error "Matching client config not found"

[firewallfrank]

The solution did not work. Duo does not recognize the domain group or pass it on after authentication. I have this working fine on GlobalProtect using just LDAP as authentication and restricting the logon to a specific domain group and then I write rules to that specific domain group. But when I switch the authentication method to Duo on the Portal and Gateway I am unable to even login.

[c.leighland]

Hello, Did you ever find a solution to this? I’m running into the exact same problem. There seems to be a disconnect between the Group mapping - domain\username, and the username that’s passed from LDAP. I’ve been fighting with this for ever. If anyone found a solution to this, please post. I’m at my wits end…

[firewallfrank]

I could not find a solution for it to work with Duo SSO. I worked with Duo Support and they confirmed it. I ended up using the Palo SSL VPN application in Duo that works with Groups.

[c.leighland]

@fcalderone I’m still working on this, and I’ve ended up deep in the weeds, I’ve even tried editing the XML file to include WindowsDomainQualified name in the NameIDFormat tag of the file. This attribute is exactly what we’re looking for: domain\username.

The big issue right now, is how to see the username format being passed from Duo to the SAML integration on the Palo. Knowing this might really help the cause. My issue is with Duo’s logging - it’s definitely sub-par for validating this sort of information

I’m not sure if you’re still interested in getting this resolved, but I’ll post a solution if I ever come across one. We’re using the standard SSL VPN application currently, and there are just too many limitations, especially around authentication sequences with MFA/Non-MFA authentications…

Anyways, thanks for getting back to me - I know it’s been a while.

[c.leighland]

@fcalderone,

Not sure if you’re still interested in a solution, but there is one that I’ve applied and is confirmed working with the LDAP Groups. Frighteningly enough, the solution is quite simple:

1. In Username Attributes of the application (Palo Alto GlobalProtect - Single Sign-On), enable “Custom Attributes” and change the Username Attribute from to msDS-PrincipalName.
   

   

2. Make sure “Username normalization” is set to simple.
   

   

3. On the Palo: Device > Authentication Profile: Username Attribute should still be User.Username (Case sensitive - both "U"s NEED to be upper-case, or the login will default to user@domain.com:
   

   

That’s really it - Worked like a charm.

The only real major change was the Username attribute change to msDS-PrincipalName.

Cheers,