Firewall user authentication and captive portals: Build identity aware rules users cannot bypass

Firewall rules written against IP addresses stop meaning anything once laptops roam, users share terminal servers and guests join the same subnet, so most next generation firewalls now authenticate the person or device behind the traffic. This guide explains how firewall user authentication works in practice: passive identity mapping, active captive portals, the standards based Captive Portal API, and how each feeds identity aware security rules. It covers the design decisions that decide whether the result is trustworthy, how to roll it out without locking people out, and how to detect abuse of the mappings and the service accounts behind them. It is written for network and identity engineers who run firewalls, wireless and remote access, and assumes the general rule lifecycle covered in the Firewall Management Guide.

Key takeaways

• An identity aware rule is only as good as its mapping. The firewall still sees IP addresses; user rules depend on an IP to user table that can be stale, spoofed or shared, so the mapping source matters more than the rule syntax.
• Prefer authoritative passive sources, use the portal as the fallback. Domain controller and identity provider events, VPN logins and NAC give mappings without user friction; a captive portal catches the devices those sources miss.
• Captive portals are credential collection pages. They need a trusted TLS certificate, a hostname users can recognise, MFA where the resource justifies it, and no cleartext methods such as HTTP Basic on untrusted segments.
• The mapping agents are privileged non-human identities. Directory read accounts, WMI probing accounts, RADIUS and LDAP bind credentials and XML API keys live on the firewall and must be scoped, vaulted and rotated like any other service account.
• Timeouts are security controls. Mapping timeouts, portal timers and re-authentication intervals decide how long a stolen or reassigned IP keeps someone else's access.

How firewall user authentication works

Every vendor implements the same three building blocks under different names. A mapping table records which user (and often which groups) currently sits behind an IP address. A group mapping process reads directory groups so rules can reference "Finance" rather than individual names. A policy engine matches traffic to rules that include a user or group column, alongside the usual zones, addresses, applications and services.

Palo Alto Networks documents nine User-ID mapping methods: Server Monitoring, Port Mapping, Syslog, XFF Headers, Username Header Insertion, Authentication Policy and Authentication Portal, GlobalProtect, XML API and Client Probing. Cisco Secure Firewall Management Center groups the same idea into passive identity sources (ISE or ISE-PIC and the TS agent for terminal servers) and active sources (captive portal and remote access VPN), with an identity policy whose rules assign each flow a realm and an authentication method of passive, active or none. Whatever the product, the questions are the same: where does the mapping come from, how fresh is it, and what happens to traffic that has no mapping.

Captive portals: modes, methods and the standards

A captive portal intercepts traffic from an unauthenticated device and redirects it to a login or acceptance page. In an enterprise firewall this is an authentication portal that adds a mapping once the user signs in. On guest and public networks it is usually a venue portal that collects acceptance of terms, a voucher or payment before releasing the device.

Authentication methods

• Web form: the portal page collects a username and password, then hands off to further factors. In PAN-OS the Authentication Portal web form is the first factor and additional factors (push, OTP, SMS, voice) are presented on a separate MFA login page, after which Security policy decides access.
• Transparent Kerberos or Negotiate: domain joined browsers authenticate silently with Kerberos tickets. Cisco's HTTP Negotiate option lets the portal choose Kerberos, NTLM or Basic, and Kerberos requires a directory join account on the realm. This is the least friction option, but it inherits Kerberos hygiene: a protected service principal and a rotated keytab. See the Kerberos Security Guide.
• NTLM: transparent for configured browsers on Active Directory realms, but NTLM is relayable and on a deprecation path. Treat it as a migration item. See the NTLM Deprecation and Elimination Guide.
• HTTP Basic: Cisco's documentation describes it as unencrypted, with users logging in through the browser pop-up. Never offer it without TLS, and avoid it on any segment an attacker can sniff.
• SAML or OIDC single sign-on: the portal redirects to the corporate identity provider, which enforces MFA and conditional access centrally. This keeps passwords off the firewall entirely and is the preferred option when the firewall supports it. See the Identity Provider and SSO Security Guide.

The IETF Captive Portal API

