Active Directory as Identity Source

What is Active Directory as Identity Source

An identity source stores user information in a database. You can use this information for user authentication. Active Directory as Identity Source defines integration of SRX Series firewall, vSRX virtual firewall, cSRX container firewall or NFX Series device with Microsoft Windows Active Directory.

Note:

Active Directory as Identity Source was previously known as Integrated User Firewall.

Benefits

• Simpler configuration steps and best-effort security for access to the device.

• Ideal for medium businesses and upto medium-scale deployments.

• Supports high availability (HA).

• Configuration of captive portal is optional for users who do not authenticate.

How does Active Directory as Identity Source Work

Figure 1 illustrates a typical scenario where the Active Directory as Identity Source is deployed. Users inside and outside the Active Directory domain want access to the Internet through a device. The domain controller might also act as the LDAP server.

Table 1: Components of Active Directory as Identity Source

Components	Description
Domain Controller	Domain controller helps to apply security policies for request access to user authentication resources.
Domain PC	Connected windows computers group that share user account information and a security policy.
Non-domain PC	Users can access windows desktop enviroment from any location using a device with internet connectivity.
LDAP authentication server for non-domain user	LDAP protocol helps to identify the groups to which users belong. The username and group information are queried from the LDAP service in the Active Directory controller.

1. The device reads and analyzes the Windows event log of the active directory controller and generates an authentication table.

2. The Active Directory as Identity Source is aware of any domain user via the authentication table.

3. The device configures a policy that enforces the desired user-based or group-based access control.

4. For any non-domain user or domain user on a non-domain machine, the administrator specifies a captive portal to force the user to authenticate (if the device supports captive portal for the traffic type).

5. After the user enters a name and password and authenticates, the device gets user/group information and enforce the policy.

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

What is Windows Management Instrumentation Client (WMIC)

When you configure the Active Directory as Identity Source, the device establishes a Windows Management Instrumentation (WMI)/Distributed Component Object Module (DCOM) connection to the domain controller. The device acts as a WMI client (WMIC). It reads and monitors the security event log on the domain controller. The device analyzes the event messages to generate IP address-to-user mapping information.

How WMIC Reads the Event Log on the Domain Controller

WMIC reads the event log on the domain controller in following manner:

• The device monitors the event log at a configurable interval, which defaults to 10 seconds.

• The device reads the event log for a certain timespan, which you can configure. The default timespan is one hour.

• Each time at WMIC startup, the device checks the last timestamp and the current timespan. If the last timestamp is older than the current timespan, then the current timespan takes effect.

• The device can read the event log to obtain IPv6 addresses in addition to IPv4 addresses.

• During WMIC startup, the device has a maximum count of events it will read from the event log, and that maximum is not configurable.

  • On SRX300, SRX320, SRX340, SRX345, and SRX380 Series Firewalls, the maximum count is 100,000.

  • On SRX5400, SRX5600, and SRX5800 Series Firewalls, the maximum count is 200,000.

  During WMIC startup, this maximum count is used with the timespan setting, so that if either limit is reached, the WMIC stops reading the event log.

• After a failover, the device reads the event log from the latest event log timestamp.

Specify IP Filters to Limit IP-to-User Mapping

You can specify IP filters to limit the IP address-to-user mapping information that the device generates from the event log.

To understand when a filter is useful for such mapping, consider the following scenario. A customer deploys 10 devices in one domain, and each device controls a branch. All 10 devices read all 10 branch user login event logs in the domain controller. However, the device is configured to detect only whether the user is authenticated on the branch it controls. By configuring an IP filter on the device, the device reads only the IP event log under its control.

You can configure a filter to include or exclude IP addresses or prefixes. You can specify a maximum of 20 addresses for each filter.

Windows Event Log Verification and Statistics

You can verify that the authentication table is getting IP address and user information by issuing the show services user-identification active-directory-access active-directory-authentication-table all command. A list of IP address-to-user mappings is displayed for each domain. The table contains no group information until LDAP is running.

You can see statistics about reading the event log by issuing the show services user-identification active-directory-access ip-user-mapping statistics domain command.

Firewall Authentication as backup to WMIC

The primary method for the Active Directory as Identity Source to get IP address-to-user mapping information is for the device to act as a WMI client (WMIC). However, the event-log-reading and PC probe functions both use WMI, and using a global policy to disable the WMI-to-PC probe affects event log reading. These might result in the failure of the PC probe, and a backup method for getting IP address-to-user mappings is needed. That method is to use firewall authentication to identify users.

See Domain PC Probing.

