Support Center > Search Results > SecureKnowledge Details
Identity Awareness AD Query
Solution

Table of Contents:

  1. Abstract
  2. 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
  3. 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
  4. AD Query (ADQ) Command Line interface
  5. AD Query (ADQ) Advanced Configuration Options
  6. 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
  7. 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 (R75, R75.20, R75.40, R75.40VS, R76, R77) beforehand.

 

(2) 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 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.

  4. 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).

  5. The user initiates a connection to the Internet.

  6. 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:

  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 undesirable associations.

  4. Applying the new Association with the user / machine to the IP database.

Steps:

  • 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 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.

  • 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.

 

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, 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:

  1. Log in to SmartDashboard.

  2. Select "Servers and OPSEC" view in the objects tree click on LDAP Account Unit.

  3. 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.

  4. Go to the "Servers" tab - select "Add..."

  5. Configure the Exchange server:

    1. In "Host", select the network object representing this server (if no such exist, use the "New..." button to create a new one).

    2. 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.

    3. For "Default priority" set 100 (this is a special step required only when setting up Exchange servers).


  6. Repeat Steps 4-5 above for each Exchange server required querying.

  7. 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.

  8. 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.

In addition: Make sure that all Exchange servers queried by the Security Gateway produce the event logs described in sk60501 (Active Directory (AD) Query does not recognize Users).

 

(3) 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 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.



  • '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 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 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.

    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 shouldn't 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:

    • 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 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.

 

Applies To:
  • This solution replaces sk103408

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment