Palo Alto Networks: Captive Portal vs. GlobalProtect for User Authentication and User-ID

Core Concept: User-ID in Palo Alto Networks

At the heart of Palo Alto Networks' Next-Generation Firewalls (NGFWs) is the User-ID technology. User-ID allows the firewall to integrate with a wide range of enterprise directories and terminal services to associate IP addresses with specific users. This user-to-IP mapping is crucial for enabling granular security policies based on user identity rather than just IP addresses, enhancing visibility, and simplifying reporting. Both Captive Portal and GlobalProtect are powerful mechanisms within PAN-OS that contribute to populating these User-ID mappings, albeit through different approaches and for distinct use cases.

Captive Portal (Authentication Portal) Deep Dive

Captive Portal, also referred to as Authentication Portal in PAN-OS, is a method to identify and authenticate users who are attempting to access network resources through the Palo Alto Networks NGFW. When a user's traffic matches an Authentication Policy rule, the firewall can prompt them for credentials before allowing or denying access. This is particularly effective for scenarios where other User-ID methods (like AD domain controller monitoring or syslog parsing) are not feasible or for specific groups of users like guests.

Mechanism of Action

The process typically involves:

1. A user attempts to access a resource (e.g., browse the internet).
2. The traffic hits the Palo Alto Networks firewall and matches an Authentication Policy rule. This rule specifies the source/destination zones, addresses, services, and, critically, the "Source User" field which is often set to "unknown" to trigger authentication for unidentified users.
3. The Authentication Policy rule is linked to an Authentication Profile , which defines the authentication method (e.g., LDAP, RADIUS, Kerberos, SAML, local database) and the server profile for that method.
4. The firewall then challenges the user for credentials using one of the configured Authentication Portal methods.
5. Upon successful authentication, the firewall creates an IP-address-to-username mapping in its User-ID table. This mapping is then used for Security Policy evaluation.
6. The User-ID mapping source for Captive Portal authenticated users will appear as "Auth Portal" or "CP" in the mapping table.

   admin@PA-VM> show user ip-user-mapping all
   
   IP              Vsys   User                               From    IdleTimeout(s) MaxTimeout(s)
   --------------- ------ ---------------------------------- ------- -------------- ------------
   192.168.1.100   vsys1  example\jsmith                     CP      27000          27000
               

Authentication Methods within Captive Portal

• Web Form:
  • This is the most common method. The firewall presents a web-based login form to the user.
  • Supports authentication against:
    • LDAP servers (e.g., Microsoft Active Directory)
    • RADIUS servers (can be used for MFA integration)
    • SAML Identity Providers (IdP) for Single Sign-On (SSO)
    • Kerberos (indirectly, by authenticating to a server that then uses Kerberos)
    • Local User Database on the firewall (suitable for small deployments or backup)
    • Multi-Factor Authentication (MFA) can be enforced through integration with RADIUS servers that support MFA (e.g., Duo, Okta RADIUS agent) or SAML IdPs configured for MFA.
  • The appearance of the web form (Response Pages) can be customized under Device > Response Pages .
• Kerberos Single Sign-On (SSO):
  • Attempts to authenticate users transparently if they are already logged into a Windows domain that uses Kerberos.
  • Requires a Kerberos Server Profile configured on the firewall, pointing to the KDC (Key Distribution Center, typically a domain controller).
  • The firewall needs a service account and a Service Principal Name (SPN) registered in Active Directory.
  • The browser must be configured to support Integrated Windows Authentication and trust the firewall's portal FQDN.
  • Typically used in Redirect Mode because browsers will only send Kerberos tickets to trusted sites.
  • If Kerberos SSO fails, it can fall back to the Web Form method if configured in the Authentication Profile.
• Client Certificate Authentication:
  • Authenticates users based on a valid client certificate presented by the user's browser.
  • Requires a Certificate Profile on the firewall configured to validate client certificates against a trusted CA.
  • The firewall acts as the authenticator, checking the certificate's validity, revocation status (via CRL or OCSP), and other attributes.
  • This method provides strong authentication but requires a PKI infrastructure to issue and manage client certificates.