If a domain is configured in that statement, fwauth recognizes that the domain is for a domain authentication entry, and will send the domain name to the fwauth process along with the authentication request. After it receives the authentication response, fwauth deletes that domain authentication entry. The fwauth process sends the source IP address, username, domain, and other information to the UserID process, which verifies that it is a valid domain user entry. The subsequent traffic will hit this user firewall entry.

What is Domain PC Probing

Domain PC probing acts as a supplement of event log reading. When a user logs in to the domain, the event log contains that information. The PC probe is triggered only when there is no IP-to-address mapping from the event log.

Domain information constantly changes as users log in and out of domain PCs. The Active Directory as Identity Source probe functionality provides a mechanism for tracking and verifying information in the authentication tables by directly probing domain PCs for IP address-to-user mapping information. New and changed information identified by the probe serves to update Active Directory authentication table entries, which is critical to maintaining firewall integrity.

The IP address filter also impacts the PC probe. Once you configure the IP address filter, only the IP address specified in the filter is probed.

Domain PC Probing User Information

The Active Directory as Identity Source tracks the online status of users by probing domain PCs. If a user is not online or is not an expected user, the Active Directory authentication table is updated as appropriate. The following probe behaviors apply:

On-demand probing

On-demand probing occurs when a packet is dropped due to a missing entry in the Active Directory authentication table. In this case, an entry is added in pending state to the authentication table, and the domain PC identified by the source IP field of the dropped packet is probed for IP address and user information. The entry remains in pending state until a response is received from the probe.

Manual probing

Manual probing is used to verify and troubleshoot the online status of a user or a range of users, and is at the discretion of the system administrator. Note: Manual probing can cause entries to be removed from the Active Directory authentication table. For example, if there is no response from your PC due to a network issue, such as when the PC is too busy, the IP address entry of the PC is marked as invalid and your access is blocked.

Based on the domain PC probe response, updates are made to the Active Directory authentication table, and associated firewall policies take effect. If no response is received from the probe after 90 seconds, the authentication entry times out. The timed-out authentication entry is the pending state authentication entry, which is generated when you start the PC probe.

If the probe is successful, the state of the authentication entry is updated from pending to valid. If the probe is unsuccessful, the state of the authentication entry is marked as invalid. The invalid entry has the same lifetime as a valid entry and is overwritten by upcoming fwauth (firewall authentication process) authentication results or by the event log.

If the device cannot access a domain PC for some reason, such as a network configuration or Windows firewall issue, the probe fails.

For more probe responses and corresponding authentication table actions, see Table 1.

Table 2: Probe Responses and Associated Active Directory Authentication Table Actions

Probe Response from Domain PC	Active Directory Authentication Table Action
Valid IP address and username	Add IP-related entry.
Logged on user changed	Update IP-related entry.
Connection timeout	Update IP-related entry as invalid.
Access denied	Update IP-related entry as invalid.
Connection refused	Update IP-related entry as invalid.
Authentication failed (The configured username and password have no privilege to probe the domain PC.)	Update IP-related entry as invalid.

How to Configure Probe

On-demand probing is enabled by default. To disable on-demand probing, you can use the set services user-identification active-directory-access no-on-demand-probe statement. Delete this statement to reenable probing. When on-demand probing is disabled, manual probing is available.

To initiate a manual probe, you can use the request services user-identification active-directory-access ip-user-probe ip-address address domain domain-name command. If a domain name is not specified, the probe looks at the first configured domain for the IP address. To specify a range, use the appropriate network address.

The probe timeout value is configurable. If no response is received from the domain PC within the wmi-timeout interval, the probe fails and the system either creates an invalid authentication entry or updates the existing authentication entry as invalid. If an authentication table entry already exists for the probed IP address, and no response is received from the domain PC within the wmi-timeout interval, the probe fails and that entry is deleted from the table.

See Configure Active Directory as Identity Source.

Probe Rate and Statistics

The maximum probe rate for the Active Directory as Identity Source is set by default and cannot be changed. For SRX 5400, SRX 5600, and SRX 5800 Series Firewalls, the probe rate is 600 times per minute. For branch SRX Series Firewalls, the probe rate is 100 times per minute. Probe functionality supports 5000 users, or up to 10 percent of the total supported authentication entries, whichever is smaller. Supporting 10 percent means that at any time, the number of IP addresses waiting to be probed cannot exceed 10 percent.

What is the use of LDAP for Active Directory as Identity Source

The use of LDAP in this section applies specifically to LDAP functionality within the Active Directory as Identity Source.

In order to get the user and group information necessary to implement the Active Directory as Identity Source, the device 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 Active Directory as Identity Source, 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.

How LDAP for Active Directory as Identity Source Work

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.

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.