4/22/2014 Identity Awareness AD Query

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301#Abstract 1/5
Print Email
Identity Awareness AD Query
Solution ID: sk60301
Product: Identity Awareness
Version: R75.40VS, R75, R75.20, R75.30, R75.40, R75.10, R75.45, R75.46, R75.47,
R76, R77, R77.10
OS: SecurePlatform 2.6, Windows, Gaia
Platform /
Model:
All
Date Created: 03-Jan-2011
Last Modified: 22-Apr-2014
Rate this document
[1=Worst,5=Best]
SOLUTION
Table of Contents:
Abstract
How AD Query (ADQ) works
Step 1: Communication with the Domain Controllers
Step 2 & 3: Extraction of the user/machine to IP Association and filtering undesirable association
Step 4: Applying the new Association with the user / machine to the IP database
Various applicable scenarios
More about AD Query (ADQ) communication
Security Gateway - Domain Controller communication
SmartDashboard - Domain Controller communication
AD Query (ADQ) Performance Considerations
Effect on the Security Gateway
Effect on the Domain Controllers
Bandwidth between the Security Gateway and the Domain Controllers
Configuring AD Query (ADQ) for more than one Security Gateway
AD Query (ADQ) Command Line interface
AD Query (ADQ) Advanced Configuration Options
Did you know that ...
You can configure AD Query (ADQ) to support non-English names
You can configure each gateway to connect to different Domain Controllers in the same account unit
Identity Logging is now called AD Query


Abstract
AD Query (ADQ) is a clientless identity acquisition method. It is based on Active Directory integration and allows the
Security Gateway to correlate Active Directory Users and machines to IP addresses in a method that is completely
transparent to the user.
When using AD Query (ADQ), the Security Gateway connects to the Active Directory Domain Controllers using WMI,
and subscribes to receive Security Event logs that are generated, by default, on the Domain Controllers, when users
perform login. Using these event logs, the Security Gateway can correlate Active Directory Users and machines to IP
addresses, and to enforce a user based policy.
Note: This article is not a substitute for the Identity Awareness Administration Guide, but rather a more detailed
explanation of the feature and related technology. We strongly suggest reading the Identity Awareness
Administration Guide beforehand.

How AD Query (ADQ) works
The steps in the AD Query example are listed below:
1. The Security Gateway registers to receive Security Event logs from the Active Directory Domain Controllers.
2. A user logs in to a desktop computer using his Active Directory credentials.
3. The Active Directory DC sends the Security Event log to the Security Gateway. The Security Gateway extracts
the user and IP address information (user name@domain, machine name and source IP address).
4. The user initiates a connection to the Internet.
5. The Security Gateway confirms that the user has been identified and allows him to access the Internet, based
on the policy.
Support Center > Search Results > SecureKnowledge Details
Guest Access
Sign In
Live Chat
Start Chat Now
Service Requests
Create Service Request
My Service Requests
Contact Us
STAY UP TO DATE
Get weekly email notifications on
support related updates.
SUGGESTED
SOLUTIONS
People that viewed this solution
also viewed:
1. Check Point R77.10
2. Both FWD and CPD processes
Crash on the Customer
Management Add-on (CMA)
3. Browsers supported to work
with Gaia Portal
Search
Global Sites My Account
4/22/2014 Identity Awareness AD Query
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301#Abstract 2/5
AD Query (ADQ) employs the following four main steps:
1. Communication with the Domain Controllers and subscription for the relevant Security Event logs.
2. Extracting the user and/or machine to IP Association from the Event Log.
3. Filtering undesriable associations.
4. Applying the new Association with the user / machine to the IP database.