• Multi-Factor Authentication (MFA):
  • PAN-OS Captive Portal can integrate with MFA providers. This is typically achieved via:
    • RADIUS: The Authentication Profile points to a RADIUS server that acts as a proxy to an MFA solution (e.g., Duo Security, RSA SecurID, Okta RADIUS Agent). The user enters their primary credentials, and the MFA server pushes a secondary challenge or expects a one-time password (OTP).
    • SAML: If using SAML for Captive Portal authentication, the SAML IdP (e.g., Okta, Azure AD) can be configured to enforce MFA as part of its authentication flow. The firewall redirects the user to the SAML IdP, which handles the MFA challenge.
  • MFA significantly enhances security by requiring more than one form of verification.

Captive Portal Modes of Operation: Transparent vs. Redirect

How the firewall presents the authentication challenge is determined by the Captive Portal mode, configured within the Captive Portal settings ( Device > User Identification > Captive Portal Settings ).

Transparent Mode

• Mechanism: The firewall intercepts the user's HTTP/HTTPS traffic destined for an external website. It then spoofs the destination server's IP address and presents an HTTP 401 Unauthorized response, which prompts the browser to request credentials. For HTTPS traffic, the firewall must present a certificate.
• Certificate Consideration:
  • For HTTP traffic, this is generally seamless.
  • For HTTPS traffic, since the firewall is impersonating the actual destination server (e.g., www.google.com) but does not possess its private key, it must present *a* certificate. If users access an HTTPS site, the browser will display a certificate warning because the certificate presented by the firewall will not match the intended destination's certificate and likely won't be trusted for that FQDN.
  • To mitigate this for HTTPS in Transparent mode, a "Forward Trust" certificate (a CA certificate installed on client browsers as trusted) can be used by the firewall to dynamically generate and sign certificates for the impersonated sites. However, users will still see that the certificate is issued by the firewall's CA, not the original site's CA, which can be confusing.
• Use Case: Generally not recommended due to certificate issues with HTTPS. It might be considered in Layer 2, Virtual Wire, or Tap mode deployments where the firewall doesn't have a Layer 3 interface in the user's traffic path for redirection.
• User Experience: Can be poor due to frequent certificate warnings for HTTPS sites, potentially training users to ignore such warnings.

Redirect Mode

• Mechanism: The firewall intercepts the user's initial HTTP/HTTPS request. Instead of trying to proxy or impersonate the destination, it sends an HTTP 302 Found/Redirect message to the user's browser. This redirect points the browser to a specific Layer 3 interface IP address or FQDN on the firewall where the Authentication Portal (web form) is hosted.
• Certificate Consideration:
  • The firewall uses its own certificate for the Authentication Portal FQDN (e.g., `portal.company.com`). This certificate should be signed by a trusted CA (public or internal enterprise CA) and installed on the firewall.
  • Since the user's browser is explicitly redirected to the firewall's portal FQDN for authentication, certificate errors are avoided if the portal's certificate is valid and trusted by the client.
• User Experience: Much smoother and more secure, as there are no misleading certificate warnings related to the originally requested site. This is the recommended mode .
• Requirements:
  • A Layer 3 interface on the firewall accessible by the users being authenticated.
  • DNS record for the portal FQDN resolving to the firewall's Layer 3 interface IP.
  • A valid SSL/TLS certificate for the portal FQDN.
• Session Cookie: Redirect mode supports a session cookie. Once authenticated, if the user's IP address changes (e.g., a wireless user roaming between APs but staying on the same logical network), the cookie can maintain the authenticated session, preventing repeated login prompts. Transparent mode typically does not support this as effectively.
• Compatibility: Essential for Kerberos SSO and SAML authentication, as browsers will only send Kerberos tickets or SAML assertions to trusted sites with valid certificates.

Key Configuration Components for Captive Portal

