Guide
Identity-Based Firewall Policy: Users, Not Subnets
An identity-based rule names a person or a group where an ordinary rule names an address — and the interesting engineering is in how the firewall learns which is which.
A firewall rule that says “the finance group may reach the ERP servers” makes a claim no packet can verify on its own. Packets carry addresses, not usernames. Identity-based firewall policy is the machinery that closes that gap: the firewall maintains a mapping from addresses to authenticated users, and access control rules written in terms of users and groups are enforced by consulting that mapping when a connection arrives. On Cisco Secure Firewall, that machinery centers on the identity policy — associated with the access control policy, and deciding for the traffic it matches how identity gets established before user conditions can match — alongside sources like remote access VPN that supply mappings on their own.
The payoff is policy that survives the network changing underneath it. DHCP hands out a different address after the weekend; a laptop moves from a desk to a conference room; a subnet is renumbered in a migration. An address-based rule tracks none of that. A user-based rule does not care, because the thing it names — the account in the directory — is stable, and the mapping underneath is refreshed as long as an identity source witnesses the user’s next authentication at the new address. The audit story improves for the same reason: a rule that names a group reads as intent, where a list of subnets reads as archaeology.
Realms: Teaching the Firewall Your Directory
Before a rule can name a user, the Management Center has to know your users exist. A realm is the configured connection to a directory such as Active Directory: credentials, directory servers, and the containers to search. From the realm, the Management Center downloads users and groups, which is what makes them selectable in rule conditions — and it is the download that matters here. The realm gives the firewall the vocabulary of identities; it does not, by itself, tell the firewall who is behind any address. That second job belongs to the identity sources.
Passive and Active Authentication
The identity policy contains rules, and each rule applies one of three actions to the traffic it matches: passive authentication, active authentication, or no authentication.
Passive authentication is the workhorse. The firewall never challenges the user; it learns the user-to-address mapping from an external source that already witnessed a real authentication. Cisco ISE or its purpose-built subset ISE-PIC publishes session data over pxGrid as users authenticate to the network. The Terminal Services Agent reports users on terminal servers. In both, identity arrives as a byproduct of authentication that was happening anyway — no user experience cost, no new prompt.
Active authentication means the firewall establishes identity by authenticating the user itself. A remote access VPN login is one such event — configured with the VPN itself, not through an identity rule: the device terminated the authentication, so the mapping arrives with the tunnel and no further challenge is needed. The captive portal is the action identity policy rules invoke directly: the firewall challenges the user over web traffic it can redirect, and applies the resulting identity to the source address. That mechanism bounds its reach — it identifies users who lack a mapping only when they produce web traffic the portal can intercept — and a passive identity rule can fall back to it, where that option is enabled, for exactly those connections. The candidates are the endpoints passive sources cannot see — unmanaged devices, guests on a segment without 802.1X — and the coverage is visible by nature: users meet a login page, which is friction you deploy deliberately, not by default.
No authentication is the explicit opt-out for traffic where identity is meaningless — server-to-server flows, infrastructure protocols — a rule that tells the device not to attempt to establish identity for what it matches, rather than leaving that outcome to chance.
Where Attribution Breaks
Ordinary IP-based attribution rides on one assumption: an address belongs to one user at a time. Break that assumption and attribution breaks with it. The classic case is a terminal server, where dozens of users share one source address; treating that address as one user would grant everyone the access of whoever authenticated last. The Terminal Services Agent exists precisely for this — it allocates each logged-on user a distinct range of TCP and UDP source ports and reports the port-to-user mapping, so the firewall can distinguish users sharing an address by the ports their connections use. Address translation is the other trap: if source addresses are translated before traffic reaches the enforcement point, distinct users collapse into a single translated address, and attribution ends there. Identity sources have to report mappings on addresses that correspond to what the firewall sees at the enforcement point. And a connection with no mapping at all still needs a decision — write rules with the expectation that unknown users exist, and decide deliberately what they may reach.
Identity conditions slot into the rule structure covered in FMC access control policy design, and the richest passive source is the subject of What Is Cisco ISE. Configuring identity policy in the Management Center sits on the SNCF 300-710 blueprint by name, and it is a topic that rewards lab time — watching a mapping appear, expire, and fail teaches more than any diagram. Start with the first lesson.
Frequently Asked Questions
What is the difference between passive and active authentication?
Passive authentication learns who owns an address from an external source — ISE or ISE-PIC, or the Terminal Services Agent — without the user noticing anything. Active authentication means the firewall authenticates the user itself: a remote access VPN login does this at tunnel setup, and the captive portal does it by challenging the user directly. Passive is the normal choice for managed networks; active covers users that passive sources cannot see.
Do I need Cisco ISE to write user-based firewall rules?
No. A realm connection to your directory plus any supported identity source — the captive portal, the Terminal Services Agent, or remote access VPN identity, each with its own configuration requirements — lets access control rules match users. ISE is the richest passive source, though: it sees authentications as they happen and can also share TrustSec tags and session attributes that plain directory integration cannot provide.
Do identity-based rules replace network-based rules?
No. Identity conditions are added to access control rules alongside zones, networks, ports, and applications, and they depend on a user-to-address mapping existing at match time. Infrastructure traffic, unmanaged devices, and anything without a mapped user still need network-based rules, so a real policy uses both.