Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Control Network Access Using Device Identity Authentication

 

Based on identity and attributes of the device you can control the access to your network by configuring device identify feature.

Understanding Access Control to Network Resources Based on Device Identity Information

You can use the integrated user firewall device identity authentication feature to control access to network resources based on the attributes, or characteristics, of the device used. After you configure device identity authentication feature, you can configure security polices that allow or deny traffic from the identified device based on the policy action.

Why Use Device Identity Information 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. For example, you might not know the identity of the user. You might allow your users to use their own devices (BYOD) to access network resources and you do not want to use captive portal authenticate. Some companies might have older switches that do not support 802.1, or they might not have a network access Control (NAC) system. The integrated user firewall 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.

Background

Fundamentally, 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. If Microsoft Windows Active Directory is the authentication source, the device retrieves the device information from the Active Directory domain controller. In the case of third-party Network Access Control (NAC) systems, the device receives the information from the authentication source through the RESTful Web services API that the device exposes to it for this purpose. After the device obtains the device identity information, it creates an entry for it in the device identity authentication table.

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.

In broad terms, 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:

    • Active Directory—For Active Directory, 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 NAC systems—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 SRX Series device.

      The API has a formal XML structure and restrictions that the authentication source must adhere to in sending this information to the device.

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

    After the SRX Series device 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 SRX Series device allows only authentication source to be used at a time to constrain the demand on the system to process information.

The device identity authentication feature supports various types of authentication systems, such as Active Directory or a third-party authentication source. That is, the device identity authentication feature provides a generic solution that stores device identity information in the same table regardless of the authentication source.

Starting with Junos OS Release 17.4R1, the SRX Series supports IPv6 addresses for user firewall (UserFW) authentication. The device identity table can include entries with IPv6 addresses when active directory is the authentication source.

Figure 1 shows the communication between the SRX Series and a third-party NAC authentication source that is used for device identity authentication. The SRX Series device 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.

Figure 1: Using a Third-Party Network Access Control (NAC) System for Device Identity Authentication
Using a Third-Party Network Access Control
(NAC) System for Device Identity Authentication

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.

Understanding the Device Identity Attributes and Profiles for the Integrated User Firewall Device Identity Authentication Feature

The device identity profile, referred to in the CLI as the end-user-profile, is a key component of the integrated user firewall device identity authentication feature. It identifies the device and specifies its attributes. The device identity authentication feature allows you to control access to your network resources based on the identity of the device used and not the identity of the user of that device. This feature supports Microsoft Windows Active Directory and third-party network access control (NAC) systems as authentication sources.

This topic focuses on device identity and the device identity profile.

Device Identity

The device identity essentially consists of the IP address of the device, its name, its domain, and the groups that the device belongs to.

For example, the following output shows information about the device, which is referred to from the device identity profile.

This example shows that the device identity authentication table contains entries for two devices. For each entry, it shows the IP address of the device, the name assigned to the device, and the groups that the device belongs to. Note that both devices belong to the group grp4.

Device Identity Profile Contents

The device identity profile is a collection of attributes that are characteristics of a specific group of devices, or of a specific device, depending on the attributes configured in the profile. The Packet Forwarding Engine of the device maps the IP address of a device to the device identity profile.

A device identity profile specifies the name of the device and information that includes the IP address of the device, groups to which the device belongs, and attributes of the device which are collectively referred to as the host attributes.

Note

The only attributes that you can configure using the CLI are the name of the device and the groups that it belongs to. The other attributes are configured using the third-party RESTful web services API, which is used by NAC systems or Active Directory LDAP.

When traffic from a device arrives at the SRX Series device or NFX Series device, the device obtains the IP address of the device from the first packet of the traffic and uses it to search the device identity authentication table for a matching device identity entry. Then it matches that device identity profile with a security policy whose source-end-user-profile field specifies the device identity profile name. If a match is found, the security policy is applied to traffic issuing from the device.

The same device identity profile can also apply to other devices sharing the same attributes. However, for the same security policy to apply, the device and its traffic must match all other fields in the security policy.

A device identity profile must contain the domain name. It might contain more than one set of attributes, but it must contain at least one. Consider the following two sets of attributes that belong to the profile called marketing-main-alice.

