4.2 Active Directory Query

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:

1. Open the gateway object in SmartConsole and enable the Identity Awareness blade.
2. In the AD Query section, add the domain (or domains) and the DCs to query.
3. Provide the service account credentials the gateway will use to bind to AD.
4. Set the query interval and the mapping TTL.
5. 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.