Errors: globalprotectgateway-config-fail, description contains 'GlobalProtect gateway client configuration failed. User name: , Client OS version: Microsoft Windows 10 Enterprise , 64-bit, error: Matching client config not found.
Once I removed the group from Gateway\Agent\Client Settings\User group, and selected any, users could login, no error.
But as soon as I add the group back (which is required by our company security), get the error again and users can't login.
This is a site location in Sydney, our main DC and Agent servers are in Oregon. But they do have a local AD server, and I do have that in the LDAP config.
Have anyone else had this problem?
I'm using SamAccountName, and nothing else changed, besides that some of the attributes are in a slightly different location to configure. The configuration still looks correct, and I can browse and see the group and users.
I've noticed that user who logs on from Sydney doesn't show the groups when running: show user ip-user-mapping ip x.x.x.x
IP address: x.x.x.x (vsys1)
User: domain name\user name
Idle Timeout: 1038s
Max. TTL: 1038s
Group(s): domain name\User name(3519)
But the user that's logon from Oregon does: show user ip-user-mapping ip x.x.x.x
IP address: x.x.x.x (vsys1)
Idle Timeout: 10782s
Max. TTL: 10782s
and all the other groups are listed where the user is member of...
In both those clients, is the domain the same? You've listed them slightly differently ("domain name" versus "domainame") and I'm not sure if that's just a typo or an indication that it's a separate domain. If it is two separate domains, you'll need a separate LDAP server profile for each domain controller.
Also, ensure that both are referenced under Device > User Identification > Group Mapping Settings tab. You'll want to ensure that both DCs are pulling the correct groups into the Group Include List section of that group mapping.
This issue has been resloved, thank you for the comments.
The problem was the domain name. The users that worked, was domain\username --> without the suffix.
The users that didn't work, had the full domain name, domain.local\username --> with the suffix.
The solution was in the Authentication Profile to change the User Domain without the suffix.
Thanks for sharing. We had this exact problem. We are using AD groups to assign the GP Client config. Since the domain was set incorrectly in the Authentication profile (was: domain.local, fixed: domain), the UserID couldn't map the groups to that user account, so it couldn't match a GP Client config.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!