The profile contains the following set of attributes:

  • alice-T430, as the name of the device.

  • MARKETING and WEST-COAST, as the groups that the device belongs to.

  • example.net as the name of the domain that it belongs to.

The profile also the following attributes that characterize the device:

  • laptop, as the category of the device (device-category)

  • Lenovo, as the device vendor (device-vendor)

  • ThinkPad T430, as the type of device (device-type)

In cases such as the marketing-main-alice profile that includes the name given to the device, the profile applies exclusively to that device.

However, now suppose that another profile called marketing-west-coast-T430 was configured and that it contains the same attributes as the marketing-main-alice profile with one exception: the name given to the device in the marketing-main-alice profile was not included as an attribute in the marketing-west-coast-T430 profile. In this case, the attributes contained in the profile now make up a group profile. Application of the profile is widened to include all Lenovo ThinkPad T430 devices (which are laptops) that fit the rest of the characteristics, or attributes, defined in the profile.

Devices are covered by the profile if all other attributes match: devices that belong to either the MARKETING or WEST-COAST groups, which the marketing-west-coast-T430 profile specifies as its groups, or to both groups, match the profile.

As mentioned previously, a device identity profile can contain more than one group. A device can also belong to more than one group.

To illustrate further, note that the group device identity profile called marketing-west-coast-T430 also applies to the device called alice-T430 because that device belongs to both the MARKETING and the WEST-COAST groups and it matches all other attributes defined in the profile. Of course, the marketing-main-alice device identity profile still applies to the device called alice-T430. Therefore, the device called alice-T430 belongs to at least two groups, and it is covered by at least two device identity profiles.

Suppose that another profile called marketing-human-resources was defined with all of the attributes of the marketing-west-coast-T430 device identity profile but with these differences: the new device identity profile includes a group called HUMAN-RESOURCES and it does not include the group called WEST-COAST. However, it does contain the MARKETING group.

Because the device called alice-T430 belongs to the MARKETING group, which remains as a group in marketing-human-resources profile, the alice-T430 device also matches the marketing-human-resources device identity profile. Now the alice-T430 device matches three profiles. If the names of any of these profiles is specified in a security policy’s source-end-user-profile and the alice-T430 device matches all of the other fields in the security profile, then that profile’s action is applied to traffic from that device.

The previous examples of device identity profiles illustrate the following points:

  • A profile can be defined to identify only one device or it can be defined to apply to many devices.

  • A device identity profile can contain more than one group to which a given device belongs.

  • A device can match more than one device identity profile by matching the characteristics, or attributes, including at least one of the groups, configured for the profile.

The flexible use of device identity profiles will become evident when you configure security policies that are designed to include the source-end-user-profile field, in particular when you want the policy’s action to be applied to a number of devices.

Predefined Device Identity Attributes

The SRX Series device provides the predefined device identity policy attributes that are configured using the third-party RESTful web services API, which is used by NAC systems or Active Directory LDAP.

  • device-identity

  • device-category

  • device-vendor

  • device-type

  • device-os

  • device-os-version

You specify values for these attributes in a device identity profile.

Characteristics of Device Identity Profiles, and Attributes and Target Scaling

This section describes how the SRX Series and NFX Series devices treat device identity attributes and profiles. It also gives device-independent and device-dependent scaling numbers for these entities.

The following attribute and profile characteristics apply to their use on all supported SRX Series and NFX Series devices.

  • The maximum length of the following entities is 64 bytes: device identity profile names (referred to in the CLI as end-user-profile) attribute names, attribute-values.

  • You can not overlap values in a range if you configure more than one digital value range for the same attribute.

  • When the device matches a device identity profile to a security policy, all of the attributes in the profile are taken into account. Here is how they are treated:

    • If the device identity profile contains multiple values for an attribute, the values of that attribute are treated individually. It is said that they are ORed.

      For the security policy to be applied to the device, the following conditions must be met. The device must match:

      • One of the values for each attribute that has multiple values.

      • The rest of the attribute values specified in the device identity profile.

      • The security policy field values.

    • All individual attributes that have a single value are treated separately and considered together as a collection of values—that is, the AND operation is applied to them. The device uses its standard policy-matching criteria in handling these attributes.

Table 1 shows the platform-independent scaling values used in the device identity authentication feature.

Table 1: Platform-Independent Scaling

Item

Maximum

Values per attribute

20

Attributes per profile

100