1. Authentication Profile: ( Device > Authentication Profile ) Defines the authentication method (LDAP, RADIUS, SAML, Kerberos, Local), server profiles, and advanced settings like allow lists.
2. Authentication Server Profile: (e.g., Device > Server Profiles > LDAP ) Contains connection details for the backend authentication server.
3. Captive Portal Settings: ( Device > User Identification > Captive Portal Settings ) Configures the mode (Transparent/Redirect), redirect host (for Redirect Mode), session timers (Idle Timer, Timer), and certificate for the portal.
4. Authentication Policy: ( Policies > Authentication ) Triggers the Captive Portal. Rules define source/destination zones, addresses, users (typically 'unknown' to trigger for unauthenticated users), and the Authentication Profile to use. The action is typically "Authentication Enforcement."
5. Certificate Profile (for Client Certificate Auth): ( Device > Certificate Management > Certificate Profile ) Defines CA certificates for validating client certs.
6. SSL/TLS Service Profile (for Redirect Mode Portal): ( Device > Certificate Management > SSL/TLS Service Profile ) Assigns the server certificate that the firewall will present for its HTTPS-based authentication portal.

Use Cases for Captive Portal

• Guest Networks: Providing internet access to guests after they accept an AUP or authenticate with temporary credentials.
• BYOD (Bring Your Own Device) Environments: Identifying users on personal devices that are not domain-joined.
• Non-Windows/Non-Domain Environments: Authenticating users on macOS, Linux, or mobile devices where domain-based SSO is not straightforward.
• Specific Application Access: Requiring authentication for users attempting to access particular sensitive internal applications.
• Contractors/Temporary Staff: Providing controlled network access with distinct credentials.

Timers and Nonces

• Idle Timer and Timer (Session Timeout): Configured in Captive Portal Settings.
  • Timer (Max Session Timeout): The maximum duration a user mapping learned via Captive Portal will remain active, regardless of activity.
  • Idle Timer: The duration of inactivity after which the user mapping will be removed. Activity resets this timer.
• Enable Nonce: Found under Device > User Identification > Captive Portal Settings > Authentication Timers . When enabled, the firewall adds a unique, randomly generated key (nonce) to the Captive Portal redirect URL. This helps prevent credential replay attacks by ensuring that each login attempt is unique. It is a recommended security practice to enable nonces.

GlobalProtect Deep Dive

GlobalProtect extends the protection of the Palo Alto Networks NGFW to users wherever they are located – on the local network, at home, or on the road. It provides secure access to enterprise resources by establishing a VPN connection (typically SSL VPN or IPSec) to a GlobalProtect Gateway on the firewall. A key function of GlobalProtect is to provide consistent user identification and security policy enforcement for these remote and mobile users.

GlobalProtect Components

• GlobalProtect Client/App: Software installed on the endpoint (Windows, macOS, Linux, iOS, Android, ChromeOS). It initiates the connection, authenticates the user, and can collect Host Information Profile (HIP) data.
• GlobalProtect Portal: Resides on a Palo Alto Networks firewall. Its primary functions are:
  • Authenticates users initially.
  • Provides the GlobalProtect client with the agent configuration (e.g., list of available gateways, connection settings, trusted CAs).
  • Manages client certificates if used for authentication.
  • Can also provide Clientless VPN access for browser-based applications.
• GlobalProtect Gateway(s): Resides on a Palo Alto Networks firewall (can be the same or different firewall as the Portal). Its primary functions are:
  • Terminates the VPN tunnels from GlobalProtect clients.
  • Authenticates users for tunnel access (can be a second factor or re-authentication).
  • Enforces security policies on the traffic passing through the tunnel.
  • Receives HIP reports from clients and can use this information in policy decisions.

High-level interaction between GlobalProtect components: Client, Portal, and Gateway, leading to secure access to internal resources.

Authentication Mechanisms in GlobalProtect

• Credential-Based Authentication:
  • Users authenticate using their enterprise credentials (username/password).
  • Supported backends include LDAP, RADIUS, Kerberos, SAML, and local firewall user databases.
  • Typically configured via an Authentication Profile and Server Profile , similar to Captive Portal.
• Client Certificate Authentication:
  • Uses X.509 certificates for authenticating either the device (machine certificate) or the user, or both.
  • Portal can be configured to issue certificates to clients upon successful credential-based authentication, or pre-deployed certificates can be used.
  • Gateway can then require a valid client certificate for tunnel establishment.
  • Enhances security by verifying the identity of the connecting endpoint/user cryptographically.
