4.1 Identity Awareness Overview

What Identity Awareness Is

Identity Awareness is a Check Point software blade enabled on the Security Gateway that lets you write access control and threat prevention policy based on users, groups, and machines in addition to IP addresses. Without Identity Awareness, a rule can only say "allow 10.0.0.5 to reach the web server." With Identity Awareness, a rule can say "allow members of the CORP\HR-Admins Active Directory group to reach Finance servers, regardless of which laptop or IP they sit at." That shift from network identity to user/machine identity is the core of identity-based policy.

Why Identity-Based Policy Matters

Several real-world problems push administrators to adopt identity-based policy:

• Mobility. Users move between wired, wireless, and VPN subnets. IP-based rules become stale the moment a user roams. Identity follows the user, not the lease.
• Shared IPs. NAT, DHCP, and terminal-server sessions hide many users behind one IP. Identity Awareness disambiguates which user is behind a connection.
• Compliance and incident response. Logs that include usernames are far more actionable than logs with bare IPs. Most audit frameworks now expect user attribution.
• Granular threat prevention. You can apply stricter IPS, Anti-Bot, or Threat Emulation profiles to contractors, guests, or specific groups than to employees, instead of treating every internal IP identically.
• Zero-trust alignment. Modern security postures ask "who" before "what" and "where." Identity Awareness is the gateway-side mechanism that answers "who."

Sources of Identity in R82

Check Point supports multiple methods to acquire identity, each suited to different environments. The four primary sources examined in this chapter are:

1. Active Directory Query (AD Query). The gateway queries AD domain controllers for the IP-to-user mapping that AD records when users authenticate via Kerberos. No agent on endpoints, no client software. Best for domain-joined Windows environments.
2. Identity Collector. A Windows service that aggregates identity from multiple sources (AD Query, RADIUS accounting, Syslog parsers, Identity Agents, and more) and pushes consolidated mappings to one or more gateways. Scales better than per-gateway AD Query and supports non-AD sources.
3. Identity Agent. Lightweight endpoint software (Windows, macOS, Linux) that reports the logged-in user and machine identity directly to the gateway over a secure channel. Most accurate for endpoints that move between networks.
4. Captive Portal. For users who cannot be identified by any of the above (guests, non-domain machines, unmanaged devices), the gateway intercepts HTTP(S) and presents an authentication page. The user enters credentials checked against AD, RADIUS, or a local database, and the gateway maps the session IP to that user.

Additional feeds include RADIUS accounting (common for remote-access VPN) and Syslog parsers that ingest identity events from third-party systems.

How the Gateway Uses Identity

Each source feeds mappings into the gateway's identity cache. Each entry has a Time-To-Live (TTL) and a confidence level. When a new connection matches an Access Role in policy, the gateway looks up the source IP in the identity cache. If a mapping exists, the rule evaluates against the user/group/machine. If no mapping exists and a Captive Portal is configured, the gateway can redirect the user to authenticate on-demand, after which the mapping is cached.

Identity is per-gateway: each gateway in a cluster maintains its own cache unless Identity Collector centralizes the feed. Identity is not retroactive: a session that began before the mapping was learned is not re-evaluated. The mapping applies only to connections that start after it is known.

Access Roles

An Access Role is the policy object that combines identity with network and session criteria. Instead of building separate rules for "HR users from corporate Wi-Fi" and "HR users from VPN," a single Access Role can match:

• Users / Groups: CORP\HR-Admins
• Networks: Corporate-Wi-Fi OR VPN-Pool
• Machines: CORP\HR-Laptops
• Sessions: only when the authentication method is Captive Portal or Identity Agent

At rule-evaluation time the gateway checks the source IP against the identity cache and the network/machine/session fields against the corresponding object lists. A connection matches the Access Role only if every populated dimension matches. Empty dimensions are treated as wildcards.

Enabling Identity Awareness

In SmartConsole, enable the Identity Awareness blade on the gateway object (Gateway Properties → Blades → Identity Awareness). Configure the identity sources per gateway. The blade requires a license but is included in the standard bundle on most Quantum gateways. Once enabled, Access Roles become available as matchable objects in the Access Control policy, and Install Policy pushes the configuration to the gateway.

Exam Traps to Remember

• Identity Awareness is enforced on the gateway, not the management server. The management only stores the policy; the gateway holds the live identity cache.
• A user-to-IP mapping is per-gateway; each gateway queries independently unless Identity Collector centralizes the feed.
• Identity is not retroactive — existing sessions are not re-evaluated when a mapping appears mid-session.
• "Identity Awareness" is the blade; "Identity Collector" and "Identity Agent" are specific acquisition methods. Do not confuse the three on the exam.
• Captive Portal is both an identity source and a fallback mechanism for unidentified traffic; it is not a replacement for AD Query when you already have domain-joined endpoints.