Device identity profile specification per security policy (source-end-user-profile)

1

Table 2 shows the platform-dependent scaling values used in the device identity authentication feature..

Table 2: Platform-Dependent Scaling

Platform

Maximum Number of Profiles

Maximum Total Number of Attribute Values

SRX5000 Series

4000

32000

SRX Series 1500

1000

8000

SRX Series 550M

500

4000

SRX Series 300 and SRX Series 320

100

1000

SRX Series 340 and SRX Series 345

100

1000

SRX Series 4100-4XE

1000

8000

SRX Series 4200-8XE

2000

16000

vSRX

500

4000

NFX150

100

1000

The following changes to device identity profiles and their use in security policies do not cause the device to perform a session scan:

  • Updates to a profile which is referenced in a security policy.

  • Updates to the profile configuration.

  • Updates to attributes that are made through the RESTful web services API, which is used by NAC systems, or Active Directory LDAP.

Understanding the Device Identity Authentication Table and Its Entries

The device contains a number of local authentication tables used for user authentication for various purposes. For example, the device contains a local Active Directory authentication table for user authentication when Microsoft Windows Active Directory is used as the authentication source.

When you configure the device to use the integrated user firewall 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.

To gain a complete view of the device identity authentication feature, it helps to understand this table, its contents, and its relationship to other entities.

This topic covers the device identity authentication table and its device entries, and how the table contents change based on several factors.

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. Moreover, unlike user authentication tables, it does not contain information about devices authenticated by one authentication source. Rather, it 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.

Starting in Junos OS 17.4R1, the SRX Series device supports IPv6 addresses for user firewall module (UserFW) authentication. This feature allows IPv6 traffic to 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 UserFW module ignored the IPv6 traffic.

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

Why the Device Identity Authentication Table Content Changes

The device identity entries in the device identity authentication table are changed when certain events occur: when the user authentication entry with which the device identity entry is associated expires, when security policy changes occur in regard to referencing a group that the device belongs to, when the device is added to or removed from groups, or when groups that it belongs to are deleted and that change is made to the Windows Active Directory LDAP server.

  • When the User Identity Entry with Which a Device Identity Entry Is Associated Expires

    When the device generates an entry for a device in the device identity authentication table, it associates that entry with a user identity entry in a local authentication table for the specific authentication source that authenticated the user of the device, such as Active Directory. That is, it ties the device identity entry in the device identity authentication table to the entry for the user of the device in the user authentication table.

    When the user authentication entry with which the device identity entry is associated expires and is deleted from the user authentication table, the device identity entry is deleted silently from the device identity authentication table. That is, no message is issued to inform you of this event.

  • When Security Policy Changes Occur in Regard to Referencing a Group to Which the Device Belongs

    To control access to network resources based on device identity, you create a device identity profile that you can refer to in a security policy. In addition to other attributes, a device identity profile contains the names of groups. When a device identity profile is referenced by a security policy, the groups that it contains are referred to as interested groups.

    A group qualifies as an interested group if it is referenced by a security policy—that is, if it is included in a device identity profile that is specified in the source-end-user-device field of a security policy. If a group is included in a device identity profile that is not currently used in a security policy, it is not included in the list of interested groups. A group can move in and out of the list of groups referenced by security policies.

  • When a Device Is Added to or Removed from a Group or a Group Is Deleted

    To keep the device identity entries in the local device identity authentication table current, the SRX Series or NFX Series monitors the Active Directory event log for changes. In addition to determining whether a device has logged out of or in to the network, it can determine changes to any groups that the device might belong to. When changes occur to the groups that a device belongs to—that is, when a device is added to or removed from a group or the group is deleted—the device modifies the contents of the affected device entries in its own device identity authentication table to reflect the changes made in the Microsoft Windows Active Directory LDAP server.

The device identity authentication table is updated according to changes to groups with which the device is associated in the LDAP server, as illustrated in Table 3.

Table 3: Group Changes for Devices in the Active Directory LDAP and the SRX Series or NFX Series Response

Changes Made to LDAP

SRX Series or NFX Series LDAP Message and UserID Daemon Action

Group information for a device has changed. The device has been added to or removed from a group, or a group that the device belongs to has been deleted.

The Active Directory LDAP module sends notification of the change to the SRX Series or NFX Series UserID daemon, directing it to revise information in its local device identity authentication table.