• SAML Integration for SSO:
  • GlobalProtect Portal and Gateway can act as SAML Service Providers (SPs), integrating with an external SAML Identity Provider (IdP) like Okta, Azure AD, PingFederate.
  • Provides a seamless SSO experience for users; they authenticate once with the IdP.
  • The IdP can enforce its own policies, including MFA.
• Multi-Factor Authentication (MFA):
  • Highly recommended for GlobalProtect.
  • Can be integrated via:
    • RADIUS: Authenticate against a RADIUS server that proxies to an MFA provider.
    • SAML: The SAML IdP handles the MFA challenge.
    • PAN-OS MFA Server Profile (for certain MFA vendors): Direct integration for specific MFA solutions for password-based authentication methods (LDAP, Kerberos, RADIUS). This prompts the user for an MFA code/OTP directly in the GlobalProtect client or a separate prompt after primary authentication.
    • Cookie Authentication: After initial MFA, a cookie can be used for a period to avoid repeated MFA prompts, enhancing user experience while maintaining security.
• Two-Factor Authentication (using combination): Often, a combination is used, e.g., username/password + client certificate, or SAML (with IdP-enforced MFA) + client certificate.

Deployment Scenarios for GlobalProtect

• Always-On VPN:
  • The GlobalProtect client automatically establishes a VPN connection as soon as the user logs into their endpoint or the endpoint boots up (using pre-logon).
  • Maintains a persistent connection to ensure continuous security and policy enforcement.
  • Internal Host Detection (IHD): The client can detect if it's on the internal network (e.g., by trying to resolve an internal-only DNS name or reach an internal HTTP server). If internal, it can either remain connected (internal gateway mode) or disconnect the VPN tunnel while still collecting HIP data.
  • Often preferred for corporate-managed devices to ensure consistent security posture.
• On-Demand VPN:
  • Users manually initiate the VPN connection when they need to access corporate resources.
  • Suitable for scenarios where continuous connection is not required or for user-owned devices.
• User-Logon (Connect Method):
  • The GlobalProtect client attempts to establish a VPN tunnel after the user logs into the endpoint.
  • This is a common Always-On configuration.
• Pre-Logon (Connect Method):
  • The GlobalProtect client establishes a VPN tunnel *before* the user logs into the endpoint.
  • Uses a machine certificate for authentication or cached credentials.
  • Crucial for remote management tasks like applying Group Policies, software updates, or allowing users to change expired passwords remotely.
  • Requires "Enforce GlobalProtect for Network Access" in the Agent config for Windows.
  Gotcha! (Palo Alto Networks): Pre-logon requires careful certificate management if using machine certificates. Also, ensure the pre-logon tunnel has access to necessary infrastructure like Domain Controllers and DNS for user login to function correctly. User-ID mappings from pre-logon tunnels will be `pre-logon@ ` or similar until the user logs in, then it updates to the actual username.

GlobalProtect and User-ID Mapping

GlobalProtect is a highly reliable source for User-ID information. When a user successfully authenticates to a GlobalProtect Gateway:

• The Gateway creates an IP-address-to-username mapping. The IP address is the inner IP assigned to the client from the Gateway's IP pool.
• This mapping is registered locally on the Gateway firewall and can also be redistributed to other firewalls via User-ID redistribution if Panorama or inter-firewall User-ID sharing is configured.
• The source of these mappings in the User-ID table will be "GP" or "GlobalProtect."

admin@PA-VM> show user ip-user-mapping all

IP              Vsys   User                               From    IdleTimeout(s) MaxTimeout(s)
--------------- ------ ---------------------------------- ------- -------------- ------------
10.5.5.10       vsys1  example\ruser                      GP      27000          27000
    

This ensures that all traffic originating from the GlobalProtect user (through the VPN tunnel) is accurately associated with their username, allowing for consistent user-based policy enforcement regardless of their physical location.

Host Information Profile (HIP) Integration

A significant advantage of GlobalProtect is its ability to collect Host Information Profile (HIP) data from endpoints.

