11-14-2011 10:38 AM
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?
11-14-2011 11:32 AM
We have the same problem.
Also Global Protect stores the login and Password information on the computer that i do not find a secure idea.
11-14-2011 02:02 PM
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.
11-14-2011 11:39 PM
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:
11-29-2011 02:45 AM
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.
11-29-2011 08:03 AM
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.
01-16-2012 08:30 AM
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.
01-16-2012 01:52 PM
Please resolve this issue PA, none of your competitors would have made the same mistake. Sort out 2 factor authentication in GP please.
01-16-2012 02:53 PM
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.
01-17-2012 06:55 AM
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.
01-31-2012 12:47 PM
Just want to report that we're having the same issues with PhoneFactor and GlobalProtect, not closing, saving the password, reconnecting at bootup even though the icon near the clock flashes "on demand." Users can connect *sometimes*. It keeps showing as failed to connect and popping back up for them to hit the apply button, but each time they do, it counts as a logon attempt. Too many of those, and their VPN account AND their Active Directory account get locked.
I had our idle timeout set to two hours. Had a user that was actively using the VPN, but kept getting kicked off after two hours. I had to bump up the idle timeout.
I've got a cubicle full of laptops returned to me because users can't connect. I opened a ticket and have spoken with two technicians so far. I got a suggestion to uninstall the GP client and delete the PAN file folder in Program Files, then reinstall the GP client. That didn't solve the connection issues.
Looks like we'll be reverting back to the previous OS until PAN has a better handle on this GlobalProtect issue. Very frustrating!
01-31-2012 10:27 PM
Release notes for GP 1.1.2 seem to address the saved password and reconnect after hibernation issues.
Have not tested yet, but will tomorrow, just wanted to put this out there..
From Release Notes:
•35430 – When the GlobalProtect portal "Agent" settings "User can save password" and "Use single sign-on" are both disabled, the GlobalProtect client is still caching the login credentials and the "remember me" option is available on the client.
• 35234 – GlobalProtect is not re-establishing a VPN connection after the host computer comes out of hibernate or sleep mode
02-08-2012 04:49 PM
Were you using the IPSec client or the AnyConnect client and what were the parameters you used?
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!