Classic portals rely on intercepting HTTP and redirecting the browser, which breaks with HTTPS everywhere, HSTS and operating system captive network assistants. The IETF CAPPORT work replaces interception with discovery. RFC 8910 (Standards Track) defines DHCP, DHCPv6 and Router Advertisement options that tell the device the API URI. RFC 8908 (Standards Track) defines the API: a JSON document of media type application/captive+json with a required captive boolean and optional user-portal-url, venue-info-url, can-extend-session, seconds-remaining and bytes-remaining. RFC 8952 (Informational) describes the architecture: user equipment, provisioning service, API server, enforcement device and user portal.

The security requirements are worth adopting even on proprietary portals. RFC 8908 requires TLS for all client to API traffic, a certificate the client can validate and check for revocation, and a name that matches the hostname the network supplied; if validation fails the client must not use the API. It recommends OCSP stapling, allowing revocation and time services through the enforcement device, and marking responses private or no-store. RFC 8952 adds that signals are only hints and should be rate limited, and that IP based identifiers need anti-spoofing because they can be forged.

Designing identity aware rules

• Use groups, not users: reference directory groups in rules and manage membership in the identity system, so leavers lose network access when their account is disabled, not when someone edits the firewall.
• Decide the unknown user behaviour explicitly: every product has a pseudo identity for unmapped traffic ("unknown", "Unknown" users in Cisco realm sequences, or a guest identity). Write a rule for it on purpose: redirect to the portal for web, deny for sensitive zones, and allow only infrastructure services such as DNS, DHCP and the portal itself.
• Keep identity out of infrastructure rules: domain controllers, NAC, DNS and the portal must be reachable before anyone is mapped, otherwise users cannot authenticate to become mapped.
• Separate servers from people: servers, printers, IoT and workloads do not log in through a portal. Give them address or tag based rules and keep them out of user mappings so a service logon cannot overwrite a human mapping. Machine identities should be governed as non-human identities, see the Network Access Control (NAC) Guide for device level identity.
• Combine identity with application and zone: "Finance group may use the payroll application from the corporate zone" is a far smaller grant than "Finance group may reach the payroll subnet".
• Re-authenticate for sensitive targets: put an authentication rule with MFA in front of admin interfaces, jump hosts and payment systems, with a short timeout, rather than relying on the mapping created at morning logon.

Timeouts that matter

Where identity fits: the service accounts behind the firewall

User aware firewalls quietly accumulate some of the most sensitive non-human identities on the network. Each one can either read the directory, write mappings or authenticate as the firewall.

• Directory read and event log accounts: agents that read domain controller security logs need membership of a log reader role, not Domain Admins. Check for legacy agents installed years ago under an administrator account.
• Client probing accounts: Palo Alto Networks "strongly recommends disabling client probing" and warns that enabling it on external, untrusted interfaces could send the User-ID agent's service account credentials outside the network. If you still use it, restrict it to trusted zones and plan its removal.
• LDAP, RADIUS and TACACS+ bind secrets: stored in the firewall configuration and in its backups. The SonicWall SSL VPN account compromises showed why: after cloud configuration backups were exposed, the advice extended beyond user password resets to rotating these bind credentials, pre-shared keys and API keys. See the RADIUS Security Guide.
• Mapping API keys: an XML or REST API key that can post mappings can make any IP look like any user. Scope it to the mapping function, restrict source addresses, and alert on mappings from unexpected senders.
• Kerberos service principal and keytab: used for transparent portal authentication. Use a long random password or managed account, set an owner and rotate it.

Choosing an approach

Large organisations should treat the firewall as a consumer of identity, not a source: feed it from NAC, the identity provider and VPN, redistribute mappings between firewalls (PAN-OS offers Redistribute User Mappings and Authentication Timestamps so all firewalls enforce timeouts consistently), and keep group mapping in one place. Small organisations gain most from putting MFA in front of remote access and admin interfaces and keeping guest traffic on its own segment. Where the goal is per application access for remote users, a ZTNA broker may be a better fit than user rules on a perimeter firewall; see the ZTNA Guide.

How to implement

