4.4 Identity Agent

What Identity Agent Is

Identity Agent is lightweight endpoint software, available for Windows, macOS, and Linux, that runs as a background service and reports the currently logged-in user and the machine identity directly to a Check Point Security Gateway or to Identity Collector. It is the most accurate of the agent-based identity sources because the agent observes logon and logoff events locally and pushes updates as they happen, rather than waiting for the gateway to query a domain controller and infer mappings from Kerberos activity.

How Identity Agent Reports Identity

The agent runs in the background after installation. On user logon, logoff, switch, lock, or session change, the agent sends an update to its configured destination. The reported payload typically includes:

• The user's domain and username (for example, CORP\jdoe).
• The machine account name.
• The source IP(s) the endpoint currently holds.
• A timestamp and the event type (logon, logoff, lock, unlock).

The receiving gateway or collector stores the mapping in the identity cache. Because the agent pushes updates on session changes, roaming between subnets, VPN connect/disconnect, and fast user switching are reflected in near real time, which is the agent's main advantage over AD Query.

Where Identity Agent Is Strongest

• Roaming laptops. A user who moves from wired Ethernet to Wi-Fi to VPN keeps the same identity, but the IP changes. AD Query can lag until the next Kerberos TGT renewal; Identity Agent pushes the new IP-to-user mapping immediately.
• Frequent session changes. Fast user switching, RDP into a workstation, and lock/unlock events are all reported, keeping the cache accurate.
• Mixed-OS environments. macOS and Linux endpoints that are not domain-joined (or that authenticate to AD in ways AD Query cannot observe) can still be identified if they run the agent.
• Multi-gateway environments through Identity Collector. Agents report to Identity Collector, which fans the feed out to every gateway, so the same mapping is visible everywhere.

Where Identity Agent Falls Short

• Unmanaged devices. The agent must be installed with administrative privileges. Guests, contractors with personal laptops, and BYOD mobile devices cannot run it.
• Deployment overhead. Rolling out, updating, and monitoring an agent on every endpoint is operational work; some shops prefer agentless AD Query when it is good enough.
• Terminal servers and VDI. On a multi-user RDSH host, the agent reports all logged-in users but the source IP is shared. Identity Collector and Access Roles handle multi-user IPs, but the agent alone does not solve that case.
• Agent software lifecycle. The agent must be kept current with the gateway version; mismatches can cause reporting failures that look like silent identity loss.

Configuration

The agent is configured with:

• The destination address (a gateway or Identity Collector) and the port over which it reports.
• A shared secret or certificate that authenticates the agent to the destination.
• The identity sources it should report (typically the logged-in user and the machine account).

On the receiving side, the gateway or collector must be configured to accept agent connections and trust the credentials. In SmartConsole, the gateway's Identity Awareness configuration offers Identity Agent as a source; the matching configuration on the agent and the gateway must use the same shared secret.

Agent and AD Query Together

A common production design is to run both AD Query and Identity Agent:

• AD Query covers domain-joined desktops that never move.
• Identity Agent covers roaming laptops, macOS, and Linux endpoints.
• Captive Portal covers the remaining unidentified traffic (guests, BYOD).
• Identity Collector aggregates all three and pushes the unified feed to all gateways.

This layered design is what the exam often describes as the "complete" identity solution. Each source covers a gap the others leave.

Operational Verification

On the gateway, pdp monitor shows mappings and indicates the source. Entries delivered through Identity Collector are tagged accordingly; direct agent connections show as Identity Agent. pdp monitor show sources reports counters per source, useful for confirming that agents are actively reporting.

If an agent stops reporting (host reboot, network loss, software crash), the mapping on the gateway ages out per TTL. If the agent resumes before the TTL expires, the mapping is refreshed; otherwise, the IP becomes unidentified until the next report or until Captive Portal reauthenticates the user.

Deployment Considerations

Rolling out Identity Agent at scale is an endpoint-management exercise, not just a firewall configuration. Typical practices include:

• Distribution via MDM or endpoint management (Microsoft Intune, SCCM, Jamf, Ansible) rather than manual install.
• Version alignment with the gateway release; major R82 upgrades usually require an agent update to keep reporting reliable.
• Excluding multi-user RDSH hosts where the source IP is shared, unless Identity Collector is in place to handle multi-user mapping.
• Monitoring agent health through the gateway's per-source counters; a silent agent is worse than no agent because the rulebase assumes identity is present.

Because of the deployment overhead, Identity Agent is usually reserved for managed endpoints where the accuracy gain justifies the work — roaming laptops, executive machines, and developer workstations that move between networks.

Exam Traps

• Identity Agent is the most accurate source for roaming endpoints because it pushes updates on session changes. AD Query depends on periodic DC queries and Kerberos renewals.
• Identity Agent requires administrative installation, so it is not for guest or BYOD devices. The exam pairs "unmanaged device" with "use Captive Portal," not "use Identity Agent."
• Identity Agent can report to Identity Collector, which is the recommended pattern for multi-gateway deployments.
• Identity Agent does not replace Identity Awareness or the gateway cache; it is a source feeding the same blade.
• On multi-user RDSH/VDI hosts, the agent alone does not disambiguate users behind one IP; Identity Collector handles that case.