topic GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2 in General Topics

GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Wed, 15 Aug 2018 17:26:53 GMT

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?

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

BPry — Wed, 15 Aug 2018 19:24:22 GMT

@Margit_Curtis,

Did you make note of the User-ID Changes that were included as part of the PAN-OS 8.1 upgrade? I would verify that the user-id that globalprotect is recieving is actually in the correct format and is as expected by your configuration.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Wed, 15 Aug 2018 21:25:51 GMT

Thanks you BPry, I'll check it out.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Wed, 15 Aug 2018 21:42:04 GMT

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.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Thu, 16 Aug 2018 17:27:31 GMT

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
From: GP
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)
User: domainame\vpntest
From: GP
Idle Timeout: 10782s
Max. TTL: 10782s
Group(s): domainame\vpntest(3599)
cn=vpn-fulltunnel,ou=ouname,dc=domainname,dc=test(2147483989)
and all the other groups are listed where the user is member of...

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

gwesson — Thu, 16 Aug 2018 18:13:37 GMT

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.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Thu, 16 Aug 2018 18:23:05 GMT

They are on the same domain, just a hurried typing on my part.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

Margit_Curtis — Wed, 22 Aug 2018 23:40:39 GMT

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.

Re: GlobalProtect client stopped working after upgrade from 8.0.7 to 8.1.2

svintinner — Fri, 14 Dec 2018 20:04:00 GMT

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.