As part of Check Point's response to CVE-2021-26414, "Windows DCOM Server Security Feature Bypass", Check Point recommends to use Identity Collector as the Identity Source instead of AD Query. For more information about Check Point's response to CVE-2021-26414, see sk176148.
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
Using AD Query with Exchange Servers
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
Related Solutions
(1) 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.
(2) How AD Query (ADQ) works
The steps in the AD Query example are listed below:
The Security Gateway registers to receive Security Event logs from the Active Directory Domain Controllers.
A user logs in to a desktop computer using his Active Directory credentials.
The user logs on to a Domain Controller (DC). This DC and only it will have the logon security log (those logs do not replicate to other DCs. The firewall queries all the DCs security logs and gets the logon security log.
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).
The user initiates a connection to the Internet.
The Security Gateway confirms that the user has been identified and allows him to access the Internet, based on the policy.
AD Query (ADQ) employs the following four main steps:
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 not 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 the IP address that the authentication came from. 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.
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 explicitly 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.
SmartConsole - 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), SmartConsole 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.
Using AD Query with Exchange Servers
AD Query identity source can be used for acquiring identities of users connected to Microsoft Exchange servers. This can be useful for acquiring identities of users who are not logging in using Active Directory, but are still connecting to the organization's Exchange servers. A common use case would be users running Linux/Mac computers and smartphones outside the AD domain, who connect directly to the Exchange servers.
Prerequisites are the same as with integrating AD Query with domain controllers, including auditing of "success login" events enabled, WMI running on the Exchange server, and sufficient permissions for the user configured with the relevant AU. See the additional information section for reference.
Mostly, the setup process is the same as manually adding a server to an existing AD Query environment. The additional steps for setting up Exchange server appear below in italics:
Log in to SmartConsole.
In the Object Explorer, go to Users/Identities and click on LDAP Account Unit.
Double-click on the Account Unit defined for the AD domain. If no such account unit is configured, create a new one. Note: at least one Domain controller must be configured in the Account Unit. Domain controller is required for fetching mandatory user information such as group membership.
Go to the "Servers" tab - select "Add..."
Configure the Exchange server:
In "Host", select the network object representing this server (if no such exist, use the "New..." button to create a new one).
Fill in the user details. This user will be used by the gateway to query the Exchange server for events. This user must have sufficient permissions to query the Exchange server security log.
For "Default priority" set 100 (this is a special step required only when setting up Exchange servers).
Repeat Steps 4-5 above for each Exchange server required querying.
Verify that events are received and processed on Security Gateway - run the "adlog a dc" command in Expert mode to get a report regarding each configured server and the number of events received in the last hour.
It might be required to add an explicit security rule for allowing X11 traffic (service "dce-rpc") between the Security Gateway and the Exchange server.
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 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 efficient (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.
(4) 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 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
(5) 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.
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.
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 commutative, it prefers to ignore the machine if it reaches this threshold.
Note: setting 'machine_multi_users_threshold' to "0" will disable this feature.
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.
Controls 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 should not do it (set to 'false').
(6) 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:
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 Query Configuration" - "Specifying Domain Controllers per Security Gateway".
Identity Logging is now called AD Query
The Identity Logging feature is available under the name AD Query. Simply turn AD Query on a Security Management Server / Log Server to have the same capabilities that you had when using Identity Logging.