Step 1: Communication with the Domain Controllers
After being configured, AD Query (ADQ) begins communication with all of the Domain Controllers in the configured
account unit. The communication is a WMI query (over DCE-RPC), registering to receive all relevant Security Event logs
from the Domain Controller. (For Windows 2003 Domain Controllers, events 672,673 and 674 are fetched, while for
Windows 2008 Domain Controllers events 4624, 4768, 4769 and 4770 are fetched.) From then on, any new relevant
Security Event log will be sent to the Security Gateway, seconds from its creation time. AD Query (ADQ) does pull the
Security Event log from the Active Directory every second (1 second) or the Active Directory pushes the latest 100
events to the Security Gateway that runs AD Query (ADQ).
The registration mechanism allows AD Query (ADQ) to receive new Security Event logs in a timely manner (up to
several seconds from generation time). It does not generate a lot of burden on the Domain Controller, as it already
has the message in its memory, when it is sent to AD Query (ADQ). Real life deployments on running AD environments,
measured up to a 3% increase in CPU usage on the Domain Controllers, with an average of much less than 1%.
Most of the problems with AD Query (ADQ) happen in the communication phase since WMI runs over DCE-RPC, which is
a complicated and non firewall-friendly protocol (it starts on port 135 but later moves on to a dynamically coordinated
port). The first thing that you want to check when AD Query (ADQ) is not working is if something, on the local Security
Gateway, or on the way to the Domain Controller is blocking this traffic. Refer to sk58881 (AD Query traffic dropped by
Check Point Security Gateway), for further details about how to diagnose and handle such problems.

Step 2 & 3: Extraction of the user/machine to IP Association and filtering undesirable association
After AD Query (ADQ) successfully receives a Security Log event, it generates an Association between a user and/or
machine to an IP address. Afterwards, it may be filtered by both Implied and Configured filters.
Implied filters
Implied filters will filter the following Associations:
Associations with an IP address of 127.0.0.1 (meaning, that AD Query (ADQ) will not be able to detect users
working on the Domain Controller itself).
Associations with 'general' user name, such as 'NT Authority\System'.
Associations with an IP address of one of the Check Point Security Gateways. The reason for this filtering is that
Check Point Security Gateways may act as NAT Devices, hiding several IP addresses behind them.

Step 4: Applying the new Association with the user / machine to the IP database
Note: The AD Query (ADQ) "database" is stored in the Kernel Tables. It does not survive reboot / 'cpstop'.
Before discussing the process that happens each time a new association arrives and is applied to the database, we
should note that the database is a mapping between IP address and a list of user and machine names, each of them
with its own expiry time.
For the sake of simplicity, we'll assume that the association includes either user or machine. If this is not the case, the
association is handled as two subsequent associations, one including only the machine and the other one including
the user.

Various applicable scenarios
Various applicable scenarios:
New Association: In case this IP address was unknown before this association, the association is added to the
database with an expiry time of (now + the configured timeout) (by default, the configured timeout is 12 hours).
Existing Association: If this Association for this IP address was known before, the expiry time is updated to
(now + configured timeout) (The configured timeout is 12 hours).
Machine change: If the machine has changed, all of the currently known user associations are revoked, as well
as the current associated machine, and the new machine is added to the database with an expiry time of (now
+ configured timeout).
New User: If an unknown user association is encountered, and "assume one user per IP" is "off" (default), the
new association is added with an expiry time of (now + configured timeout) (The configured timeout is 12
hours).
User Change: If an unknown user association is encountered, and "assume one user per IP" is "on", all of the
currently associated users are revoked, and the new association is added as the only user for this IP address. If
there were any machine associations for this IP address, they are left intact. See "Single User Assumption" in
the Identity Awareness Administration Guide for more information.
4/22/2014 Identity Awareness AD Query
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301#Abstract 3/5
Multi user host detected: If 7 (by default) users are currently associated for the same IP address, the IP
address is automatically considered a "multi user host". A log about it is issued, all of the currently associated
users are revoked and all new user associations for this IP address are ignored.

More about AD Query (ADQ) communication
Security Gateway - Domain Controller communication
In order to configure and use AD Query (ADQ), the Security gateway must have connectivity to the Domain Controllers
via DCE-RPC (port 135, and later a dynamic coordinated port), and LDAP / LDAP over SSL, according to your Domain
Controller configuration. (Note: LDAP over SSL must be configured explicity on your Domain Controllers). Note: DCE-
RPC (the protocol DCOM uses) is not firewall friendly, and can be blocked for various reasons. Refer to sk58881 (AD
Query traffic dropped by Check Point Security Gateway), for more details. If you have a non-Check Point filtering device
between the Security Gateway running AD Query (ADQ) and your Domain Controller, and you have AD Query (ADQ)
communication problems, see the manufacturer's Identity Awareness Administration Guide for instructions about how
to allow this traffic.

