Map IP Addresses to Usernames Using Captive Portal
If the firewall receives a request from a security zone that has User-ID enabled and the source IP address does not have any user data associated with it yet, the firewall checks its Captive Portal policy rules for a match to determine whether to perform authentication. This is useful in environments where you have clients that are not logged in to your domain servers, such as Linux clients. The firewall triggers this user mapping method only for web traffic (HTTP or HTTPS) that matches a Captive Portal rule but has not been mapped using a different method.
Captive Portal Authentication Methods
Captive Portal uses the following methods to obtain user information from the client when a web request matches a Captive Portal rule:
Authentication Method Description
Kerberos SSO The firewall uses Kerberos Single Sign-On (SSO) to transparently obtain user credentials. To use this method, your network requires a Kerberos infrastructure, including a key distribution center (KDC) with an authentication server and ticket granting service. The firewall must have a Kerberos account, including a principal name and password. As a best practice, choose Kerberos transparent authentication over NTLM authentication. Kerberos is a stronger, more robust authentication method than NTLM and it does not require the firewall to have an administrative account to join the domain. If Kerberos SSO authentication fails, the firewall falls back to NT LAN Manager (NTLM) authentication. If you don’t configure NTLM, or NTLM authentication fails, the firewall falls back to web form or client certificate authentication, depending on your Captive Portal configuration.
NT LAN Manager (NTLM) The firewall uses an encrypted challenge-response mechanism to obtain the user credentials from the browser. When configured properly, the browser will transparently provide the credentials to the firewall without prompting the user, but will prompt for credentials if necessary. If you use the Windows-based User-ID agent, NTLM responses go directly to the domain controller where you installed the agent. If you configure Kerberos SSO authentication, the firewall tries that method first before falling back to NTLM authentication. If the browser can’t perform NTLM or if NTLM authentication fails, the firewall falls back to web form or client certificate authentication, depending on your Captive Portal configuration. Microsoft Internet Explorer supports NTLM by default. You can configure Mozilla Firefox and Google Chrome to also use NTLM but you can’t use NTLM to authenticate non-Windows clients.
Web Form The firewall redirects web requests to a web form for authentication. You can configure Captive Portal to use a local user database, RADIUS server, TACACS+ server, LDAP server, or Kerberos server to authenticate users (or an authentication sequence). Although the firewall always prompts users for credentials, this method works with all browsers and operating systems.
Client Certificate Authentication The firewall prompts the browser to present a valid client certificate to authenticate the user. To use this method, you must provision client certificates on each user system and install the trusted certificate authority (CA) certificate used to issue those certificates on the firewall.
Captive Portal Modes
The Captive Portal mode defines how the firewall captures web requests for authentication:
Mode Description
Transparent The firewall intercepts the browser traffic per the Captive Portal rule and impersonates the original destination URL, issuing an HTTP 401 to invoke authentication. However, because the firewall does not have the real certificate for the destination URL, the browser displays a certificate error to users attempting to access a secure site. Therefore, you should only use this mode when absolutely necessary, such as in Layer 2 or virtual wire deployments.
Redirect The firewall intercepts unknown HTTP or HTTPS sessions and redirects them to a Layer 3 interface on the firewall using an HTTP 302 redirect to perform authentication. This is the preferred mode because it provides a better end-user experience (no certificate errors). However, it does require additional Layer 3 configuration. Another benefit of the Redirect mode is that it provides for the use of session cookies, which enable the user to continue browsing to authenticated sites without requiring re-mapping each time the time outs expire. This is especially useful for users who roam from one IP address to another (for example, from the corporate LAN to the wireless network) because they won’t need to re-authenticate when the IP address changes as long as the session stays open. If you use Kerberos SSO or NTLM authentication, you must use Redirect mode because the browser will provide credentials only to trusted sites.
Configure Captive Portal
The following procedure shows how to configure Captive Portal using the PAN-OS integrated User-ID agent to redirect web requests that match a Captive Portal rule to a redirect host. A redirect host is the intranet hostname (a hostname with no period in its name) that resolves to the IP address of the Layer 3 interface on the firewall to which the firewall will redirect requests.
If you use Captive Portal without the other User-ID functions (user mapping and group mapping), you don’t need to configure a User-ID agent.
Configure Captive Portal Using the PAN-OS Integrated User-ID Agent
Configure the interfaces that the firewall will use for redirecting web requests, authenticating users, and communicating with directory servers to map usernames to IP addresses. The firewall uses the management (MGT) interface for all these functions by default, but you can configure other interfaces. In redirect mode, you must use a Layer 3 interface for redirecting requests. ( MGT interface only ) Select Device > Setup > Management, edit the Management Interface Settings, select the User-ID check box, and click OK. ( Non-MGT interface only ) Assign an Interface Management profile to the Layer 3 interface that the firewall will use to redirect web requests and communicate with directory servers. You must enable Response Pages and User-ID in the Interface Management profile. ( Non-MGT interface only ) Configure a service route for the interface that the firewall will use to authenticate users. If the firewall has more than one virtual system (vsys), the service route can be global or vsys-specific. The services must include LDAP and potentially the following: Kerberos, RADIUS, or TACACS+ —Configure a service route for one of these services only if you will use it for external authentication. UID Agent —Configure this service only if you will enable NT LAN Manager (NTLM) authentication or if you will Enable User- and Group-Based Policy. ( Redirect mode only ) Create a DNS address (A) record that maps the IP address on the Layer 3 interface to the redirect host. If you will use Kerberos SSO, you must also add a DNS pointer (PTR) record that performs the same mapping. If your network doesn’t support access to the directory servers from any firewall interface, you must Configure User Mapping Using the Windows User-ID Agent.
Make sure Domain Name System (DNS) is configured to resolve your domain controller addresses. To verify proper resolution, ping the server FQDN. For example: admin@PA-200> ping host dc1.acme.com
Create a Kerberos keytab for the redirect host. Required for Kerberos SSO authentication. Create a Kerberos keytab. A keytab is a file that contains Kerberos account information (principal name and hashed password) for the redirect host (the firewall). To support Kerberos SSO, your network must have a Kerberos infrastructure, including a key distribution center (KDC) with an authentication server and ticket granting service.
Configure clients to trust Captive Portal certificates. Required for redirect mode—to transparently redirect users without displaying certificate errors. You can generate a self-signed certificate or import a certificate that an external certificate authority (CA) signed. To use a self-signed certificate, create a root CA certificate and use it to sign the certificate you will use for Captive Portal: Select Device > Certificate Management > Certificates > Device Certificates. Create a Self-Signed Root CA Certificate or import a CA certificate (see Import a Certificate and Private Key). Generate a Certificate to use for Captive Portal. Be sure to configure the following fields: Common Name —Enter the DNS name of the intranet host for the Layer 3 interface. Signed By —Select the CA certificate you just created or imported. Certificate Attributes—Click Add, for the Type select IP and, for the Value, enter the IP address of the Layer 3 interface to which the firewall will redirect requests. Configure an SSL/TLS Service Profile. Assign the Captive Portal certificate you just created to the profile. Configure clients to trust the certificate: Export the CA certificate you created or imported. Import the certificate as a trusted root CA into all client browsers, either by manually configuring the browser or by adding the certificate to the trusted roots in an Active Directory (AD) Group Policy Object (GPO).
Configure an authentication server profile. Required for external authentication. If you enable Kerberos SSO or NTLM authentication, the firewall uses the external service only if those methods fail. As a best practice, choose Kerberos transparent authentication over NTLM authentication. Kerberos is a stronger, more robust authentication method than NTLM and it does not require the firewall to have an administrative account to join the domain. Configure a RADIUS Server Profile. Configure a TACACS+ Server Profile Configure an LDAP Server Profile Configure a Kerberos Server Profile The PAN-OS web server timeout (default is 3 seconds) must be the same as or greater than the server profile timeout multiplied by the number of servers in the profile. For RADIUS and TACACS+, the default server profile Timeout is 3 seconds. For LDAP, the timeout is the total of the Bind Timeout (default is 30 seconds) and Search Timeout (default is 30 seconds) for each server. For Kerberos, the non-configurable timeout can take up to 17 seconds for each server. Also, the Captive Portal session timeout (default is 30 seconds) must be greater than the web server timeout. To change the web server timeout, enter the following firewall CLI command, where < value > is 3-30 seconds: set deviceconfig setting l3-service timeout <value> . To change the Captive Portal session timeout, select Device > Setup > Session, edit the Session Timeouts, and enter a new Captive Portal value in seconds (range is 1-1,599,999). Keep in mind that the more you raise the web server and Captive Portal session timeouts, the slower Captive Portal will respond to users.
Add an authentication profile The profile defines the authentication methods to use (Kerberos SSO, external service, or local database) when a Captive Portal rule invokes Web Form authentication. Even if you enable NTLM, you must define a secondary authentication method in case NTLM authentication fails or the User-ID agent doesn’t support NTLM. If you set the authentication Type to RADIUS, specify a RADIUS User Domain in case users don’t enter the domain at login. Configure an authentication profile: If the authentication Type is an external service ( RADIUS, TACACS+, LDAP, or Kerberos), select the authentication Server Profile you created. If you use Kerberos SSO, enter the Kerberos Realm (usually the DNS domain of the users, except that the realm is uppercase), and import the Kerberos Keytab you created. Select Advanced and Add the users and user groups that can authenticate using this profile. If the authentication Type is Local Database, add the Captive Portal users or user groups you created. You can select all to allow every user to authenticate. After completing the Allow List, click OK. If your users are in multiple domains or Kerberos realms, you can create an authentication profile for each domain or realm, assign all the profiles to the authentication sequence, and assign the sequence to the Captive Portal configuration.
(Optional) Configure Client Certificate Authentication. You don’t need an authentication profile or sequence for client certificate authentication. If you configure both an authentication profile/sequence and certificate authentication, users must authenticate using both. Use a root CA certificate to generate a client certificate for each user who will authenticate to Captive Portal. The CA in this case is usually your enterprise CA, not the firewall. Export the CA certificate in PEM format to a system that the firewall can access. Import the CA certificate onto the firewall: see Import a Certificate and Private Key. After the import, click the imported certificate, select Trusted Root CA, and click OK. Configure a Certificate Profile. In the Username Field drop-down, select the certificate field that contains the user identity information. In the CA Certificates list, click Add and select the CA certificate you just imported.
(Optional) Enable NT LAN Manager (NTLM) authentication. As a best practice, choose Kerberos transparent authentication over NTLM authentication. Kerberos is a stronger, more robust authentication method than NTLM and it does not require the firewall to have an administrative account to join the domain. If you do configure NTLM, the PAN-OS integrated User-ID agent must be able to successfully resolve the DNS name of your domain controller to join the domain. If you haven’t already done so, Create a Dedicated Service Account for the User-ID Agent. Select Device > User Identification > User Mapping and edit the Palo Alto Networks User ID Agent Setup section. On the NTLM tab, select the Enable NTLM authentication processing check box. Enter the NTLM Domain against which the User-ID agent on the firewall will check NTLM credentials. In the Admin User Name, Password, and Confirm Password fields, enter the username and password of the Active Directory account you created for the User-ID agent. Do not include the domain in the Admin User Name field. Otherwise, the firewall will fail to join the domain. Palo Alto Networks recommends that you use a User-ID agent account that is separate from your firewall administrator account. Click OK.
Configure the Captive Portal settings. Select Device > User Identification > Captive Portal Settings and edit the settings. Make sure the Enable Captive Portal check box is selected. Select the SSL/TLS Service Profile you created for redirect requests over TLS. Select the Mode (in this example, Redirect). ( Redirect mode only ) Specify the Redirect Host name that resolves to the IP address of the Layer 3 interface for redirected requests. If users authenticate through Kerberos single sign-on (SSO), the Redirect Host must be the same as the hostname specified in the Kerberos keytab. Select the authentication method to use if NTLM fails (or if you don’t use NTLM): To use Kerberos SSO, an external server, or the local database, select the Authentication Profile or authentication sequence you created. To use client certificate authentication, select the Certificate Profile you created. Click OK and Commit to save the Captive Portal configuration.

Related Documentation