Changes to Default Behavior in GlobalProtect App 4.0
The following are changes to default behavior that affect GlobalProtect app 4.0. For changes to default behavior that affect GlobalProtect in PAN-OS 8.0, refer to the PAN-OS 8.0 Release Notes.
Changes to Default Behavior in GlobalProtect 4.0.8
- For new installations of the GlobalProtect app on Windows 8 or 10 endpoints, if you set the value to1for theHKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\SetGPCPDefaultregistry key, Windows now uses GlobalProtect as the default credential provider every time an end user logs in to Windows even if, after the last login, the user selected another credential provider through the Sign-in options on the login page. Previously, the Windows login page always displayed the credential provider that the user last selected in the Sign-in options. Specifying no value for the SetGPCPDefault registry key ensures that the login page always displayed the credential provider that the user last selected.
Changes to Default Behavior in GlobalProtect 4.0.3
- The option toUpdate DNS Settings at Connect (Windows Only), which is available in the GlobalProtect portal agent configuration as an app customization, now applies only to GlobalProtect apps 4.0.2 and earlier releases. For GlobalProtect app 4.0.3 and later, you can configure the newResolve All FQDN Using DNS Servers Assigned by Tunnel (Windows Only)option. For more information, see Features Introduced in GlobalProtect App 4.0.3.On the macOS image, boot into Recovery OS and use the spctl kext-consent command to disable the user approval requirement completely or specify the Team ID PXPZ95SK77 to allow Palo Alto Networks as a KEXT that macOS can load without user approval.For Mac endpoints managed by mobile device management (MDM) systems, all endpoints with a valid MDM profile installed which specifies the Team ID PXPZ95SK77 do not require user approval to load any properly-signed kernel extension.All third-party KEXTs that were already installed at the time of upgrading to macOS 10.13 are automatically approved and don't require any user action. For unmanaged devices, if a user sees the popup after upgrading to macOS 10.13 (and you have not performed one of the above fixes), the user must follow the on-screen instructions to allow Palo Alto Networks to load kernel extensions. For additional information on this pop-up and the recommended fixes, see Apple Technical Note TN2459.
- GlobalProtect can now automatically retry the connection when network disconnects occur due to network instability or endpoint state changes. For more information, see Features Introduced in GlobalProtect App 4.0.3.
- To improve the logic the GlobalProtect app uses to select the best gateway, the app now prioritizes the gateways assigned highest, high, and medium priority ahead of gateways assigned a low or lowest priority regardless of response time. Previously, the app would connect to a lower priority gateway only if the response time for the higher priority gateway is greater than the average response time across all gateways. For more information, see Features Introduced in GlobalProtect App 4.0.3.
- In macOS 10.13, Apple introduced a new feature that prompts users to approve any third-party extensions (KEXTS). Although the GlobalProtect app is compliant with the KEXT change, the pop-up prompts can cause confusion for users. For enterprise deployments where you must distribute software that includes kernel extensions without requiring user approval, there are two options that prevent the user pop-ups when installing GlobalProtect:
All third-party KEXTs that were already installed at the time of upgrading to macOS 10.13 are automatically approved and don't require any user action. For unmanaged devices, if a user sees the popup after upgrading to macOS 10.13 (and you have not performed one of the above fixes), the user must follow the on-screen instructions to allow Palo Alto Networks to load kernel extensions. For additional information on this pop-up and the recommended fixes, see Apple Technical Note TN2459.
- On the macOS image, boot into Recovery OS and use thespctl kext-consentcommand to disable the user approval requirement completely or specify the Team IDPXPZ95SK77to allow Palo Alto Networks as a KEXT that macOS can load without user approval.
- For Mac endpoints managed by mobile device management (MDM) systems, all endpoints with a valid MDM profile installed which specifies the Team IDPXPZ95SK77do not require user approval to load any properly-signed kernel extension.
Changes to Default Behavior in GlobalProtect 4.0.2
- Traffic on a loopback interface is no longer blocked when you Enforce GlobalProtect for Network Access () and GlobalProtect is not connected. This change allows local applications that use ports for internal communication to run without a GlobalProtect connection. Previously, applications using the loopback interface failed.NetworkGlobalProtectPortals<GlobalProtect-portal-config>Agent<agent-config>AppApp Configurations
- If you Allow User to Disable GlobalProtect app, the Disable Timeout now applies when the user disables the app using any method (passcode, comment, or ticket), instead of just applying when users use the ticket method ().NetworkGlobalProtectPortals<GlobalProtect-portal-config>Agent<agent-config>AppApp Configurations
Changes to Default Behavior in GlobalProtect 4.0.0
- The name of the GlobalProtect gateway subscription has changed to GlobalProtect subscription. A GlobalProtect subscription is required for the following features: HIP checks and associated content updates, support for the GlobalProtect mobile app, IPv6 support, and GlobalProtect Clientless VPN.
- GlobalProtect app behavior for thehas changed. Prior to this change, if the server certificate verification failed (for example, the user was behind a Captive Portal network) the GlobalProtect app warned the user but still provided the user an option to continue with the connection. With this change, as long as a valid cached portal configuration exists on the endpoint, GlobalProtect will no longer continue with the portal connection if the server certificate verification fails; instead GlobalProtect uses the cache configuration to continue the connection to the gateway. This change prevents the user from accidentally continuing the connection to a man-in-the-middle (MITM) site.App ConfigurationAllow User to Continue with Invalid Portal Server CertificateAs a best practice, use a server certificate from a trusted root certificate authority (CA). However, if a non-trusted CA (such as a self-signed CA) issued the server certificate, then this change might impact user connections. To avoid disruption before the initial attempt by a GlobalProtect app to connect to the portal, selectandNetworkGlobalProtectPortalsAgentAddthe server certificate CA to the Trusted Root CA list.If you missed this step and made a configuration error and the user is now in a state where the initial portal connection was successful and the server certificate did not come from a trusted root CA, follow this procedure to recover the endpoint:
- Add the trusted root CA in the GlobalProtect portal configuration.
- Add a portal configuration or select an existing configuration, and then select Agent.
- In the Trusted Root CA list, Add the CA certificate used to issue the server certificate.
- On each affected GlobalProtect endpoint, delete all PANPortalCfg_*.dat files.
- On Windows, the files are located in:%userprofile%\AppData\Local\Palo Alto Networks\GlobalProtect.
- On Mac, the files are located in:$HOME/Library/Application/Support/PaloAltoNetworks/GlobalProtect
- For all other endpoints, uninstall the GlobalProtect app, or clear the app data for GlobalProtect.
Recommended For You
Recommended videos not found.