TAC guy shrugged.Īlso, if using SSO on Windows clients, we rolled out the GlobalProtect registry setting “SetGPCPDefault”=1 to force use of the GP credential provider and it helped password change issues massively, though it alone didn’t fix that caching issue.Įdit: just to mention, we started seeing the issue with 5.0.x and PanOS 8.1, upgrading to 5.1.x and 9.0 didn’t help. I also followed up with TAC and they told me this was expected behavior with SUC=“yes”… why on earth would such an awful and confusing behavior be expected. A few weeks ago I stumbled upon some Reddit or StackOverflow page that mentioned to set Save User Credentials to “no”, since “yes” does enable a hidden credential cache, and voila, problem solved! We haven’t seen any adverse issues either. Many lockouts, tickets, and angry support folks dinging my phone, a few every day.
Globalprotect password install#
We were assured by TAC long ago during our GlobalProtect install that the Portal > Agent config > Authentication setting called “Save User Credentials” did nothing with our authentication setup, so to be safe and also to follow all the GP setup guides, we set it to “yes”.īut now it’s over a year later and we’d been battling your same issue all along, where even with SSO enabled GP would seemingly cache users’ old credentials after a password change, and even through reboots. Oh man, we just went through this! Not sure if you have the same setup, but we use pre-logon/always on with machine certificates, LDAP authentication, and SSO enabled (for Windows clients). Usually that period of time is between that connection and their next one (next day most likely so within 12 hours).Īnyone seen an issue like this with GlobalProtect, Palo Alto Firewall (we are at 9.1.8), and Active Directory 2016 (we use the User-ID Agent 9.1.209 on both domain controllers)?ĭoes GlobalProtect/Palo Alto Firewall cache AD credentials for a period of time? If so, is that timing adjustable or even something we can disable? Is there a downside to using real-time querying of creds from AD (if that is possible)?Īny other recommendations for dealing with this behavior? It has become very disruptive as it usually results in multiple locks per user (once when they try to use the new password, and the next day when the old saved password finally fails). Allow GlobalProtect to send you notifications. If you have not enabled GlobalProtect notifications on your endpoint, a notification permission dialog appears. When this happens, the user can try their old password and it will work for a period of time. Launch the GlobalProtect application, and select either Allow or Don’t Allow. At that point we are seeing some users not being able to use the new password they just chose, and tested in Windows (which is querying the domain controllers in real-time so we know the change took). After that, we have them disconnect and sign out of GlobalProtect and then immediately connect GP again and sign in again.
Globalprotect password update#
When a user changes their password in AD, we have the user immediately lock and unlock Windows, to be sure the change took, and to force Windows to update the cached creds. We use Active Directory to authenticate GlobalProtect connections.
0 kommentar(er)
