How to troubleshoot 'Matching client config not found'
21371
Created On 09/14/23 03:39 AM - Last Modified 10/11/24 06:54 AM
Objective
- When configuring GlobalProtect, an administrator has the option to set the 'Config Selection Criteria ' for User/User Group.
- By default, this setting is configured to 'Any', which allows any user or group to connect.
- However, when an administrator narrows down this criteria by specifying a particular User or User Group, it's imperative that the username with which the GlobalProtect Client authenticates to the Portal and/or Gateway matches precisely with the User/User Group information extracted from the LDAP servers.
- One significant challenge administrators face in this configuration is the variance in the User/User Group format retrieved from the LDAP servers. Since LDAP can represent users and groups in a multitude of formats, the possible combinations can seem endless. This diversity can lead to mismatches between the expected username or group name and the information on the LDAP servers.
- Furthermore, another potential issue arises if the exact User/User Group specified in the GlobalProtect configuration doesn't possess a corresponding username in the system. This discrepancy can result in connection failure and restrict access to users who should otherwise have permissions.
- In this piece, by referencing various articles, we aim to pinpoint and navigate these challenges, offering guidance for resolution.
Environment
- GlobalProtect Client
- GlobalProtect Portal
- GlobalProtect Gateway
- LDAP server
- SAML
Procedure
- Configuration
- Use GlobalProtect connection is Failing with Error "Matching client config not found" to further expand on the goal of this article.
- To identify discrepancies between the username format used by the GlobalProtect Client and that retrieved from the LDAP server, refer to GlobalProtect is not getting the configuration when user authenticates to the portal successfully.
- If one system uses the "domain\username" or "domain\user" format, while the other employs "user@domain.com" or "user@domain", consult the guide How to retrieve group mapping based on SAM or UPN format to address the discrepancy.
- Verify if the Identity Provider (IdP) in SAML is sending only the username attribute without the domain information. If so, implement one of the following actions:
- Configure the IdP to send the domain information.
- Authenticate users without domain information using this procedure, provided that the usernames are not duplicated across domains to avoid misidentification:
- Remove any override domain name by navigating to:
Device > User Identification > Group Mapping Settings > [LDAP-GroupMapping] > Server Profile > Domain Setting > User Domain: Clear any values. - Enable matching of usernames without domain information by navigating to:
Device > User Identification > User Mapping > Palo Alto Networks User-ID > Agent Setup > Cache > Allow matching usernames without domains: Check.
- Remove any override domain name by navigating to:
- If the User/User Group from the LDAP isn't properly pulled by the firewall use Newly Added Active Directory Users do not Appear on the Firewall.
- If all of the above seems to be in place and error still exist, try deleting GlobalProtect's cached credentials using Under which conditions can users see the Sign Out option within the GlobalProtect app.
Additional Information
07/11/24 - Content has been created by an SME in a Resolution Path format
DDE has granted permission for this format type for: AIOps
If any changes are needed please contact a KDE or message in the #Knowledgebase Slack Channel, or email gcs-knowledge@paloaltonetworks.com