SmartDashboard - Domain Controller communication
During the First Time Configuration Wizard
In order for the wizard to be able to configure AD Query (ADQ), it must have connectivity to the Domain Controller. For
this step, connectivity includes both TCP/IP connectivity (i.e., pings) and being able to perform DNS queries for it (i.e.,
running 'nslookup', 'set type=srv', '_ldap._tcp.your_domain.here' succeeds). It is preferable to run it from a computer
that is a Domain Member, since then it can detect and configure all of the Domain Controllers. If you run it from a
computer that is not a Domain Member, only one Domain Controller (that is entered manually) is being configured, and
you will have to enter the rest of them manually.
If you do not have connectivity when running the first time wizard, you will have to create an LDAP account unit
manually for AD Query (ADQ) to work.
When configuring roles
In order to use the picker (when configuring Identity Roles), SmartDashboard must have LDAP connectivity to the
Domain Controllers. If this is not possible, you can still use LDAP groups (created by using SmartDirectory) in access
roles.

AD Query (ADQ) Performance Considerations
Effect on the Security Gateway
The performance impact of this feature on the Security Gateway is close to negligible and may reach up to 5% in peak
cases. Memory consumption at the Security Gateway is approximately the sum of:
10 MB for the feature itself
3 MB per configured Domain Controller
100 bytes per logged in user

Effect on the Domain Controllers
The CPU usage of sending the Security Event log to the Security Gateway is minimal. It ranges from 0 to 3%. This
depends on the amount of authentication events logged on the Domain Controller. According to our testing, the effect
is usually a little bit higher on Domain Controllers running on virtual machines.

Bandwidth between the Security Gateway and the Domain Controllers
The amount of data transferred between the Security Gateway and Domain Controllers depends on the amount of
Security Event logs generated that depends on the amount of authentication events. This amount varies according to
the applications running in the network. Programs that perform a lot of authentication requests will generate a more
logs. In real life scenarios, the observed bandwidth range varied between 0.1 to 0.25 Mbps per each 1000 users.