• The GlobalProtect client inspects the endpoint for various attributes, such as:
  • OS version and patch level
  • Antivirus software (name, version, last scan, definition date)
  • Anti-spyware software
  • Disk encryption status
  • Firewall status
  • Presence of specific files, registry keys, or processes
  • Custom checks
• This HIP data is sent as a HIP report to the GlobalProtect Gateway.
• The firewall can then use this HIP information in HIP Objects and HIP Profiles , which can be used as matching criteria in Security Policies.
• This allows for dynamic policy enforcement based on the endpoint's security posture. For example, non-compliant devices might be denied access or quarantined to a restricted network segment.
• HIP checks ensure that only devices meeting corporate security standards can access sensitive resources.

Simplified flow of GlobalProtect HIP check process. The client sends a HIP report, the gateway uses this information in conjunction with the policy engine to determine access rights based on endpoint compliance.

Split Tunneling

GlobalProtect Gateways can be configured for split tunneling, which determines what traffic is sent through the VPN tunnel versus what traffic goes directly to the internet from the client's local connection.

• Tunnel All Traffic: All traffic from the client (except local subnet traffic if excluded) is sent through the VPN tunnel. This provides maximum security and visibility as all traffic is inspected by the firewall. This is often the recommended approach for corporate devices.
• Split Tunnel by Access Route: Only traffic destined for specific networks (access routes) defined in the Gateway configuration is sent through the VPN tunnel. Other traffic (e.g., general internet browsing) goes directly from the client. This can save bandwidth on the corporate network but reduces visibility into non-tunneled traffic.
• Split Tunnel by Domain/Application: More granular control, allowing specific domains or applications to be included or excluded from the tunnel.

Licensing

• Basic GlobalProtect VPN functionality (Portal, Gateway, Client connectivity) does not require a separate license on the firewall.
• A GlobalProtect subscription license is required for advanced features, including:
  • Full HIP check functionality (collection, notification, and enforcement in policies). Without a license, basic HIP collection might occur but enforcement is limited.
  • Support for certain advanced MFA integrations via the PAN-OS MFA Server Profile.
  • Clientless VPN features.
  • iOS/Android per-app VPN.
  • And other features as defined in Palo Alto Networks documentation.

Feature Comparison: Captive Portal vs. GlobalProtect

User-ID Mapping Process Comparison

Both Captive Portal and GlobalProtect contribute to the User-ID mapping table on the PAN-OS firewall, which is essential for user-based policy enforcement. However, their mechanisms and reliability differ.

User-ID with Captive Portal

User-ID mapping process using Captive Portal (Redirect Mode). Successful authentication results in an IP-to-User mapping stored by the User-ID agent on the firewall.

• Source of Mapping: When a user authenticates via Captive Portal, the firewall's internal User-ID process (acting as an agent) creates a mapping. The "From" field in show user ip-user-mapping will show "CP" or "Auth Portal".
• Reliability: Dependent on session timeouts (idle and max). If a user's IP changes (and no session cookie or other mechanism maintains it), they might need to re-authenticate. Less "sticky" than GlobalProtect for highly mobile users.
• Scope: Typically identifies users on the local network segments protected by the firewall where Captive Portal is enforced.

User-ID with GlobalProtect

User-ID mapping process with GlobalProtect. Successful authentication at the Gateway results in an IP-to-User mapping for the VPN-assigned IP address.

• Source of Mapping: When a user connects and authenticates to a GlobalProtect Gateway, the Gateway firewall's User-ID process creates the mapping. The "From" field will show "GP" or "GlobalProtect". The IP address is the one assigned to the client from the Gateway's IP pool.
• Reliability: Very reliable. The mapping persists as long as the VPN tunnel is active. Since the user's identity is tied to the VPN connection itself, it's consistent even if the user roams across different physical networks.
• Scope: Identifies remote/mobile users connecting from anywhere. If User-ID redistribution is configured (e.g., via Panorama or firewall-to-firewall), these mappings can be shared with other firewalls in the network.

Palo Alto Networks Configuration and Troubleshooting CLI Commands