1. Inventory traffic and sources: list the zones where you want user rules, the identity sources that already see those users (domain controllers, NAC, VPN, proxies), and the devices that never log in.
2. Create the service accounts properly: least privilege directory accounts, vaulted secrets, named owners, and a rotation date. Disable client probing unless there is no alternative.
3. Enable passive mapping in monitor mode: turn on mapping and group sync, then compare mappings with DHCP and NAC records for two weeks to measure coverage and wrong user mappings before any rule depends on them.
4. Build the portal: a dedicated hostname, a publicly trusted or enterprise trusted certificate, SSO through the identity provider where possible, and no HTTP Basic. Exempt infrastructure and non-browser devices.
5. Add log only user rules: clone existing address rules with a user or group column and log hits, so you can see who would lose access.
6. Pilot one zone: start with a single office or SSID, with the helpdesk briefed and a documented bypass rule that can be enabled in one change.
7. Enforce and tighten: move to deny for unknown users in sensitive zones, add MFA authentication rules for admin targets, and shorten timeouts on shared segments.
8. Roll back cleanly: keep the previous address based rule set disabled but present for the first change window; rollback is enabling it and disabling the identity rules, not rebuilding policy under pressure.

Detection and measurement

• Authentication and mapping logs: PAN-OS writes an Authentication log entry for each request matching an Authentication rule and User-ID logs for mappings; equivalent logs exist on other platforms. Forward them to the SIEM alongside VPN and identity provider sign-in logs. The VPN and Firewall Log Detection Guide covers parsing.
• Spraying against the portal: many failed portal logins across many usernames from one source match Password Spraying (T1110.003); bursts of successes from one address across many accounts suggest stolen Valid Accounts (T1078).
• Mapping anomalies: one IP flipping between users within minutes, a privileged user mapped to a guest subnet, or mappings arriving from a sender that is not an approved agent.
• Rogue portals: look for lookalike portal hostnames and certificates on guest networks, a common Adversary-in-the-Middle (T1557) setup for harvesting credentials.

Metrics that show it is working:

• Mapping coverage: percentage of traffic in identity enforced zones with a known user (target above 95 percent).
• Rules with a user or group condition as a share of rules in those zones.
• Portal authentication failure rate and number of helpdesk tickets per week after go-live.
• Median mapping age on shared and guest segments.
• Number of firewall held service accounts with an owner and a rotation date inside policy.

Framework mapping

Common failure patterns

• Stale mappings on Wi-Fi: a mapping timeout far longer than the DHCP lease lets the next device on that address inherit the previous user's access.
• Service logons overwriting people: backup agents, monitoring tools or admins connecting from a jump host generate logon events that remap a workstation or server IP to a service account or a different user.
• Portal on HTTP or a self-signed certificate: users learn to click through warnings, which is exactly what a rogue portal needs.
• Over-privileged agent accounts: User-ID or FSSO style agents running as domain administrators, or client probing left on, turning the firewall integration into a credential exposure.
• Bind secrets never rotated: LDAP and RADIUS credentials set at install time, copied into every configuration backup, and forgotten, as the SonicWall case illustrated.
• Unknown users allowed by default: a catch-all rule permitting unmapped traffic quietly undoes every identity rule above it.

Practitioner checklist

• Document every mapping source per zone and measure coverage before enforcing.
• Disable client probing, or restrict it to trusted zones with a removal date.
• Run all agent, bind and API accounts with least privilege, vaulted secrets, owners and rotation.
• Serve the portal on a dedicated hostname with a trusted certificate, SSO and MFA; remove HTTP Basic.
• Write an explicit rule for unknown users in every zone.
• Align mapping timeouts with DHCP leases and shorten them on shared segments.
• Put MFA authentication rules with short timeouts in front of admin and high value targets.
• Forward authentication and mapping logs to the SIEM and alert on spraying and mapping anomalies.
• Keep a tested rollback rule set for the first enforcement window.

Standards and references

• IETF: RFC 8908 Captive Portal API
• IETF: RFC 8952 Captive Portal Architecture
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• Palo Alto Networks: Authentication Policy
• Palo Alto Networks: Client Probing
• Cisco: Secure Firewall Management Center Identity Policies
• Microsoft: Event 4624 An account was successfully logged on

Related NHI Mgmt Group resources: Firewall Management Guide · Network Access Control (NAC) Guide · RADIUS Security Guide · 802.1X and EAP-TLS Enterprise Wi-Fi Guide · ZTNA Guide