GlobalProtect User Authentication

GlobalProtect User Authentication

• Local Authentication—Both the user account credentials and the authentication mechanisms are local to the firewall. This authentication mechanism isn't scalable because it requires an account for every GlobalProtect user and is, therefore, advisable for small deployments only.
• External Authentication—User authentication functions are performed by external LDAP, Kerberos, TACACS+, SAML, or RADIUS services (including support for two-factor, token-based authentication mechanisms, such as one-time password (OTP) authentication). To Set Up External Authentication you must create a server profile with settings for access to the external authentication service, create an authentication profile that refers to the server profile, and specify client authentication in the portal and gateway configurations. As an optional step, you can specify the OS of the endpoint that will use these settings. You can use different authentication profiles for each GlobalProtect component.
• Client Certificate Authentication—For enhanced security, you can configure the portal or gateway to use a client certificate to obtain the username and authenticate the user before granting access to the system. GlobalProtect also supports authentication by common access cards (CACs) and smart cards, which rely on a certificate profile. With these cards, the certificate profile must contain the root CA certificate that issued the certificate to the smart card or CAC.
• Two-Factor Authentication—With two-factor authentication, the portal or gateway authenticates users through two mechanisms, such as a one-time password (OTP) and Active Directory (AD) login credentials. You can enable two-factor authentication by configuring and adding both a certificate profile and authentication profile to the portal and gateway configuration. You can configure the portal and gateways to use either the same authentication method or different authentication methods. Regardless, users must successfully authenticate through the two mechanisms that the component demands before they can gain access to the network resources.
• (Windows and macOS only) Multi-Factor Authentication for Non-Browser-Based Applications—For sensitive, non-browser-based network resources (for example, financial applications or software development applications) that may require additional authentication, the GlobalProtect app can notify and prompt the user to perform the timely, multi-factor authentication required to access these resources.
• (Windows and macOS only) Single Sign-On—With single sign-on (SSO), which is enabled by default, the GlobalProtect app uses the user’s OS login credentials to automatically authenticate and connect to the GlobalProtect portal and gateway. You can also configure the app to wrap third-party credentials to ensure that Windows users can authenticate and connect using a third-party credential provider.
  SAML SSO is not supported on macOS.
• (Prisma Access only) Cloud Identity Engine—The Cloud Identity Engine provides both user identification and user authentication for mobile users in a Panorama Managed Prisma Access—GlobalProtect deployment. Using the Cloud Identity Engine for user authentication and username-to-user group mapping allows you to write security policy based on users and groups, not IP addresses, and helps secure your assets by enforcing behavior-based security actions. By continually syncing the information from your directories, the Cloud Identity Engine ensures that your user information is accurate and up to date and policy enforcement continues based on the mappings even if the SAML identity provider (IdP) is temporarily unavailable. Prisma Access users must be running GlobalProtect app 6.0 or later with a Prisma Access Innovation release 3.0 or later.
  Cloud Identity Engine supports the following authentication methods for GlobalProtect:

  • SAML
  • Client Certificate
  • OIDC (Starting from GlobalProtect app versions 6.2.6 & later and 6.3.2 & later)