This might be something silly I am overlooking, but of the 3 computers I have Global Protect installed none of them can close Global Proect when done with it. Even going in and trying to end the process just makes it open a new instance. Has anyone else found this to be the case?
I agree, the password saving is crazy too. Even if you get it to not save it will automatically try and run with your current windows credentials. What's wrong with open, enter credentials, and close. Like really close, not reboot computer to close.
In the Global Protect portal Client configuration you can either
1. Enable the On demand option. However, with this setting enabled the GlobalProtect agent will not automatically connect to the gateway. instead the user will have to manually connect to the gateway by clicking the agent icon. But it does give you the disconnect option.
(Network tab > GlobalProtect> Portals > Client Configuration tab > General tab)
2. Enable the Agent UI and set the agent user override to with comment. This allows the end user to disable the agent on the PC with comment. You may have configured it to disabled
(Network tab > GlobalProtect> Portals > Client Configuration tab > Advanced tab)
In the Agent UI you can disable user can save password
do you have single sign on enabled? if yes, then the agent will use your Windows credentials to authenticate to the GlobalProtect portal. This can be disabled as well
Here's the Quick Start Guide Global Protect for reference:
I have configured the Agent UI to not save password, when I opened the agent the remember me check box is unactive but password is still saved.
When I try to connect to the gateway it use the same username as the portal and the last saved password, even If i configured to not save password on the Agent UI !
I want PaloAlto to ask me every time I conenct to enter my username and password.
I agree with mcsdemo. At the moment, our users are having a bit of a headache using the Global Protect client. With the addition of using a 2nd-factor authenication technology (PhoneFactor), we are experiencing difficulties connecting to the VPN that we did not experience when using NetConnect, the previous client.
As mcsdemo stated, when the client is first installed, the first set of credentials used are saved into the client. It would be great if the client, by default, did NOT allow saving of the credentials and only allow saving when configured on the firewall. Even when the "user can save passwords" setting is disabled on the firewall, it is already too late, as the client saves the first set of credentials until it is time to change the password.
The biggest headache of the Global Protect client at the moment is the two connect process: the portal and the gateway. While this may be a feature of Global Protect from its inception, this was not part of NetConnect, which only required connection to the gateway. Because of the additional portal authentication, this makes using the 2nd-factor authenication very difficult.
For example, we use PhoneFactor as our 2nd-factor authentication technology (installs on our RADIUS server). During the NetConnect days, when users want to connect to the VPN, all they would need to do was log into the gateway (posed as a Web site) with their credentials, then await a call to authenticate the VPN connection. Unfortunately, with the Global Protect client requiring connection to a portal first, users will need to 2nd-factor authenticate this connection every single time they log into the OS (Windows XP/7). Of course, they can opt to not authenticate and that phase will fail. The Global Protect Client then goes into some kind of "la la" land, attempting to connect to the portal until something is done to allow it to connect. Even worse, when users want to connect to the VPN, they still have to authenticate to the portal first. With the Global Protect trying to connect over and over from the previous failed authentication, the user ends up having to re-enter their credentials to get the client to stop connecting (receiving a call to authenticate that connection), and then doing a manual connect again to connect to the gateway (receiving a call to authenticate once again). This results in multiple, unnecesary 2nd-factor authenications which cause confusion and uneasiness in users (as well as the IT dept. that supports them).
I wish that Palo Alto would not have integrated the NetConnect feature into the Global Protect without allowing some way to make the Global Protect client function just like the previous NetConnect client (i.e., the gateway-only connection requirement being the biggest issue, as well as manual start-up only). While it may work really well without 2nd-authentication factor technology in place (tested it without this requirement and the connection to VPN is smooth), it does not seem to play very well with some of these technologies, which is a requirement in many company environments. I do like the 4.1.x update, but at the moment, things are not looking good for the Global Protect client. Worst comes to worst, we may end up having to revert back to 4.0.x to regain our beloved NetConnect client again.
The previous post is exactly the same situation I am now in. Users now get a PhoneFactor call when the GP client starts and when they connect to the VPN gateway. Everyone at my company HATES the GP client, myself included. It is awful compared to netconnect. PA just took a major step backwards here.
I've spent all day trying to workaround this, and I finally gave up, configured an IPSec group and installed the CISCO VPN client It connects to the PA gateway just fine. Screw GlobalProtect right in the ear. We're rolling out the Cisco client.. Why on earth would PA eliminate a client that worked great with no headache, and replace it with a total piece of crap? It's shockingly stupid.
Just an update on my post from a while ago. It's unfortunate (but expected) that others are having the same issue.
Since we did not have another VPN client to work with, my "fix" was to revert back to the previous 4.0.x firmware I was on and then sticking with that since (currently upgraded to 4.0.8). The revert process was not hard at all (thanks the PAN support on some easy commands), but I did have to come in on a Saturday morning to do the revert to minimize network downtime.
I solemnly agree that the NetConnect VPN client should NOT have been touched at all (esp. since it worked perfectly in the first place). Users have been happy since we reverted back to NetConnect. I suggest that NetConnect be separated from GlobalProtect once again. GlobalProtect may have its place somewhere, but I believe that, for the majority of us, NetConnect is simple to use and more reliable as a VPN client, esp. those that use 2nd factor authentication technology.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!