Active Directory as Identity Source

Benefits

• Simplifies configuration steps and provides best-effort security to access the device.

• Ideal for medium businesses and up to 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?

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 with the domain controller. The device acts as a WMI client (WMIC). The device 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.

Use Feature Explorer to confirm platform and release support for specific features.

Review the Platform-Specific WMIC Behavior section for notes related to your platform.

How WMIC reads the Event Log on the Domain Controller?

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

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

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

3. Each time at WMIC starts up, 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.

4. The device can read the event log to obtain both IPv4 and IPv6 addresses.

5. When WMIC starts up, the firewall has a maximum count of events that it can read from the event log. You cannot configure the maximum count of events.

   When WMIC starts up, the WMIC uses the maximum count with the timespan setting. When the limit is reached, the WMIC stops reading the event log.

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

Use Feature Explorer to confirm platform and release support for specific features.

Review the Platform-Specific Probe Rate Behavior section for notes related to your platform.

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:

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

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 address 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 on SRX Series Firewall.

Probe Rate and Statistics

The maximum probe rate for the Active Directory as identity source is set by default and cannot be changed. 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.

Why Use Device Identity to Control Access to Your Network

For various reasons, you might want to control access to your network resources based on the identity of the user’s device rather than on the identity of the user. The Active Directory as identity source device identity authentication feature was designed to offer a solution to these and other similar situations by enabling you to control network access based on attributes of the user’s device.

The device receives or obtains the device identity information from the authentication source in the same manner that it obtains the user identity information, depending on the authentication source. The process in which the device identity information is obtained and stored in the device identity information table entails the following actions on the part of the device:

• Getting the device identity information.

  Depending on the authentication source, the device uses one of the following two methods to obtain the device identity information:

  • Microsoft Active Directory as identity source—If your environment is set up to use Microsoft Active Directory, the firewall or NFX Series device obtains the device IP address and groups from the Active Directory domain controller and LDAP service. The device can extract the device information from the domain controller’s event log and then connect to the Active Directory LDAP server to obtain the names of the groups that the device belongs to. The device uses the information that it obtained from the event log to locate the device’s information in the LDAP directory.

  • Third-party Network Access Control (NAC) systems—If your network environment is configured for a NAC solution and you decide to take this approach, the NAC system sends the device identity information to the firewall or NFX Series device. These authentication systems use the POST service of the RESTful Web services API, called Web API. The device implements the API and exposes to the authentication systems to allow them to send the device identity information to the firewall. The API has a formal XML structure and restrictions that the authentication source must adhere to in sending this information to the device.

    Warning:

    If you take this approach, you must verify that your NAC solution works with the device.

• Creating an entry for the device in the device identity authentication table.

  • After the firewall obtains the device identity information, it creates an entry for it in the device identity authentication table. The device identify authentication table is separate from the Active Directory authentication table or any of the other local authentication tables used for third party authentication sources.

  • Too, unlike local user authentication tables which are particular to an authentication source or feature, the device identity authentication table holds device identity information for all authentication sources. However, only one authentication source, such as Active Directory, can be active at a time. The firewall allows only authentication source to be used at a time to constrain the demand on the system to process information.

  • The purpose of obtaining the device information and entering it into the device identity authentication table is to control user access to network resources based on the device’s identity. For this to occur, you must also configure security policies that identify the device, based on the specified device identity profile, and specify the action to be taken on traffic that issues from that device.

  • The device identity authentication feature provides a generic solution that stores device identity information in the same table regardless of the authentication source.

Device Identity Attributes and Profiles

The device identity profile, referred to in the CLI as the end-user-profile, is a key component of the Active Directory as identity source device identity authentication feature. It identifies the device and specifies its attributes.

Source IP       Device ID      Device-Groups 
192.0.2.1       lab-computer1   grp1, grp3, grp4 
198.51.100.1    dev-computer2   grp5, grp6, grp4      

Device Identity Authentication Table

When you configure the device to use the device identity authentication feature for authentication based on the device identity and its attributes, the device creates a new table called the device identity authentication table. Unlike other local authentication tables, the device identity authentication table does not contain information about a user but rather about the user’s device. The device identity authentication table serves as a repository for device identity information for all devices regardless of their authentication source. For example, it might contain entries for devices authenticated by Active Directory or third-party NAC authentication sources.