The device processes these messages every 2 minutes.

The device entry in LDAP is deleted.

The Active Directory LDAP module sends notification of the change to the UserID daemon, directing it to revise information in its local device identity authentication table.

The device processes these messages every 2 minutes.

The SRX Series or NFX Series device UserID daemon is informed of the changes. Whether or not a group that a device belongs to is specified in a security policy has bearing on what information is stored in device identity authentication table entries for the affected device. Table 4 shows the activity that occurs when a group is added to or deleted from the Active Directory LDAP.

Table 4: Changes to Device Identity Entries Based on Security Policy Specifications

Device Identity Profile Changes

Device-Group Mapping Behavior

SRX Series or NFX Series UserID Daemon Response

A new group that was added to the Active Directory LDAP is added to the SRX Series device identity profile.

The device gets the list of devices that belong to the new group and its subgroups from the Active Directory LDAP server. It adds the list to its local LDAP directory.

The UserID daemon determines whether the device identity authentication table includes entries for the set of affected devices. If so, it updates the group information for these entries.

For example, here is the entry for device1 before it was updated to include the new group and after the group was added:

  • device1, g1

  • device1, g1, g2

A group is deleted from the Active Directory LDAP. The device deletes the group from the device identity profile.

The device gets the list of devices that belong to the deleted group from its local LDAP database.

It deletes the device-group mapping from the local LDAP directory.

The UserID daemon checks the device identity authentication table for entries that belong to the group. It removes the group from affected entries.

For example, here is the entry for device1 before the group was deleted and after the group was deleted:

  • device1, g1, g2

  • device1, g1

Table 5 elaborates on the contents of device authentication entries for several devices that are affected by deletion of a group.

Table 5: Changes to Device Identity Authentication Table Resulting from LDAP and Security Policy Changes

Changes to Device identity Authentication Table Entries

IP Address

Device Information

Group

Original Entries

192.0.2.10

device1

group1, group2

192.0.2.11

device2

group3, group4

192.0.2.12

device3

group2

Same Entries After group2 Is Deleted

192.0.2.10

device1

group1

192.0.2.11

device2

group3, group4

192.0.2.12

device3

This entry no longer contains groups.

Security Policy Matching and Device Identity Profiles

The device follows the standard rules for matching traffic against security policies. The following behavior pertains to the use of a device identity profile in a security policy for determining a match:

  • Use of a device identity profile in a security policy is optional.

    • If no device identity profile is specified in the source-end-user-profile field, any profile is assumed.

    • You cannot use the keyword any in the source-end-user-profile field of a security policy.

      If you use the source-end-user-profile field in a security policy, you must reference a specific profile. The device from which the access attempt is issued must match the profile’s attributes.

  • Only one device identity profile can be specified in a single security policy.

  • A security policy rematch is triggered when the source-end-user-profile field value of the security policy is changed. No rematch is triggered when an attribute value of a profile is changed.

Understanding How the SRX Series Obtains the Authenticated Device Identity Information From Windows Active Directory for Network Access Control

You can use the integrated user firewall 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 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 SRX Series 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.

Understanding the Device Identity XML Solution for Third-Party NAC Authentication Systems

The integrated user firewall device identity authentication feature enables you to control access to network resources based on the identity of a device. You can use one of the following device identity solutions:

  • Microsoft Active Directory as the authentication source.

    If your environment is set up to use Microsoft Active Directory, the SRX Series or NFX Series device obtains the device IP address and groups from the Active Directory domain controller and LDAP service.

  • Network access control (NAC) authentication system.

    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 SRX Series or NFX Series device. The RESTful Web services API enables you to send the device information to the device in a formal XML structure.

    Warning

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

XML Web API Implementation on SRX Series and NFX Series Devices

The RESTful Web services API enables you to send the device identity information to the SRX Series or NFX Series device in a formal XML structure. It allows your NAC solution to integrate with the device and efficiently send the device information to it. You must adhere to the formal structure and restrictions in sending information to the device using the API.

Ensuring the Integrity of Data Sent from the NAC Service to the SRX Series or NFX Series Device

