4.2 Active Directory Query

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

4.2 Active Directory Query

Key Takeaways Explain This Topic AI

AD Query lets a Security Gateway query Active Directory domain controllers for the IP-to-user mappings that AD records during Kerberos authentication, with no agent on endpoints.

The gateway must be a member of the domain or a trusted domain; it binds to AD over LDAP/LDAPS and pulls the Security Event Log mapping data.

AD Query works only for domain-joined Windows endpoints that authenticate with Kerberos; non-domain devices, macOS, and Linux clients are not identified this way.

Mapping TTL and the query interval are tunable; stale mappings are aged out and re-queried as users log on, log off, or roam.

AD Query is per-gateway; for large or multi-domain deployments, Identity Collector centralizes the feed instead of enabling AD Query on each gateway.

Last updated: July 2026

How AD Query Works

Active Directory Query (AD Query) is the simplest Identity Awareness source for environments where endpoints are domain-joined Windows machines. When a user logs into Windows with a domain account, the workstation obtains a Kerberos ticket-granting ticket from a Domain Controller. That ticket request is logged by the DC and includes the user's source IP. The Check Point gateway periodically queries the DC for these IP-to-user mappings and caches them.

The mechanism is agentless from the endpoint's perspective — no client software is installed on user workstations. The only configuration is on the gateway and on the domain controller side.

Prerequisites

AD Query requires the following:

The gateway must be able to reach the domain controller(s) on the required ports.

A service account in AD with permission to read the Security Event Log on the DC (the gateway uses this account to bind and query).

LDAP or LDAPS connectivity to the DC (port 389 or 636) and access to the Security Event Log, typically via the Remote Event Log Management RPC ports.

The gateway object in SmartConsole must have the Identity Awareness blade enabled and AD Query selected as an identity source.

The gateway must be joined to or trusted by the domain whose users you want to identify.

What AD Query Identifies

AD Query identifies domain users on domain-joined Windows machines . Each mapping records:

The user's domain and sAMAccountName (for example, CORP\jdoe ).

The source IP the user authenticated from.

A timestamp for aging and TTL handling.

The machine account when available, allowing machine-based Access Role matching in addition to user-based matching.

Mappings enter the gateway identity cache with a configurable Time-To-Live. As long as the user keeps refreshing the Kerberos TGT (which Windows does automatically by default), the DC keeps recording fresh ticket requests and the gateway keeps refreshing the mapping. When the user logs off, the mapping ages out after the TTL expires.

Where AD Query Falls Short

AD Query is reliable for the case it was designed for but has well-known limits:

Non-Windows endpoints. macOS, Linux, and mobile devices do not authenticate to AD with Kerberos in the same way, so AD Query cannot identify them.

Non-domain-joined machines. Contractor laptops, personal devices, and guests never authenticate to the domain and produce no mapping.

Terminal-server / VDI hosts. Many users share one IP behind an RDSH or VDI broker. AD Query sees the broker IP, not the individual users.

Roaming between DCs. In large multidomain forests, mappings may live on a DC the gateway is not querying, leading to gaps.

Per-gateway load. Each gateway queries its DCs independently. In a large deployment with many gateways, that is duplicate load on AD and extra management effort.

Event log sizing. If the DC's Security Event Log is too small or wraps quickly, mappings can be missed. AD Query depends on those log entries persisting long enough to be read.

These limits are the main reason Identity Collector exists — it centralizes the query and adds non-AD sources (RADIUS, Syslog, Identity Agents) so a single feed reaches all gateways.

Configuration in SmartConsole

To enable AD Query:

Open the gateway object in SmartConsole and enable the Identity Awareness blade.

In the AD Query section, add the domain (or domains) and the DCs to query.

Provide the service account credentials the gateway will use to bind to AD.

Set the query interval and the mapping TTL.

Install policy.

The gateway validates the bind and begins querying on the configured interval. Identity appears in logs (the "User" column in SmartView) once mappings are populated.

Operational Checks

Useful CLI checks on the gateway:

pdp monitor and pdp monitor show to view the current identity cache and per-source statistics.

pdp control to start, stop, or restart the PDP (Policy Decision Point) process that holds the cache.

adlog a query (in expert mode) to test the AD bind and verify the gateway can read the Security Event Log.

If the bind fails or the service account lacks permissions, mappings never populate and Access Roles that reference users silently fall back to no match.

Tuning and Sizing

Two parameters dominate AD Query behavior:

Query interval — how often the gateway polls the DC for new mappings. Shorter intervals catch logons faster but add DC load.

Mapping TTL — how long a cached mapping stays valid without a refresh. Longer TTLs tolerate DC slowness but increase the window during which a logged-off user's IP can still be matched.

Typical practice is a query interval of a few minutes and a TTL in the tens of minutes. The DC's Security Event Log must be large enough to retain Kerberos ticket events between queries; if the log wraps between polls, mappings are lost. In large environments, raising the log size and using Identity Collector to centralize the query is the standard fix.

Exam Traps

AD Query identifies domain users on domain-joined Windows endpoints . The exam frequently tests the negative: it does not identify macOS, Linux, guests, or non-domain devices.

AD Query is per-gateway. To share one identity feed across many gateways, use Identity Collector.

AD Query depends on Kerberos authentication. Environments that authenticate users with NTLM only or with cloud-only identities (Azure AD without hybrid Kerberos) will not produce mappings.

AD Query requires a service account with Security Event Log read rights, not just plain domain-user rights. This is a common configuration question.

AD Query needs LDAP/LDAPS to the DC plus the Remote Event Log Management RPC ports; opening only LDAP is not sufficient.