GlobalProtect: Authentication Policy with MFA

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.
L3 Networker
100% helpful (2/2)

GlobalProtect: Authentication Policy with MFAGlobalProtect: Authentication Policy with MFA


In my previous article, "GlobalProtect: User/Device Context & Compliance," we covered security policy matching based on user identity and device context provided via the GlobalProtect app. We also enabled notifications to the end user based on compliance of the endpoint.


In this post, we are going to configure Authentication Policy with MFA to provide elevated access for both HTTP and non-HTTP traffic to specific sensitive resources. You can see a diagram of the environment here.


The value in leveraging Authentication Policy with MFA is to ensure that regardless of whether or not a user is known and the device is compliant, they must authenticate with multiple factors to validate their identity prior to accessing a specific resource. This helps prevent lateral movement by malicious attackers that are persisting internally via a compromised machine or with phished credentials.


NOTE: This article assumes the following:
  • You have already followed the previous articles in this series
  • You have DUO MFA configured

Although this capability can be configured without GlobalProtect for HTTP applications, we are going to focus on non-HTTP applications to highlight the GlobalProtect app's role in the authentication prompt process.



Part IV - Authentication Policy with MFA

  • Navigate to Device > Certificate Management > SSL/TLS Service Profile > Add to create a profile that references the root CA created previously

SSL/TLS Service Profile to Add a ProfileSSL/TLS Service Profile to Add a Profile

  • Navigate to Device > Authentication Profile > Add to create a new profile that consists of the LDAP and DUO Server Profiles that were previously created
    • On the Authentication tab
      • Enter a Name
      • Set the Type to LDAP
      • Set the Server Profile to LDAP
      • Enter a Login Attribute of sAMAccountName
      • Set the User Domain to your domain

Authentication Profile to Set User DomainAuthentication Profile to Set User Domain

  • On the Factors tab
    • Check the Enable Additional Authentication Factors box
    • Add the Multi-Factor Authentication Server Profile that was previously created as part of your DUO setup

Authentication Profile for LDAP Auth-DuoAuthentication Profile for LDAP Auth-Duo

  • On the Advanced tab, select the user group previously created to add to the Allow List
  • Click OK
  • Navigate to Device > User Identification > Captive Portal and click on the gear icon
    • Check the Enable Captive Portal box
    • Select the SSL/TLS Service Profile and Authentication Profile that were previously created
    • Set the Mode to Redirect
    • Set the Redirect Host to an IP address of an interface on the firewall
      • In my case, its the IP address of my trust interface
    • Click OK

Captive Portal window to Enable Captive PortalCaptive Portal window to Enable Captive Portal

  • Navigate to Network > GlobalProtect > Portals > select the previously configured portal > Agent > select the previously configured config > App > and change the following App Configurations parameters
    • Set Connect Method to User-logon (Always On)
    • Set Enable Inbound Authentication Prompts from MFA Prompts (UDP) to Yes
    • Set Trusted MFA Gateways to the IP address referenced in your Captive Portal along with port 6082
      • In my case its
    • Click OK

Config App Tab App to Configurations ParametersConfig App Tab App to Configurations Parameters

  • Navigate to Objects > Authentication > Add to create a new Authentication Enforcement
    • Enter a Name
    • Set the Authentication Method to web-form
    • Set the Authentication Profile to the MFA profile that was previously created
    • Click OK

Authentication Enforcement for DuoAuthentication Enforcement for Duo

  • Navigate to Policies > Authentication > Add to create an authentication rule
    • NOTE: If you need a resource for testing, there are plenty of test SSH servers available publicly. In the example below, that is what I am using
    • As shown below, any user in the trust or gp zone that generates traffic destined to a specific server in the untrust zone will be prompted to authenticate, regardless of whether they are a verified user or not

Policies > Authentication > Add Authentication RulePolicies > Authentication > Add Authentication Rule

  • Commit the configuration
  • Lastly, when testing with a Windows client, make sure that the host firewall is allowing UDP port 4501 inbound


You should now be able to test access to the resource. Here is the general workflow that you can follow:
  • Ensure the GlobalProtect app is connected to either an external or internal gateway
  • From operational mode in the CLI, run the 'show user ip-user-mapping all type CP' to show authenticated users
    • It should show 0 users
  • Attempt to access the resource referenced in the Authentication Policy rule, and you will see a prompt requiring you to authenticate

GlobalProtect - Protected ResourceGlobalProtect - Protected Resource

  • Upon authenticating via the factors you defined, you should be able to access the resource as well as run the same 'show user ip-user-mapping all type CP' and see your user account

In my next article, "GlobalProtect: Pre-Logon Authentication," we will configure pre-logon authentication using machine certificates.

Rate this article:
L2 Linker

Is it working with SAML + Azure MFA ? 

L1 Bithead

@DLONGPRÉ It works great with Azure AD SAML authentication and MFA is prompted in Azure login. No need for any additional configuration specific to MFA. 

L4 Transporter

I currently have pre-login working with SSO + SAML with Azure MFA... the issue that I see is that when a user stays logged in for a time greater than their time required to reauthenticate via MFA, the machine is stuck in a limbo state during this time.  Has anyone else experienced this and does anyone know of a workaround?


L1 Bithead

@DLONGPRÉ  @CEkanayake2   Are you currently using Azure MFA, Authentication Policy and GlobalProtect?  If so, can you help me out?   Trying to use this to restrict administrative access to resources to comply with new requirements and I'm having a difficult time.

L1 Bithead

Is there a way to make this work where the user only receives an MFA push notification directly to their phone when they hit a Security Authentication policy? I want to use this with user-certificate authentication. My ideal workflow would be as follows:
1. With prelogon configured, the user authenticates with their user certificate (not machine), and by the time they're done signing into their laptop, they are authenticated to Globalprotect. This allows us to have usernames in the traffic logs, and formulate security policies (eg for Internet) with Security Profile Groups attached to them for L7 protection. As a fallback, SAML auth profile is configured, and if a user has an issue with their certificate they receive a SAML login prompt. 

Step 1 works absolutely perfectly. Anyone that just needs to use the internet never has to think about the VPN, they're always connected and protected by the Security Group profile that is configured.

2. When the user tries to access an internal resource in the network, (hitting a security authentication policy), they receive an MFA push to their company-issued phone. After they acknowledge the challenge, they are free to access internal resources for x amount of hours.


is this a technically possible solution? 

L0 Member

@Brooks_Hassinger it should be possible. The MFA push is performed separately based on the auth profile applied to the auth policy, which is separate from the GP authentication process.

Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎07-11-2022 11:30 PM
Updated by: