GlobalProtect ask for password after update from 6.2.3 to 6.2.4

[SupportSPOC]

Hello,

We are using PA-3020 with software version 9.1.19, the VPN accounts are local to the PA.

Currently we are on GlobalProtect 6.2.3 and we would like to update to 6.2.4 to protect against CVE-2024-5915. When the update is done, GloabalProtect ask for the password (the username is still filled with the correct information). The users are most of the time (95%) not aware of this password, so i can't imagine having hundred calls to obtain the password. 

Is this behivior normal ? When we updated last june from 6.1.2 to 6.2.3, everything was smooth and no credentials were asked.

Thank you very much for your answers.

Regards,

Julien 

[MP18]

@SupportSPOC Is PAN OS version 9.1 is still supported?

When user connects then the VPN Username and password is Local on the PA?

Which connection method you use to connect to the GP?

Regards

[SupportSPOC]

@MP18 PAN OS 9.1 end of support is 30 june 2024 😞

Correct, both VPN username and password are local on the PA

We are using On-Demand connection method.

I tried to update from 6.2.3 to 6.2.3-c287 (hotfix version) but same behavior. After the update, GlobalProtect is asking for the password but the username is still present.

Thank you for your help !

[MP18]

@SupportSPOC what happens when you the put the password?

Regards

[SupportSPOC]

@MP18 The connection is established without problem.

[aleksandar.astardzhiev]

Hi @SupportSPOC ,

As part of GlobalProtect Gateway config,  there option to tell the client to cache the username and the password (or only username or disable credetials caching).

As mentioned here - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm6MCAS cached credentials are saved in the Windows Credential Manager.

I am only guessing that after update of the GP client, the cached credetials are no longer considered valid. For that reason user needs to enter the password again. If you haven't change the settings on the firewall, it should cache the credentials again and remember them for subsequent logins.

Unfortunately users will need to enter the password at least once after update

[SupportSPOC]

Hi @aleksandar.astardzhiev 

As you mentionned, i didn't changed the settings on the firewall, so it should cache the credentials. Indeed this is what is happening when i upgrade from GP 6.1.2 to 6.2.3, everything is smooth and transparent for the users.
But when i update from 6.2.3 to 6.2.4, then the users have to enter the password again to connect. I tried on 10 differents computers and VPN accounts : same behavior each time.

@MP18  and @aleksandar.astardzhiev  If you don't have others ideas about this problem, i will open an official case and hope to have support or workaround.

[MP18]

@SupportSPOC Might be something with new GP client then. Please open up case and keep us posted here

Regards

[SupportSPOC · Accepted solution]

@MP18 @aleksandar.astardzhiev 
Hey guys,

So I opened a case with my support (lvl 1) who themselves opened a case with their support (lvl 2). The problem was able to be reproduced by lvl 2 support and indeed the client upgrade to version 6.2.4 asks again for the GlobalProtect password for the user.
We asked for confirmation from Palo Alto regarding this change in behavior, but lvl 2 support argued that it was apparently like that in the new version, that doing local authentication was not not good and does not respect best practices, that it was necessary to go through SSO and that they could not open a ticket with Palo Alto to reimplement this functionality (something that we did not ask for, we just wanted a confirmation).
Yesterday GlobalProtect 6.2.5-c788 was released and it is indicated in the (long) changelog the correction of bug GPC-20626: "Fixed an issue where the GlobalProtect client overwrites valid authentication override cookie with empty authentication override cookie from portal when using cached portal configuration." (which seems close to our problem)
So we tested this version which effectively corrects the problem, the update is again transparent for users. We will therefore be able to correct the security problems linked to CVE-2024-5915 and CVE-2024-9473 then study the possibility of switching to SSO in a second step.
Hope this helps other people with the same problem. Thank you all!