The following requirements ensure that the data sent from the NAC service is not compromised:

  • The API implementation is restricted to processing only HTTP/HTTPS POST requests. Any other type of request that it receives generates an error message.

  • The API daemon analyzes and processes HTTP/HTTPS requests from only the following dedicated URL:

    /api/userfw/v1/post-entry
  • The HTTP/HTTPS content that your NAC solution posts to the SRX Series device must be consistently formatted correctly. The correct XML format indicates a lack of compromise, and it ensures that user identity information is not lost.

Data Size Restrictions and Other Constraints

The following data size restrictions and limitations apply to the data posted to the SRX Series or NFX Series device:

  • The NAC authentication system must control the size of the data that it posts. Otherwise, the Web API daemon is unable to process it. The Web API daemon can process a maximum of 2 megabytes of data.

  • The following limitations apply to XML data for role and device posture information. The Web API daemon discards XML data sent to it that exceeds these amounts (that is, the overflow data):

    • The device can process a maximum of 209 roles.

    • The device supports only one type of posture with six possible posture tokens, or values. Identity information for an individual user can have only one posture token.

Example: Configuring the SRX Series Device Identity Feature in an Active Directory Environment

This example shows how to configure the integrated user firewall device identity authentication feature to control access to network resources based on the identity of an authenticated device, not its user. This example uses Microsoft Active Directory as the authentication source. It covers how to configure a device identity profile that characterizes a device, or set of devices, and how to reference that profile in a security policy. If a device matches the device identity and the security policy parameters, the security policy’s action is applied to traffic issuing from that device.

For various reasons, you might want to use the identity of a device for resource access control. For example, you might not know the identity of the user. Also some companies might have older switches that do not support 802.1, or they might not have a network access control (NAC) system. The 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 the device identity. You can control access for a group of devices that fit the device identity specification or an individual device.

Requirements

This example uses the following hardware and software components:

  • An SRX Series Services Gateway device running Junos OS Release 15.1X49-D70 or later.

  • Microsoft Active Directory with a domain controller and the Lightweight Directory Access Protocol (LDAP) server

    The Active Directory domain controller has a high-performance configuration of 4 cores and 8 gigabytes of memory.

    Note

    The SRX Series obtains the IP address of a device by reading the domain controller event log. The process that reads the event log consumes domain controller CPU resources, which might lead to high CPU usage. For this reason, the Active Directory domain controller should have a high-performance configuration of at least 4 cores and 8 gigabytes of memory.

  • A server on the internal corporate network.

Overview

Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, the SRX Series provides support for controlling access to network resources based on the identity of a device authenticated by Active Directory or a third-party network access control (NAC) system. This example uses Active Directory as the authentication source.

Note

You must configure the authentication source for this feature to work.

This example covers the following configuration parts:

  • Zones and their interfaces

    You must configure the zones to which the source and destination entities specified in the security policy belong. If you do not configure them, the security policy that references the device identity profile will be invalid.

  • A device identity profile

    You configure the device identity profile apart from the security policy; you refer to it from a security policy. A device identity profile specifies a device identity that can be matched by one or more devices. For Active Directory, you can specify only the device-identity attribute in the profile.

    In this example, the device-identity attribute specification is company-computers.

    Note

    The device identity profile is referred to as end-user-profile in the CLI.

  • A security policy

    You configure a security policy whose action is applied to traffic issuing from any device that matches the device identity profile attributes and the rest of the security policy’s parameters.

    Note

    You specify the name of the device identity profile in the security policy’s source-end-user-profile field.

  • Authentication source

    You configure the authentication source to be used to authenticate the device. This example uses Active Directory as the device identity authentication source.

    If Active Directory is the authentication source, the SRX Series obtains identity information for an authenticated device by reading the Active Directory domain’s event log. The device then queries the LDAP interface of Active Directory to identify the groups that the device belongs to, using the device’s IP address for the query.

    For this purpose, the device implements a Windows Management Instrumentation (WMI) client with Microsoft Distributed COM/Microsoft RPC stacks and an authentication mechanism to communicate with the Windows Active Directory controller in the Active Directory domain. It is the device wmic daemon that extracts device information from the event log of the Active Directory domain.

    The wmic daemon also monitors the Active Directory event log for changes by using the same WMI DCOM interface. When changes occur, the device adjusts its local device identity authentication table to reflect those changes.

    Starting with 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, you could assign only IPv4 addresses.

Topology

