Captive Portal will interrupt users asking for credentials before being granted with access to a network. For example, a Wi-Fi network in a hotel, hospital, bar… Usually it’s some outdated and rather unstable Captive Portal that’ll steer people away from ever being interested. And I was also a victim of that. Palo Alto’s implementation obviously goes much deeper and plays by the zero-trust’s least privilege principles like MFA (Multi-Factor Authentication) and User-ID to create user-to-IP mappings. Furthermore leveraging the full capabilities of the Next-Generation Firewall.
A use-case scenario would be when a user tries to establish an SSH connection with a server that stores sensitive data. As we all know passwords aren’t secure regardless of their complexity. Additional authentication layers should be added like MFA and restricting unwanted users to authenticate. Eg “Domain\Domain Admins” are allowed to SSH but “Domain\Domain Users” are refused regardless of IP-addressing.
Imagine a security policy configured so that only “Domain\Domain Users” are allowed to access a SMB share and employees want to use their phone to access the share. Asking them to join the domain with their phone obviously isn’t an option. Instead we can do user-to-IP mappings by utilizing the User-ID feature and the Captive Portal on the Palo Alto Firewall. The firewall will map the IP address to a Domain User with access to the SMB share.
Another example is when people prefer to use their laptop (BYOD: Bring Your own Device) over a company provided desktop with domain membership. A computer that is a member of a domain has a lot of restrictions, e.g. the inability to install an application or change some system settings. It’s counter-productive granting domain membership to a BYOD device. There are a number of reasons and advantages to BYOD and BYOA (Bring your own App). But it doesn’t rule out that employees will need their domain credentials to access the company’s resources (e.g. SMB or mail) and captive portal is excellent for mapping IP addresses to their domain username.
Pre-requisites
- Active Directory Domain Controller
- Active Directory Domain Certificates Role for the web-form with a valid certificate
- LDAP Server Profile and User-ID configured
- 30-day Trial Okta.com
- Okta Verify App on iOS/Android and enrolled user
Okta Verify Initial configuration
On the organization’s admin page add the “Okta Verify” application.
Assign users to the application.
Security > Multifactor
Make sure it is active and enable push notification to make life easier because OTP’s can be tedious after a while. Although you still have the option to enter an OTP.
Security > Multifactor > Factor Enrollment
Add a policy so that users are automatically enrolled as they log in.
Security > Authentication > Sign On
Add a policy that will require users to use MFA every time they log in.
Security > API > New Token
Save this token for later when we configure the MFA Server profile on the firewall.
Active Directory Domain Certificates Setup
This step can be skipped if you prefer to use a self-signed certificate to simplify the process. Although it’s good practice if the Active Directory’s Root CA issues the Captive Portal a certificate because domain members automatically trust the root CA.
Next, let’s request a CSR on the Palo Alto firewall for the Captive Portal. The Hostname/DNS Attribute should match the Common Name. So captiveportal.faa.local twice. The physical interface’s IP address of my LAN interface is 192.168.50.254 which I intend to use for the captive portal.
Don’t forget to create the A-record on the domain controller which maps the FQDN to the captive portal’s IP address.
Export the certificate and copy paste the contents in http://<IP-address-DomainController/certsrv (http and not https).
Request a certificate > advanced certificate request > paste the contents of the CSR certificate and make sure to select “Web Server” as template
It has to be in a PEM format (Base 64) and import the downloaded certificate on the firewall.
Let’s hook it up to a SSL/TLS Service Profile that we will later use for the captive portal web-page.
Certificate Profile
First we have to acquire the certificates from okta.com. Just hit F12 on chromium based browsers and import the certificates in a PEM format (Base 64). We need the DigiCert Root CA (top), the Intermediate CA and *.okta.com certificate.
Device > Certificate > Management
Import the certificates
Device > Certificate Management > Certificates Profiles
Add the Root CA and the Intermediate CA.
MFA Server Profile & Authentication Profile
Device > Server Profiles > MFA > Add
Select the Okta Certificate Profile (Root & Intermediate CA). Paste the API token we’ve generated earlier on okta.com’s admin panel. Generate a new API token if lost.
The API Host and the organization has to be the admin URL format. So let’s say your organization URL is “helloworld.okta.com” and the admin URL is “helloworld-admin.okta.com”. Enter the following:
API Host = helloworld-admin.okta.com
Organization = helloworld-admin
Device > Authentication Profile > Add
Enter the sAMAccountName login attribute. Username modifier should be set to “%USERINPUT%@%USERDOMAIN%” which is the user@example.com format.
Select the Okta MFA Server Profile.
Captive Portal Configuration
Device > User Identification > Captive Portal Settings
Select the SSL/TLS Service Profile that contains the webpage’s certificate. Select the LDAP Authentication profile. It has to be set to redirect mode and enter the captive portal’s FQDN.
Authentication Enforcement
Objects > Authentication > Add
Select web-form as Authentication method and the LDAP with MFA authentication profile. The other no-captive-portal authentication method will be explained when we get to configuring our authentication policies.
Select your desires sources, addresses, users and destination zones/addresses and the services (PA’s terminology for protocols). Select the Authentication enforcement we made a moment ago.
So let’s say there’s some stubborn user who doesn’t want to authenticate for any reason. Create a new Authentication Enforcement with “no-captive-portal” as the method. Then just simply make a new Authentication policy, select that Authentication Enforcement and make sure this policy is set above the rule that requires authentication.
Interface Management Profile
Network > Network Profiles > Interface Mgmt
Enable User-ID so ip-user-mapping will work and Response-pages so that the web-page will pop up.
Attach it to a physical interface.
Enable User-ID for your security zones.
Conclusion
The portal should look something like this if everything went well.
In the CLI the following command will show users that have successfully authenticated:
show user ip-user-mapping all type CP
To force a user to reauthenticate:
debug user-id reset captive-portal ip-address <ip-address>