Familiarity with PAN-OS CLI commands is essential for verification and troubleshooting.

User-ID Mappings

show user ip-user-mapping all                     // Displays all current IP-to-user mappings
show user ip-user-mapping ip <ip_address>         // Shows mapping for a specific IP
show user ip-user-mapping user <domain\user>      // Shows mapping for a specific user
show user user-id-agent statistics                // Shows statistics for User-ID agents, including mappings
    

Captive Portal / Authentication Portal

show user captive-portal statistics               // Shows Captive Portal statistics
show user captive-portal captive-portal-sessions  // Displays active Captive Portal sessions (older PAN-OS)
show user auth-portal-sessions all                // Displays active Authentication Portal sessions (newer PAN-OS)
show running logging configured service authd     // Check authd daemon logging level (debug for troubleshooting)
less mp-log authd.log                             // View Authentication Daemon logs (for detailed troubleshooting)
debug authentication-portal reset ip <ip_address> // Clears an active Authentication Portal session for a specific IP
    

GlobalProtect

show global-protect-portal current-user           // Shows users currently connected to the Portal
show global-protect-gateway current-user gateway <gateway_name> // Shows users connected to a specific Gateway
show global-protect-gateway flow gateway <gateway_name> // Shows traffic flow statistics for a Gateway
show global-protect-gateway tunnel gateway <gateway_name> // Shows active tunnels on a Gateway
show global-protect-gateway hip-report gateway <gateway_name> user <username> // Shows last HIP report for a user
less mp-log gpsrv.log                             // View GlobalProtect service logs
less mp-log PanGPS.log                            // View older GlobalProtect service logs
    

Security Best Practices in Palo Alto Networks Environments

For Captive Portal:

• Use Redirect Mode: Provides a better user experience and is more secure due to proper certificate handling for the portal itself.
• Secure Authentication Protocols: Prefer SAML or Kerberos for integration with enterprise identity systems. If using LDAP, ensure LDAPS (LDAP over SSL/TLS) is used.
• Enforce Multi-Factor Authentication (MFA): Integrate with an MFA provider via RADIUS or SAML to significantly strengthen authentication.
• Use Strong Certificates: Ensure the certificate used for the Authentication Portal (in Redirect Mode) is issued by a trusted CA and is not expired.
• Customize Response Pages: Provide clear instructions and branding on login and success/failure pages. Inform users about AUPs.
• Implement Appropriate Timeouts: Configure reasonable Idle Timer and Session Timer values to balance security and user convenience. Shorter timeouts reduce the window of opportunity if a session is compromised.
• Enable Nonces: Protect against credential replay attacks.
• Restrict Management Access: Ensure the interface hosting the Captive Portal is not overly exposed and that management access to the firewall via that interface is restricted.

For GlobalProtect:

• Enforce Strong Authentication with MFA: This is critical for remote access. Use SAML with an IdP that enforces MFA, or RADIUS with an MFA provider, or the PAN-OS MFA Server Profile.
• Use Client Certificates: Add another layer of authentication by requiring valid client certificates, especially for corporate-managed devices. Consider pre-logon with machine certificates.
• Implement HIP Checks: Use HIP Objects and Profiles to assess endpoint security posture and enforce compliance before granting access to sensitive resources. Keep HIP definitions up-to-date.
• Prefer "Always-On" for Corporate Devices: Ensures continuous protection and policy enforcement. Use Internal Host Detection (IHD) effectively.
• Limit Access with Granular Policies: Apply the principle of least privilege. GlobalProtect users should only have access to the resources they need. Use user-based and HIP-based Security Policies.
• Tunnel All Traffic (where appropriate): For maximum security and visibility, especially for corporate devices, configure gateways to tunnel all traffic. If split tunneling is used, carefully define access routes and understand the risks.
• Keep GlobalProtect Client Software Updated: Ensure users are running the latest version of the GlobalProtect client for security patches and new features. The Portal can be configured to enforce minimum client versions.
• Monitor Logs: Regularly review GlobalProtect logs on the Portal and Gateways, as well as User-ID and traffic logs, for anomalous activity.