This may have partially been related to the timeout, but I don’t think that’s the whole issue. Are users are randomly being detected as domain\username , which matches AD groups and users in policies, but then sometimes they are being detected as domain.com\username which does not match any policy so it’s denied. Then I think it couldn’t send a HIP report (traffic denied) and caused that issue. But amongst many other issues too. We created a SAML transform in AzureAD and now the GP client shows domain\user instead of user@domain.com, and 95% of the user UD detections are correct on windows machines, but the first login user-ID gets domain.com\user from source vpn-client. On a Mac it always detects as domain.com\user since they are not talking to DCs. Weird because in the GP client the .com isn’t there in the settings UI in either GP 5.2.10 or the new GP 6.0. For now we have a failsafe “all” users from vpn zone under our specific user based vpn zone. This way macs can get on and windows users can auth to AD and DNS until they get a legitimate user. Downside is until then, or if your using a machine not on our domain like a Mac, iPhone or vendor… we can’t control what they have access too. I posted about it here: https://live.paloaltonetworks.com/t5/globalprotect-discussions/not-using-appid-but-gp-connections-are-denying-on-apps-for-10/td-p/468820 Would love to “normalize” everything from the Global Protect Enterprise Application in Azure to the GP portal as domain\user, as this would actually match AD users and groups and then fall into the correct policies. Also across operating systems (windows, mac, iOS, etc).
... View more