A rule that permits an address permits whoever is using that address. In an environment with roaming users, shared machines and , that is a weaker statement than it looks, and Identity Awareness is how it is strengthened.
The problem it solves
The firewall sees addresses. Policy usually wants to talk about people: this department reaches the finance application, contractors do not, administrators reach management interfaces from anywhere.
Identity Awareness supplies the missing mapping — which user is currently at which address — so a rule can reference an identity and the gateway can resolve it at match time.
Access Roles
An Access Role is the object a rule references. It can combine:
- Users or groups, typically from .
- Machines, so a rule can require a corporate computer rather than any device the user logs in from.
- Locations, meaning the networks the connection originates from.
- Remote access clients, where applicable.
Because the conditions combine, an Access Role can express "a member of Finance, on a domain-joined machine, from the office network" as a single object. That combination is where the feature earns its place: identity alone answers who, and the machine and location conditions answer whether the circumstances are right.
Where identities come from
This is the part that determines whether a deployment works well, and the options trade coverage against intrusiveness.
Identity Collector is the usual answer in a Windows environment. A small collector agent runs on a Windows host, subscribes to domain controller security event logs, and forwards login events to the gateway. It scales well because the collector does the talking to the domain controllers, and the gateway receives a stream rather than polling.
Query is the agentless predecessor: the gateway itself queries domain controllers for login events. It requires no additional software, which is its appeal, and it puts the query load on the gateway.
Browser-Based Authentication presents a captive portal. The user authenticates in a browser and the gateway learns the mapping. It covers anyone with a browser, including devices outside the domain, and it is intrusive by design — the user notices.
Identity Agent is software on the endpoint that reports the logged-in user directly. It gives the strongest binding and requires deployment and maintenance.
Terminal Servers need their own handling, because many users share one address. Without a specific mechanism, everyone on a terminal server appears as one identity, and rules cannot distinguish them.
Most real deployments combine sources: a collector for domain machines, and a portal for everything else.
Where identity is applied
The gateway must have Identity Awareness enabled, the identity source configured, and the Access Role used in the policy. Missing any of the three produces a rule that never matches.
Identity can also be shared between gateways, so a user identified at one gateway is known to another without re-authenticating. That matters in a multi-gateway environment and is a configuration step rather than a default.
What goes wrong
The recurring faults, and what they look like:
The rule never matches. Usually the identity is not known to the gateway. Check whether the gateway sees the user before examining the rule.
Identity is stale. A user logged out or moved, but the mapping persists until it times out. A shared machine amplifies this: the previous user's identity may still be attached to the address.
Users appear as unknown. The identity source is not covering them — a non-domain device, an unsupported operating system, or a login the collector never saw because it happened before the collector was watching.
Everyone on a terminal server looks the same. The specific case above, and it needs the specific solution rather than tuning.
The diagnostic order is the same shape as everywhere else on the platform: confirm the gateway knows the identity, then confirm the Access Role resolves it, then look at the rule.
What a CCSA candidate should be able to state cold
Identity Awareness maps users to addresses so a rule can reference an identity. An Access Role combines users or groups, machines, locations and remote access clients into one object. Identity sources include Identity Collector, which forwards domain controller login events and scales well; AD Query, which is agentless and queries from the gateway; Browser-Based Authentication via a captive portal, which covers non-domain devices and is visible to the user; and Identity Agent on the endpoint. Terminal servers need specific handling because users share an address. A rule that never matches usually means the gateway does not know the identity, so verify that before examining the rule.