How Does the App Know What Credentials to Supply?
By default the GlobalProtect app uses the same login credentials for the gateway as
for portal login, but allows customization of credentials for different portals and
gateways. Options for stronger and faster authentication are available.
| Where Can I Use This? | What Do I Need? |
|---|
- NGFW (managed by Panorama or Strata Cloud Manager)
- Prisma Access (managed by Panorama or Strata Cloud
Manager)
|
- GlobalProtect Gateway license or Prisma Access license with
the Mobile User subscription
|
By default, the GlobalProtect app attempts to use the same login credentials for
the gateway that it used for portal login. In the simplest case, where the gateway and
the portal use the same authentication profile or certificate profile, the app connects
to the gateway transparently.
On a per-app configuration basis, you can also customize which
GlobalProtect portal and gateways—internal, external, or manual
only—require different credentials (such as unique OTPs). This enables
the GlobalProtect portal or gateway to prompt for the unique OTP without
first prompting for the credentials specified in the authentication
profile.
You can modify the default app authentication behavior either by configuring cookie
authentication settings or with two-factor authentication so that authentication is both
stronger and faster:
Cookie Authentication on the Portal or Gateway
Cookie authentication simplifies the authentication process for end users because
they will no longer be required to log in to both the portal and the gateway in
succession or enter multiple OTPs for authenticating to each. This improves the user
experience by minimizing the number of times that users must enter credentials. In
addition, cookies enable use of a temporary password to re-enable VPN access after
the user’s password expires.
You can configure cookie authentication settings independently for the portal and for
individual gateways (for example, you can impose a shorter cookie lifetime on
gateways that protect sensitive resources). After the portal or gateways deploy an
authentication cookie to the endpoint, the portal and gateways both rely on the same
cookie to authenticate the user. When the app presents the cookie, the portal or
gateway evaluates whether the cookie is valid based on the configured cookie
lifetime. If the cookie expires, GlobalProtect automatically prompts the user to
authenticate with the portal or gateway. When authentication is successful, the
portal or gateway issues the replacement authentication cookie to the endpoint, and
the validity period starts over.
Consider the following example where you configure the cookie lifetime for the
portal—which does not protect sensitive information—as 15 days, but configure the
cookie lifetime for gateways—which do protect sensitive information—as 24 hours.
When the user first authenticates with the portal, the portal issues the
authentication cookie. If the user attempted to connect to the portal after five
days, the authentication cookie would still be valid. However, if the user attempted
to connect to the gateway after five days, the gateway would evaluate the cookie
lifetime and determine it expired (5 days > 24 hours). The agent would then
automatically prompt the user to authenticate with the gateway and, on successful
authentication, receive a replacement authentication cookie. The new authentication
cookie would then be valid for another 15 days on the portal and another 24 hours on
the gateways.
Credential Forwarding to Some or All Gateways
With two-factor authentication, you can specify the portal and types of gateways
(internal, external, or manual only) that prompt for their own set of credentials.
This option speeds up the authentication process when the portal and the gateway
require different credentials (either different OTPs or different login credentials
entirely). For each portal or gateway that you select, the app does not forward
credentials, allowing you to customize the security for different GlobalProtect
components. For example, you can have the same security on your portals and internal
gateways, while requiring a second factor OTP or a different password for access to
those gateways that provide access to your most sensitive resources.
