Control Network Access Using Device Identity Authentication

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.

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

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

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

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.

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.

When traffic from a device arrives at the SRX Series Firewall 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.

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

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 2 shows the platform-dependent scaling values used in the device identity authentication feature..

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.

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

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.

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 5 elaborates on the contents of device authentication entries for several devices that are affected by deletion of a group.

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.

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.

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:

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

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.