Integrated User Firewall Overview

Integrated User Firewall and Authentication Sources

The SRX Series Firewall 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 Firewalls in an environment, supporting up to 2 domains, and up to 20 domain controllers. For deployments with 3 or more SRX Series Firewalls, 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 Firewalls.

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

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

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

3. 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 Firewalls, 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 Firewall. The domain controller might also act as the LDAP server.

Figure 1: Scenario for Integrated User Firewall

The SRX Series Firewall 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 Firewall 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 Firewalls 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 Firewall 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.

Limitations

• Windows Active Directory controllers earlier than Windows 2003 are not supported.

• Tracking the status of non-Windows Active Directory users is not supported.

• For user firewall (UserFW), the shared model supports logical system and tenant system. All logical system users in a shared model can share UserFW configuration and authentication entries with the root logical system. Authentication entries in the user logical system share attributes with those in the root logical system, such as authentication entry timeout and invalid authentication entry timeout.

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

Active Directory Authentication as an Authentication Source

On an SRX Series Firewall 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 Virtual Firewall 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 Firewalls and NFX Series devices. Platform support depends on the Junos OS release in your installation.

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:

To display Active Directory authentication entries, along with their state information, use the following command:

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.

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:

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

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