Integrated User Firewall Overview
Overview of Integrated User Firewall
This topic includes the following sections:
Integrated User Firewall and Authentication Sources
The SRX Series device already supports Unified Access Control (UAC) integration with Network Access Control (NAC) and a user firewall that can derive its authentication source from Windows Active Directory via the UAC MAG Series Junos Pulse Gateway. Many customers want simple user firewall functionality without full NAC, and do not want the additional cost or complexity of user role firewall (which has Active Directory dependencies such as Kerberos, SPNEGO on Browsers, Active Directory DNS/Certs, and UAC configuration).
The integrated user firewall fulfills the requirement for simplicity. It retrieves user-to-IP address mappings from the Windows Active Directory for the firewall policies usage as match criteria. This feature consists of the SRX Series or NFX Series device polling the event log of the Active Directory controller to determine, by username and source IP address, who has logged in to the device. Then the username and group information are queried from the LDAP service in the Active Directory controller. Once the device has the IP address, username, and group relationship information, it generates authentication entries. With the authentication entries, the device user firewall module enforces user-based and group-based policy control over traffic.
Integrated UserFW is optimal for deployments with 1 or 2 SRX Series devices in an environment, supporting up to 2 domains, and up to 20 domain controllers. For deployments with 3 or more SRX Series devices, more than 2 domains, more than 20 domain controllers, or where additional features are required, JIMS solution is a better choice see Configure Juniper Identity Management Service to Obtain User Identity Information for more information.
Benefits of Integrated User Firewall
The integrated user firewall feature introduces an authentication source via integration with Microsoft Active Directory technology.
Provides visibility into who is accessing the SRX Series or NFX Series and best-effort security for access to the device.
A single-box solution, requiring only SRX Series or NFX Series.
Requires fewer configuration steps than the UAC integration with NAC, which uses the UAC MAG Series for SRX Series devices.
Does not require the configuration of a captive portal, although that option is available to enforce on users who do not authenticate.
Ideal for small-to-medium businesses and low-scale deployments.
Supports high availability (HA).
How the Integrated User Firewall Works
At a high level, this feature involves the UserID process in Routing Engine, which reads the Windows event log from the Active Directory controller and abstracts IP address-to-user mapping information. The process correlates users to the groups to which they belong, via the LDAP protocol with the LDAP service in the Active Directory controller. Thus, the process has gathered enough information to generate authentication entries. The network administrator then references the authentication entries in user firewall security policies to control traffic.
Starting in Junos OS Release 17.4R1, you can assign IPv6 addresses to Active Directory domain controllers and the LDAP server. Prior to Junos OS Release 17.4R1, only IPv4 was supported.
A more detailed explanation of how this feature works is as follows:
- The SRX Series or NFX Series device reads the Active Directory event log to get source IP address-to-username mapping information. To do so, a process in the SRX Series Routing Engine implements a Windows Management Instrumentation (WMI) client with Microsoft Distributed COM/Microsoft RPC stacks and an authentication mechanism to communicate with a Windows Active Directory controller in an Active Directory domain. Using event log information retrieved from the Active Directory controller, the process knows the IP addresses of active Active Directory users and abstracts IP-to-Active Directory username mapping information. The process monitors Active Directory event log changes via the same WMI DCOM interface to adjust local mapping information to reflect any change in the Active Directory server. Starting in Junos OS Release 17.4R1, the SRX Series WMI client can read the Active Directory event log to obtain IPv6 addresses, in addition to IPv4 addresses. Prior to Junos OS Release 17.4R1, the WMI client could read only IPv4 addresses.
- The process uses LDAP to query the LDAP service interface of the Active Directory to identify the groups to which users belong. Having the IP address, the Active Directory user, and the groups, the process can generate authentication entries accordingly.
- The process pushes the authentication entries to the Packet Forwarding Engine authentication table. The Packet Forwarding Engine uses the entries and user policy to apply user firewall access control to traffic.
For SRX Series devices, this feature supports two domains and up to 10 Active Directory controllers in a domain. For NFX Series devices, this feature supports two domains and up to 5 Active Directory controllers in a domain.
Deployment Scenario for User Firewall Integration with Windows Active Directory
Figure 1 illustrates a typical scenario where the integrated user firewall feature is deployed. Users in the Active Directory domain and users outside the Active Directory domain want access to the Internet through an SRX Series device. The domain controller might also act as the LDAP server.
The SRX Series device reads and analyzes the event log of the domain controller and generates an authentication table as an Active Directory authentication source for this feature. The user firewall is aware of any domain user on an Active Directory domain device via the Active Directory authentication source. The SRX Series device administrator configures a user firewall policy that enforces the desired user-based or group-based access control.
For any non-domain user or domain user on a non-domain machine, the administrator specifies a captive portal to force the user to do firewall authentication (if the SRX Series supports captive portal for the traffic type). After the user enters a name and password and passes firewall authentication, the SRX Series gets firewall authentication user/group information and can enforce user firewall policy to control the user accordingly.
In addition to captive portal, if the IP address or user information is not available from the event log, the user can again log in to the Windows PC to generate an event log entry. Then the system generates the user’s authentication entry accordingly.
Starting with Junos OS 17.4R1, the SRX Series devices and NFX Series devices can search the Active Directory authentication table, the local authentication table, and the firewall authentication table for information based on IPv6 addresses. Prior to Junos OS Release 17.4R1, only IPv4 was supported.
For example, prior to Junos OS Release 17.4R1, if the specification for the source-address field of a security policy was set to “any”, implying also IPv6, integrated user firewall ignored the traffic rather than searching for a matching user entry in the authentication tables.
Consider the following scenario and security policy configuration in light of support for IPv6 addresses. When traffic arrives at the SRX Series device from a user whose IP address (source-address) is 2001:db8::1:1, given a source-identity match—that is, as illustrated in this example, the user belongs to the role2 group—the SRX Series UserFW module is able to authenticate the user, and it sets up a session for the user’s traffic flow.
Prior to Junos OS Release 17.4R1, when any-ipv6 was specified for the source-address field in a user firewall security policy, a commit warning message was issued indicating that only IPv4 addresses were supported. That message is no longer issued.
Windows Active Directory controllers earlier than Windows 2003 are not supported.
Tracking the status of non-Windows Active Directory users is not supported.
Logical systems are not supported.
The WMIC does not support multiple users logged on to the same PC.
Domain controllers and domain PCs must be running Windows OS. The minimum support for a Windows client is Windows XP. The minimum support for a server is Windows Server 2003.
You cannot use the Primary Group, whether by its default name of Domain Users, or any other name (if you happened to have changed it), in integrated user firewall configurations.
When a new user is created in Active Directory, the user is added to the global security group Primary Group which is by default called Domain Users. The Primary Group is less specific than other groups created in Active Directory because all users belong to it. Consequently, it can become very large.
Understanding Active Directory Authentication Tables
This topic includes the following sections:
Active Directory Authentication as an Authentication Source
On an SRX Series device or NFX Series device, user information tables serve as the authentication source for information required by firewall security policies. The device supports various user information tables including local, user firewall, and Unified Access Control (UAC) types. The integrated user firewall feature introduces another type of authentication source—Active Directory authentication.
The integrated user firewall feature gathers user and group information for Active Directory authentication by reading domain controller event logs, probing domain PCs, and querying Lightweight Directory Access Protocol (LDAP) services within the configured Windows domain. Up to two Windows domains are supported.
From the user and group information, the integrated user firewall feature generates an Active Directory authentication table on the Routing Engine of the device, which then pushes the authentication table to the Packet Forwarding Engine. Security policies use the information in the table to authenticate users and to provide access control for traffic through the firewall.
Active Directory Authentication Tables
The Active Directory authentication table contains the IP address, username, and group mapping information that serves as the authentication source for the device integrated user firewall feature. Information in the table is obtained by reading Windows Active Directory domain controller event logs, probing domain PCs, and querying LDAP services within a specified Windows domain.
Reading domain controller event logs generates a list of IP address-to-user mapping information that is used to create entries in the Active Directory authentication table. Once entries have been added in the table, a query is sent to the LDAP server for user-to-group mapping information.
Starting with Junos OS Release 17.4R1, the SRX Series and NFX Series device supports IPv6 addresses for user firewall (UserFW) authentication. IPv6 addresses can be used in Active Directory authentication table entries, local authentication table entries, and firewall authentication table entries. They can also be used for device identity addresses with Active Directory as the authentication source. An IPv6 address can also be configured for the Windows domain controller. Previously only IPv4 addresses were supported.
Starting in Junos OS Release 20.3R1, for SRX300 Series devices with eUSB (SRX300, SRX320, SRX340, and SRX345), the authentication entry database moves from disk memory to internal memory. This enhancement reduces disk usage and increases the read-write speed of loading authentication entries.
For SRX1500, SRX380, SRX300, SRX320, SRX340, SRX345, SRX4100, SRX4200, SRX4600, SRX550HM, SRX5400, SRX5600, SRX5800 devices and vSRX 3.0 instances, the user firewall database operations on disk are enhanced; this results in reduced disk usage and increases disk lifetime.
In addition to IPv4, IPv6 traffic can match any security policy configured for source identity. Previously, if a security policy was configured for source identity and “any” was specified for its IP address, the SRX Series user firewall ignored the IPv6 traffic.
When user traffic arrives at the device, the Active Directory authentication table is searched for an entry corresponding to the source IP address of the traffic to authenticate the user. The device can also search for an entry in the local authentication table and the firewall authentication table, if an entry is not found in the Active Directory authentication table.
The device supports use of IPv6 and IPv4 addresses associated with source identities in security policies. If an entry exists, policies matching that entry are applied to the traffic and access is allowed or denied.
The LDAP server returns all group information; this includes not only information about the groups you directly belong to, but also all the parent (and parent of the parent and so on) groups that you belong to. Group information returned from the LDAP server is compared with the source identity in security policies. If there is a match, Active Directory authentication table entries are updated to include only the group information provided in the security policy. In this way, only relevant group information is listed in the authentication table. Whenever source identity is updated, the authentication table is also updated to reflect the up-to-date relevant group information for all listed users.
The integrated user firewall feature for both Active Directory authentication and ClearPass authentication will manage up to 2048 sessions for each user for whom there is a user identity and authentication entry in the authentication table. There might be additional sessions associated with a user beyond the 2048 supported sessions, but they are not managed by integrated user firewall. When an authentication entry in an authentication table is deleted, integrated user firewall only closes sessions that are associated with that entry. It will not close sessions that it does not manage. That is, sessions that are not associated with the authentication entry are not closed.
Only IPv4 addresses are supported for ClearPass.
Table 1 lists Active Directory authentication table support by SRX Series devices and NFX Series devices. Platform support depends on the Junos OS release in your installation.
Table 1: Active Directory Authentication Table Support
Active Directory Authentication Table Entries
Active Directory Controllers
SRX100, SRX110, SRX210, SRX220
vSRX (2 vCPUs and 4 GB vRAM, 5 vCPUs and 8 GB vRAM )
vSRX (9 vCPUs and 16 GB vRAM, 17 vCPUs and 32 GB vRAM )
Once the maximum number of authentication table entries is reached, no additional entries are created.
To be compliant with the Active Directory authentication table, entries must adhere to the following parameters:
Usernames are limited to 64 characters.
Group names are limited to 64 characters.
Each entry can be associated with up to 200 relevant groups (configured in the source identity field). For example, if you belong to 1000 groups in LDAP and out of these, no more than 200 groups are configured in the source identity field, you are compliant with the Active Directory authentication table.
The Active Directory authentication table must be enabled as the authentication source for integrated user firewall information retrieval in the Windows Active Directory environment. Use the following statement for that purpose:
The priority option specifies the sequence in which user information tables are checked. Using the lowest setting for the Active Directory authentication source specifies the highest priority, meaning that the Active Directory authentication source is searched first.
State Information for Active Directory Authentication Table Entries
Active Directory authentication table entries can be in one of four states:
For a list of probe responses, see Understanding Integrated User Firewall Domain PC Probing .
To display Active Directory authentication entries, along with their state information, use the following command:
Domain: www.example1.net Total count: 3 Source IP Username Groups State 2001:db8::1:1 u2 r1, r3, r4 initial 192.168.10.3 u3 r5, r6, r4 pending 2001:db8::2:1 u4 r3, r4 initial Domain: www.example2.net Total count: 2 Source IP Username Groups State 10.1.1.2 u4 r1, r3, r4 valid 10.1.1.3 u5 r5, r6, r4 invalid
Command options allow you to display information by user or group, and to define additional output levels—brief, domain, extensive, node.
Active Directory Authentication Table Management
Windows domain environments are constantly changing as users log in and out of the network and as network administrators modify user group information. The integrated user firewall feature manages changes in the Windows domain by periodically reading domain controller event logs and querying the LDAP server for user-to-group mapping information. That information is used in updating the Active Directory authentication table as appropriate.
Additionally, a probe function is provided to address changes that occur between reading event logs, or to address the case where event log information is lost. An on-demand probe is triggered when client traffic arrives at the firewall but a source IP address for that client cannot be found in the table. And at any point, manual probing is available to probe a specific IP address
Changes to the Active Directory Authentication table also occur due to source identity changes in the security policy configuration.
Table 2 describes events that trigger an Active Directory authentication table update.
Table 2: Events Triggering Active Directory Authentication Table Updates
Active Directory Authentication Table Update
A domain controller event log is read at configured intervals.
New IP address-to-user entries are added in the authentication table in initial state. Group information is retrieved from the LDAP server.
When the authentication entry is pushed to Packet Forwarding Engine, the state is changed to valid.
An on-demand or manual probe is sent to a domain PC.
An entry is added in the authentication table in pending state. If a probe response is not returned within 90 seconds, the state of the entry is deleted.
An on-demand or manual probe response is received from a domain PC.
Based on the response, entries in pending state are changed to valid or invalid. For valid responses, the group information is retrieved from the LDAP server. For invalid responses, the entry is marked as invalid.
An LDAP server query identifies new user-to-group mapping information.
Entries are updated with the group information.
An LDAP server query identifies deleted user information.
Entries associated with that user are deleted from the table.
An LDAP server query identifies deleted group information.
The affected group information is updated.
For example, user2 belongs to group2, and group2 belongs to group1. And, group1 is listed as a source-identity for group2. For any authentication entry of user2, group1 is listed in its relevant groups. However, if group2 is removed from the LDAP server, user2 loses the connection with group1, and as a result, group1 is removed from the user2 authentication table.
An LDAP server query identifies added group information.
If the group is referenced in a security policy, entries associated with this group are updated to add the group information.
The source identity information is removed from a security policy configuration.
Entries associated with the source identity are deleted from Active Directory authentication table.
If an entry is deleted from the table, any sessions attached to that entry are also deleted. If an entry in the table is updated to add or remove group information, there is no impact to existing sessions for that entry.
When you use the CLI to delete an Active Directory authentication entry, the system closes the related session and writes a session-close message to the log file. However, the session-close message does not contain the source identity information for the user, that is, the user and user group information.
To manually delete an entry from the table, use the request services user-identification active-directory-access active-directory-authentication-table command. Options exist for deleting a specific IP address, domain, group, or user.
To clear the contents of the Active Directory authentication table, use the clear services user-identification active-directory access active-directory-authentication-table command.
Timeout Interval for Table Entries
When a user is no longer active, a timer is started for that user’s entry in the Active Directory authentication table. When time is up, the user’s entry is removed from the table. Entries in the table remain active as long as there are sessions associated with the entry.
To set the timeout value, use the following statement:
The default authentication-entry-timeout interval is 30 minutes. To disable timeouts, set the interval to 0.
We recommend that you disable timeouts when disabling on-demand probing in order to prevent someone from accessing the Internet without logging in again.
To view timeout information for Active Directory authentication table entries, use the following command:
Domain: www.example1.net Total entries: 2 Source IP: 192.168.1.2 Username: u2 Groups: r1, r3, r4 State: initial Access start date: 2014-03-22 Access start time: 10:56:58 Age time: 20 min Source IP: 192.168.1.3 Username: u3 Groups: r5, r6, r4 State: pending Access start date: 2014-03-22 Access start time: 10:46:58 Age time: 10 min
This example shows that the timer has started for two entries—the entry for user u2 will time out in 20 minutes, while the entry for user u3 will time out in 10 minutes. When session traffic is associated with an entry, the age time value changes to “infinite.”
Understanding the Invalid Authentication Table Entry Timeout Setting
Timeout Setting for Invalid Authentication Entries
Starting in Junos OS Release 15.1X49-D100, for SRX Series devices and vSRX, you can protect invalid user authentication entries in an authentication table from expiring before the user can be validated by configuring a timeout setting that is specific to invalid entries. The invalid authentication entry timeout setting is separate from the common authentication entry timeout setting that is applied to valid entries.
Authentication entries in both the Windows Active Directory authentication table and the ClearPass authentication table contain a timeout value after which the entry expires. Prior to introduction of this feature, a single, common timeout setting was applied to valid and invalid authentication entries. That is, if an invalid authentication entry was created in either of these tables, the current setting of the common timeout for the table—which applied to all of the table’s entries—was applied to it.
For both the Active Directory authentication table and the ClearPass authentication table, the invalid entry could expire before the user’s identity could be validated. Here is what could cause that event to occur in each case:
Windows Active Directory uses a mechanism to probe an unauthenticated user’s device for user identity authentication information based on the IP address of the device. It is not uncommon for Windows to trigger a WMI probe that fails because it occurs before the user logs in. After an unsuccessful probe, the system generates an entry in the authentication table with an INVALID state for the IP address of the device. If you configured a value for the invalid timeout setting, that timeout is applied to the entry. If you did not configure a value for the invalid entry timeout setting, then its default timeout of 30 minutes is applied.
The invalid authentication entry timeout setting is separate from the common authentication entry timeout setting that is applied to valid entries.
Starting in Junos OS Release 17.4R1, the integrated user firewall supports IPv6 device addresses in the Windows Active Directory authentication table. Prior to Junos OS Release 17.4R1, only IPv4 addresses were supported.
For the ClearPass feature, if an unauthenticated user attempts to join the network and the IP address of the user’s device is not found—that is, it is not in the Packet Forwarding Engine—the device queries Aruba ClearPass for the user’s information. If the query is unsuccessful, the system generates an INVALID authentication entry for the user. If you configured a value for the invalid timeout setting, that timeout is applied to the entry. If you did not configure the invalid entry timeout, then its default timeout of 30 minutes is applied to the new entry.
The invalid entry timeout is also applied to entries whose state is changed from valid or pending to INVALID.
You configure the timeout setting to be applied to invalid authentication entries in the Windows Active Directory authentication table and the ClearPass authentication table separately. If you do not configure a timeout setting, the invalid authentication entry timeout default value of 30 minutes is applied. The application and effect of the timeout value is determined differently for these authentication sources.
How the Invalid Authentication Entry Timeout Works for Windows Active Directory
Use the following command to configure the invalid authentication entry timeout setting for entries in the Windows Active Directory authentication table. In this example, the invalid authentication entry timeout value is set to 40 minutes. That timeout value is applied to new invalid entries.
The new timeout value is also applied to existing invalid entries but within the context of the current timeout value assigned to them and the timeout state. Suppose that the authentication table contains existing invalid entries to which an invalid authentication entry timeout setting or the default was previously applied. In this case, the new invalid entry timeout setting has effect on the timeout for these entries, but in a different way. For these entries, the original timeout setting—the time that has expired since the original timeout value was applied–and the new timeout setting collude to produce the resulting timeout value that is applied to the existing entry.
As Table 3 shows, in some cases the resulting timeout is extended, in some cases it is shortened, and in some cases it causes the original timeout to expire and the invalid authentication entry to which is applies to be deleted.
Table 3: How New Invalid Authentication Entry Timeout Settings Affect Timeout Settings for Existing Invalid Entries in the Active Directory Authentication Table
Original Invalid Entry Timeout Setting for Existing Entry
New Invalid Entry Timeout Configuration Setting
Resulting Timeout Setting for Existing Invalid Entry
Timeout expired and entry is removed from the authentication table
Just as the new invalid timeout entry is imposed on that of old invalid entries, producing various and unique results, a new invalid entry is subject to the same rules and effects when the invalid entry timeout value is changed.
How the Invalid Authentication Entry Timeout Works for SRX Series and NFX Series Aruba ClearPass
Use the following command to configure the invalid authentication entry timeout for entries in the ClearPass authentication table. In this example, invalid authentication entries in the ClearPass authentication table expires 22 minutes after they are created.
When you initially configure the invalid authentication entry timeout value for ClearPass, it is applied to any invalid authentication entries that are generated after it was configured. However, all existing invalid authentication entries retain the default timeout of 30 minutes.
If you do not configure the invalid authentication entry timeout setting, the default timeout of 30 minutes is applied to all invalid authentication entries.
If you configure the invalid authentication entry timeout setting and delete it later, the default value is applied to new invalid authentication entries generated after the deletion. However, any existing invalid authentication entries to which a configured value had been applied previously retain that value.
If you change the setting for the invalid authentication entry timeout value, the new value is applied to all invalid authentication entries that were created after the value was changed. However, all existing invalid authentication entries retain the former invalid authentication entry timeout setting applied to them. Those entries to which the default value of 30 minutes had been applied previously retain that setting.
When the pending or valid state of an entry is changed to invalid, the invalid authentication entry timeout setting is applied to it.
When the state of an invalid authentication entry is changed to pending or valid, the invalid authentication entry timeout setting is no longer applicable to it. The timeout value set for the common authentication entry timeout is applied to it
Table 4 shows how a new invalid entry timeout value affects new and existing invalid entries.
Table 4: How New Invalid Authentication Entry Timeout Settings Affect Timeout Settings for Invalid Entries in the ClearPass Authentication Table
Invalid Entry Timeout Setting
Intial Invalid Entry Timeout Setting
New Invalid Entry Timeout Configuration Setting
Final Timeout Setting for Existing Invalid Entry
New invalid authentication entry
Existing invalid entry timeout
Existing invalid entry timeout
Existing invalid entry timeout
LDAP Functionality in Integrated User Firewall
This topic includes the following sections:
Role of LDAP in Integrated User Firewall
In order to get the user and group information necessary to implement the Integrated User Firewall feature, the SRX Series evice uses the Lightweight Directory Access Protocol (LDAP). The device acts as an LDAP client communicating with an LDAP server. In a common implementation scenario of the integrated user firewall feature, the domain controller acts as the LDAP server. The LDAP module in the device, by default, queries the Active Directory in the domain controller.
The device downloads user and group lists from the LDAP server. The device also queries the LDAP server for user and group updates. The device downloads a first-level, user-to-group mapping relationship and then calculates a full user-to-group mapping.
The use of “LDAP” in this section applies specifically to LDAP functionality within the integrated user firewall feature.
LDAP Server Configuration and Base Distinguished Name
Most of the LDAP server configuration is optional, leveraging the common implementation scenario where the domain controller acts as the LDAP server. The device periodically (every two minutes) queries the LDAP server to get the user and group information changed since the last query.
LDAP’s Authentication Method
By default, the LDAP authentication method uses simple authentication. The client’s username and password are sent to the LDAP server in plaintext. Keep in mind that the password is clear and can be read from the network.
To avoid exposing the password, you can use simple authentication within an encrypted channel [namely Secure Sockets layer (SSL)], as long as the LDAP server supports LDAP over SSL (LDAPS). After enabling SSL, the data sent from the LDAP server to the device is encrypted. To enable SSL, see the user-group-mapping statement.
LDAP Server’s Username, Password, and Server Address
The LDAP server’s username, password, IP address, and port are all optional, but they can be configured.
If the username and password are not configured, the system uses the configured domain controller’s username and password.
If the LDAP server’s IP address is not configured, the system uses the address of one of the configured Active Directory domain controllers.
If the port is not configured, the system uses port 389 for plaintext or port 636 for encrypted text.
Caching and Calculation of User-to-Group Mappings
The device caches user-to-group mappings in its local database when the show services user-identification active-directory-access user-group-mapping operation is performed. This command displays the users who belong to a group or the groups to which a user belongs.
Three events cause a user-to-group mapping to be removed from the cache:
A source-identity is removed from a referenced firewall policy (because only source-identities referenced in a policy are stored in the authentication table).
The LDAP configuration is deleted from the customer’s configuration, so all cached Active Directory user-to-group mappings for the domain are removed.
The user-to-group mapping is deleted from the LDAP server.
The device periodically queries to get user and group information from the LDAP server in real time. The user list and the group list show only cached users or groups, not all users or groups in the LDAP server. From this information, the device calculates one-level mapping relationships. The user list, group list, and mapping are cached in the local database.
Updating Group Information in the Authentication Entry Table
The device queries to get the changed users and groups based on the prior query results from the LDAP server. The device updates the local database and triggers an authentication entry update. Only user/group mappings that are already cached are updated. Other users and groups that are not in the database do not have their mapping relationships cached.
LDAP Server Status and Statistics
You can verify the LDAP connection status by issuing the show services user-identification active-directory-access user-group-mapping status command.
You can see counts of queries made to the LDAP server by issuing the show services user-identification active-directory-access statistics user-group-mapping command.
Active Directory Autodiscovery
The integrated user firewall feature provides the IP address and Active Directory name of the domain. The auto-discovery feature can use the Active Directory’s global catalog feature and then query DNS for a list of global catalogs. The global catalogs in the list are typically provided in a weighted order based on criteria such as network location, system-set weights based on global catalog server size, and so on. Once the customer has the list of Active Directories, the customer can configure it for both event log reading and LDAP search.