In this example, users who belong to the marketing-zone zone want to access resources on the internal corporate servers. Access control is based on the identity of the device. In this example, company-computers is specified as the device identity. Therefore, the security policy action is applied only to devices that fit that specification and match the security policy criteria. It is the device that is either granted or denied access to the server resources. Access is not controlled based on user identification.

Two SRX Series zones are established: one that includes the network devices (marketing-zone) and one that includes the internal servers (servers-zone). The SRX Series device interface ge-0/0/3.1, whose IP address is 192.0.2.18/24, is assigned to the marketing-zone zone. The SRX Series device interface ge-0/0/3.2, whose IP address is 192.0.2.14/24, is assigned to the servers-zone zone.

This examples covers the following activity:

  1. The SRX Series device connects to the Active Directory domain controller using the WMI DCOM interface to obtain information about devices authenticated by Active Directory.

    When a user logs in to the network and is authenticated, information about the user’s device is written to the event log.

  2. The SRX Series extracts the device information from the event log of the Active Directory domain controller.

  3. The SRX Series uses the extracted information to obtain a list of the groups that the device belongs to from the Active Directory LDAP server.

  4. The SRX Series creates a local device identity authentication table and stores the device identity information that it obtained from the domain controller and LDAP server in the table.

  5. When traffic from a device arrives at the SRX Series device, the SRX Series checks the device identity authentication table for a matching entry for the device that issued the traffic.

  6. If the SRX Series finds a matching entry for the device that is requesting access, it checks the security policy table for a security policy whose source-end-user-profile field specifies a device identity profile with a device-identity specification that matches that of the device requesting access.

  7. The matching security policy is applied to traffic issuing from the device.

Figure 2 show the topology for this example.

Figure 2: Topology for the Device Identity Feature with Active Directory as the Authentication Source
Topology for the Device Identity Feature
with Active Directory as the Authentication Source

Configuration

To configure the device identity feature in an Active Directory environment, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands to a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuring the Integrated User Firewall Device Identity Authentication Feature in an Active Directory Environment

Step-by-Step Procedure

This procedure includes the configuration statements required to configure the SRX Series device to support the device identity authentication feature in an Active Directory environment.

  1. Configure the interfaces to be used for the marketing-zone and the servers-zone.
  2. Configure the marketing-zone and the servers-zone and assign interfaces to them.
  3. Configure the authentication source to specify Microsoft Active Directory. You must specify the authentication source for the device identity feature to work. This is a required value.
  4. Configure the device identity specification for the device identity profile, which is also referred to as end-user-profile.
  5. Configure a security policy, called mark-server-access, that references the device identity profile called marketing-west-coast. The security policy allows any device that belongs to the marketing-zone zone (and that matches the device identity profile specification) access to the target server’s resources.
  6. Configure the SRX Series device to communicate with Active Directory and to use the LDAP service.

    To get the group information necessary to implement the device identity authentication feature, the SRX Series device uses the Lightweight Directory Access Protocol (LDAP). The SRX Series acts as an LDAP client communicating with an LDAP server. Typically, the Active Directory domain controller acts as the LDAP server. The LDAP module in the device, by default, queries the Active Directory in the domain controller.

Results

Enter show interfaces in configuration mode.

Enter show security zones in configuration mode.

Enter show services user-identification device-information end-user-profile in configuration mode.

Enter show services user-identification device-information authentication-source in configuration mode.

Enter show security policies in configuration mode.

Enter show services user-identification active-directory-access in configuration mode.

Enter show services user-identification active-directory-access domain example-net in configuration mode.

Verification

Verify the Device Identity Authentication Table Contents

Purpose

Verify that the device identity authentication table contains the expected entries and their groups.

Action

In this case, the device identity authentication table contains three entries. The following command displays extensive information for all three entries.

Enter show services user-identification device-information table all extensive command in operational mode to display the table’s contents.

Sample Output

Meaning

The table should contain entries with information for all authenticated devices and the groups that they belong to.

Release History Table
Release
Description
Starting with Junos OS Release 17.4R1, the SRX Series supports IPv6 addresses for user firewall (UserFW) authentication. The device identity table can include entries with IPv6 addresses when active directory is the authentication source.
Starting in Junos OS 17.4R1, the SRX Series device supports IPv6 addresses for user firewall module (UserFW) authentication. This feature allows IPv6 traffic to 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 UserFW module ignored the IPv6 traffic.