Not using AppID but GP connections are denying on apps for 10 minutes before allowing traffic to work properly

[ksauer507]

We are currently working on trying to get PA-3220s working properly and Global protect working but are running into an issue.

Once a user connects, recently its starting to deny based on app ID, however in our VPN policy we have any specified.  The thing is this is pretty random.  In 5 to 10 minutes the VPN starts working normally and those denies turn to allows and are identified as the proper VPN access policy.  You could go a day or a few hours and then it goes back into this vicious cycle where its detects apps and fails back to our last policy which is a default deny.

This would be easier to diagnose if the problem was consistent.  But it seems the firewall flip flops and denies specific apps and then it resolves itself all on its own.  Anyone see this?

We are on 10.0.8-h8 and Global Protect version 5.2.10.When vpn is not workingrule for the VPN allows for ANY app id for this userWhen vpn is working fine

[ksauer507]

One of the things I've noticed is sometimes the fw will see the user as domain.com\username and sometimes as domain\username.  I found this thread and made changes so user and Group Attributes Primary Usernname is sAMAccountName and Alternate Username 1 is userPrincipalName, but it still randomly flip flops detecting the user.

so we ignored app-id based on the user name with a temp rule and deleted our others, now things work.  Why doesn't the palo see what AzureAD is passing and normalize it with what we have in on prem AD?

[ksauer507]

By creating a claims transform in AzureAD to user.onpremisesamaccountname that seems to make 95% of user-id detected as domain\username now.  That’s also indicated in GP client settings in windows and Mac.

BUT we’re not out of the woods yet.  When you first connect on windows there’s two user-id entries in the monitor tab from source: vpn-client and GlobalProtect.  So initially there are hits to AD from domain.com\username which falls under a different access policy.  Once they hit any of our 4 AD servers, they update user-id with domain\username which now they can hit the appropriate policy.

On a Mac client that is not intergrated with AD, user-id always sees them as domain.com\username so then they will never fall into appropriate user groups.  So since macs not touching AD we still think there’s more to the MS Azure AD SAML configuration, or maybe some how to override GP client from throwing in that stupid .com in the domain. 

[ksauer507]

Ok in Azure claims we went back to user.userprincipalname, and in the Group Mapping > User and Group Attributes Primary Username is also matching as userPrincipalName.

Even though this was a direct match, PAN support basically threw us out saying this was an Azure AD issue.  In fact after 4 days of rigorous round-the-clock testing and troubleshooting, even on PTO time... we think we solved it.

In User Identification, there's a certificate profile attached.  We went to that certificate profile and the third field down is User Domain.  It was set to our domain in this format: domain.com.  We basically threw a hail mary here and changed it to just domain..  After reconnecting we finally saw non-domain machines such as iPhone and mac test equipment finally match the user ID in username@domain.com format and hit on the actual policy we have tied to that AD group the user lives in.  We also see successful consistent user-id matching on domain-joined Windows machines as well.

Seems we are ok now, but we are still watching it!

[ksauer507]

Not fixed.  It was working beautifully for a few hours.  Everything was matching, then at one point the firewall out of nowhere started detecting users as domain.com\username , and because of that .com, not matching on any AD groups, therefore falling into our temporary all access safety net policy (which we really need to get rid of!).

What would cause the firewall go out of nowhere throw that additional .com back in the username?  Seems like you make a small change and commit the firewall, it will resolve it for a bit, but eventually break again all by itself.

I seem to be talking to myself here.  Is this forum visited often?  Or is it pretty much silence like Palo Alto support?