Configuring AD Query (ADQ) for more than one Security Gateway
In case more than one Security Gateway requires the identity information, it is far more efficent (in terms of CPU usage
and bandwidth) to configure one Security Gateway (preferably the closest) to fetch the information from the Domain
Controller(s). The rest of the Security Gateways will fetch it from that Security Gateway (via "get Identities from other
gateways" option in the Identity Awareness section in the Security Gateway properties).
If you have several Security Gateways and Domain Controllers in different physical sites, it is usually the best
deployment option that one Security Gateway from each physical site will connect to the local site Domain Controllers,
and will fetch the information from all of the other Security Gateways. As the information sharing is done on a "need to
know" basis, you usually don't need to worry about the inter-gateways communication.

AD Query (ADQ) Command Line interface
AD Query (ADQ) has an extensive CLI. This allows you to view and control AD Query (ADQ) status. You can run adlog a
4/22/2014 Identity Awareness AD Query
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301#Abstract 4/5
AD Query (ADQ) has an extensive CLI. This allows you to view and control AD Query (ADQ) status. You can run adlog a
if this is a Security Gateway, or adlog l if this is a Security Management Server / Log Server machine to receive usage
describing the various options.
Some of the useful options are:
'adlog a dc' - Displays a table specifying which Domain Controllers this Security Gateway is connected to, their
connectivity status and the number of events fetched in the last hour
'adlog a query all' (or 'adlog a q a' for short) - Displays all of the identity information currently known by AD
Query (ADQ)
'adlog a query ip 1.1.1.1' (or 'adlog a q i 1.1.1.1' for short) - Displays the information currently known for
1.1.1.1

AD Query (ADQ) Advanced Configuration Options
Most of AD Query (ADQ) configuration options are configurable in SmartDashboard, under the Security Gateway
properties. Nevertheless, there are some advanced options that can be tweaked by using the GuiDBEdit Tool. (See
sk13009.)
These options reside here:
Left pane 'Network Objects' 'network_objects' Right upper pane <Gateway_Object_Name> Lower pane
'identity_aware_blade' 'ad_query_profile'.
'full_name_fetch_hour' (default: 4[am]) and 'full_name_query_interval' (default: 1[days])
In order for AD Query (ADQ) to display full user names, it fetches a mapping from login name to user name from
the Domain Controller. This is done every 'full_name_query_interval' days at 'full_name_fetch_hour' (hour is
GMT), and at the first time the system started.
As this fetching can cause some burden on the Domain Controller, it is done by default daily at 4am GMT (which
is out of normal business hours for both US and Europe).
You can adjust the hour by changing 'full_name_fetch_hour', or you can adjust the frequency of the update by
changing 'full_name_query_interval'.
Note: setting 'full_name_query_interval' to "0" will disable update of login > full name mapping.
'machine_multi_users_threshold' (default: 7[users])
The number of users concurrently connected from a single machine (IP) before designating this as a multi-user
host, and stopping tracking it. As AD Query (ADQ) cannot differentiate between users on the same machine, and
the given permissions are commulative, it prefers to ignore the machine if it reaches this threshold.
Note: setting 'machine_multi_users_threshold' to "0" will disable this feature. The value "0" is supported only
on R75.10 and above.
'service_account_threshold' (default: 10[concurrent connections])
The minimal amount of concurrent connections of the same user, before assuming that this is a 'service account'
(account used by some automated process), and issuing a log suggesting to ignore it.
Note: setting 'service_account_threshold' to "0" will disable this feature.
'log_user_ad_logins' (default: true)
Applies only to AD Query (ADQ) on Security Management Server / Log Server.
Controll whether AD Query (ADQ) should issue (set to 'true') a log when user logs into or out of Active Directory
/ when user is detected or revoked, or shouldn't it (set to 'false').

Did you know that ...
You can configure AD Query (ADQ) to support non-English names
If AD Query (ADQ) has to support non-English user / machine names, then enable the support for Unicode:
On R75 GA: Close all SmartConsole windows connect with the GuiDBEdit Tool Left pane 'Managed Objects'
'servers' Right upper pane <Relevant_LDAP_Account_Unit> Lower pane 'SupportUnicode' set the
value to "true" 'File' menu 'Save All' connect with SmartDashboard install the policy.
On R75.10 and above: SmartDashboard relevant 'LDAP Account Unit' 'Properties' 'General' tab check
the box 'Enable Unicode support' install the policy.

You can configure each gateway to connect to different Domain Controllers in the same account unit
If you have several Security Gateways, and you want each one of them to connect to different Domain Controllers
(i.e., each of the Security Gateways resides at a different physical site), it is possible to configure this via the
Gateway's properties. Refer to Identity Awareness Administration Guide chapter "Identity Sources" "Advanced AD
4/22/2014 Identity Awareness AD Query
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301#Abstract 5/5
Gateway's properties. Refer to Identity Awareness Administration Guide chapter "Identity Sources" "Advanced AD
Query Configuration" "Specifying Domain Controllers per Security Gateway".

Identity Logging is now called AD Query
The Identity Logging feature, which is available since R70.20, is still available in R75, under the name AD Query. Simply
turn AD Query on a Security Management Server / Log Server in order to have the same capabilities that you had
when using Identity Logging.
Notes:
Enabling AD Query (ADQ) on Log Servers enables you to see identity information even for logs generated by
pre-R70 Security Gateways.
Although AD Query (ADQ) for Security Gateways generally runs on SecurePlatform (since R75), IPSO (since
R75.20), Gaia based Security Gateways (since R75.40) and XOS (Crossbeam) based solutions (since R75.20), it
can also run on Windows-based Log Servers / Security Management Servers.


Related Solution: sk58881 (AD Query traffic dropped by Check Point Security Gateway)
Give us Feedback
Rate this document
[1=Worst,5=Best]
Characters left: 2000
2014 Check Point Software Technologies Ltd. All rights reserved.
Check Point Software Technologies, Inc. is a wholly owned
subsidiary of Check Point Software Technologies Ltd.
Additional comments...(Max 2000 characters allowed)