A device identity authentication table entry contains the following parts:

• The IP address of the device.

• The name of the domain that the device belongs to.

• The groups with which the device is associated.

• The device identity.

  The device identity is actually that of a device identity profile (referred to in the CLI as end-user-profile). This type of profile contains a group of attributes that characterize a specific individual device or a specific group of devices, for example, a specific type of laptop.

IPv6 addresses for user firewall module (UserFW) authentication allows IPv6 traffic to match any security policy configured for source identity. IPv6 addresses are supported for the following authentication sources:

• Active directory authentication table

• Device identity with Active Directory authentication

• Local authentication table

• Firewall authentication table

Device Identity Information from Windows Active Directory for Network Access Control

You can use the device identity authentication feature to control access to your network resources based on the identity and attributes of the device used rather than the user identity. Information about a device is stored in the device identity authentication table. You can specify the name of a device identity profile that contains the device attributes in the source-end-user-profile field of a security policy. If all conditions are met, the security policy’s actions are applied to traffic issuing from that device.

For you to be able to use device identity profiles in security policies, the SRX Series Firewall or NFX Series device must obtain the device identity information for authenticated devices. The device creates the device identity authentication table to use to store device identity entries. It searches the table for a device match when traffic arrives from a device. This topic considers the process followed when Active Directory is used as the authentication source.

An Active Directory domain controller authenticates users when they log in to the domain, and it writes a record of that event to the Windows event log. It also writes a record to the event log when a user logs out of the domain. The domain controller event log provides the device with information about authenticated devices that are currently active in the domain and when those devices are logged out from it.

The UserID daemon takes the following actions:

1. It reads the Active Directory domain controller event logs to obtain the IP addresses of devices logged into the domain and authenticated by Windows.

   The UserID daemon in the device 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 domain controller in an Active Directory domain. Using event log information retrieved from the Active Directory controller, the process obtains the IP addresses of active Active Directory devices. The process monitors Active Directory event log changes using the same WMI DCOM interface to adjust its device identity information in its local authentication table to reflect any changes made to the Active Directory server.

2. It uses the device IP addresses that it obtained from the event log to obtain information about the groups that a device belongs to. To obtain this group information, the device connects to the LDAP service in the Active Directory controller using the LDAP protocol for this purpose.

As a result of this process, the device is able to generate entries for the devices in the device identity authentication table. After it generates an entry for a device in the device identity authentication table, the device associates that entry with the appropriate user entry in its local Active Directory authentication table. You can then reference the device identity profile entries in security policies to control access to resources.

Behavior and Constraints

• The process of reading the event log consumes domain controller CPU resources which may lead to high CPU usage in the domain controller. For this reason, the Active Directory domain controller should have a high-performance configuration of at least 4 cores and 8 gigabytes of memory.

• The domain controller event log records a maximum length of 16 bytes of the device ID, including a null terminator. Therefore, the maximum length of the device ID that the device obtains from the domain controller is 15 bytes.

• If the domain controller clears the event log or if the data written to the event log is missing or delayed, the device identity mapping information might be inaccurate. If the firewall or NFX Series device is unable to read the event log or if it contains null data, the device reports an error condition in its own log.

• If the device identity information table reaches capacity, it cannot add new device identity entries. In that case, traffic from the device is dropped.

Device Identity XML Solution for Third-Party NAC Authentication Systems

Figure 2 shows the communication between the firewall and a third-party NAC authentication source that is used for device identity authentication. The firewall receives the device identity information from the NAC system and stores it in its local device identity authentication table. A security policy that specifies a device identity profile is applicable to one or more devices. If a device matches the device identity profile and other parts of the security policy, the security policy is applied to traffic issuing from that device.

Use of a device identity profile in a security policy is optional. If no device identity profile is specified in the security policy’s source-end-user-profile field, “any” profile is assumed. However, you can not use the keyword “any” in the source-end-user-profile field of a security policy. It is a reserved keyword.

Platform-Specific WMIC Behavior

Platform-Specific Probe Rate Behavior