Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Understanding Enforcement of ClearPass User and Group Authentication on the SRX Series Devices

This topic describes how the SRX Series device enforces user and group authentication when a user attempts to access a resource. It also explains how the SRX Series device handles information in the ClearPass authentication table user entries when a security policy that references a group in a user entry is removed. Understanding that process will help you troubleshoot issues related to group identity and give you insight into changes in the ClearPass authentication table user entries.

Understanding How the SRX Series Device Manages the ClearPass Authentication Table

The integrated ClearPass authentication and enforcement feature enables the SRX Series device and the Aruba ClearPass Policy Manager (CPPM) to collaborate in protecting your company’s resources. It enables the SRX Series device to apply firewall security policies to user traffic and to control user access to protected resources based on user or group identity. To ensure the identity of the user, the SRX Series device relies on authenticated user information that it receives from the CPPM.

It is useful to understand how the SRX Series device gets authenticated user identity information from the CPPM, generates entries in its ClearPass authentication table, and manages those entries in relation to security policies and user events. Understanding these processes will help you to quickly identify and resolve related problems.

This topic focuses on:

  • How the SRX Series device obtains user identity information from the CPPM and manages it, and how you can use this information in security policies.
  • How security policies that reference a group as the source (source-identity) have bearing on the groups listed in user entries in the ClearPass authentication table. Groups that are referenced by security policies are referred to as interested groups.

User Authentication Entries in the ClearPass Authentication Table

In their collaboration, ClearPass acts as the authentication source for the SRX Series device. The CPPM sends to the SRX Series device identity information about users that it has authenticated. The UserID daemon process in the SRX Series device receives this information, processes it, and synchronizes it to the Packet Forwarding Engine side in the independent ClearPass authentication table that is generated for this purpose.

As administrator of the SRX Series device, you can use the authenticated user identity information in security policies to control access to your protected resources and the Internet.

The collection of user identity information that the SRX Series device obtains from the CPPM and uses to create entries in its global routing engine authentication table that is synchronized to its individual ClearPass authentication table is referred to as a mapping, or, more commonly, an IP-user mapping because the username and the related group list are mapped to the IP address of the user’s device.

Note: For each user authentication entry in the ClearPass authentication table, a group list identifies the groups that a user belongs to in addition to other information such as the posture token which indicates state of the device, such as whether it is healthy.

You can use a username or a group name in security policies to identity a user and not rely directly on the IP address of the device used, because the IP address of the device is tied to the username and its groups in the ClearPass authentication table entry.

Note: For each user entry, the number of groups, or roles, in the entry cannot exceed 200. After the capacity is reached, additional roles are discarded and the following syslog message is sent.

userid_get_and_check_adauth_num: src_ip ip-address user domain:user dropped.record numrecord-number has arrived max num of db

The CPPM posts user information to the SRX Series device in the following format. The SRX Series device does not use all of this information.

<userfw-entries><userfw-entry><source>Aruba ClearPass</source><timestamp>2016-01-29T03:18:10Z</timestamp><operation>logon</operation><IP>4.0.0.110</IP><domain>my-company-domain</domain><user>user1</user><role-list><role>human-resources-grp</role><role>[User Authenticated],/role></role-list><posture>HEALTHY</posture><device_category>Computer</device_category></userfw-entry></userfw-entries>

Here is the format for a ClearPass authentication table entry for a user, followed by an example entry and a description of its components.

IP-address, domain, user, user-group-list

In the following example, the user belongs to two groups, the human-resources-grp group and the posture-healthy group. The SRX Series device converts the posture information from the CPPM to a group name. You might configure a security policy that allows all users access to the marketing server if their devices belong to the posture-healthy group (role).

192.168.0.2, my-company-domain, lin, human-resources-grp, posture-healthy
  • IP address

    This is the IP address of the device used.

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

    In this example, the domain name is “my-company-domain.” The default domain name GLOBAL is used if a domain name is not provided.

  • The username

    The username is the user’s login name used to connect to the network, which, in this example, is lin.

    This name is constant regardless of the device used.

    When you configure a security policy whose source-identity tuple identifies the source of the traffic by username or group name, not by the IP address of the device used, it is as if the security policy were device independent; it applies to the user’s activity regardless of the device used.

  • One or more groups that a user belongs to

    It is here where the concept of interested groups and their relationship to security policies comes into play. An interested group is a group that is referenced in a security policy. The concept of interested groups is covered later in this topic.

Note that if a user is connected to the network using multiple devices, there might be more than one IP-user mapping for that user. Each mapping would have its own set of values—that is, domain name and group-list—in conjunction with the username and IP address.

For example, the following three IP address-to-username mappings might exist for the user abe who is connected to the network using three separate devices:

110.208.132.23 abe, marketing-grp, posture-healthy192.168.1.1 abe, marketing-grp, posture-transition202.38.11.33 abe, marketing-grp, posture-unknown

Assume that the SRX Series device receives a logout message for 110.208.132.23, abe. The following partial user authentication entry shows that the user abe is now logged in to the network using only two devices:

192.168.1.1 abe, marketing-grp, posture-transition202.38.11.33 abe, marketing-grp, posture-unknown

Communication Between ClearPass and the SRX Series Device

Here is a summary of how the SRX Series device and ClearPass communicate:

  • A user joins the company network via a wired or wireless LAN.
  • The CPPM authenticates the user.
  • The CPPM initiates a secure connection with the SRX Series device using the integrated Web API.
  • The SRX Series UserID daemon gets the full IP-user mapping from the CPPM. For each authenticated user, the UserID daemon generates an entry in the Routing Engine authentication table.

    The Routing Engine authentication table is common in that it holds authentication entries based on information from other authentication sources in addition to ClearPass. For example, it might also hold entries for users authenticated by Microsoft Active Directory.

  • The UserID daemon synchronizes the user authentication information from the Routing Engine authentication table to the ClearPass authentication table on the Packet Forwarding Engine. The ClearPass authentication table is dedicated to holding only ClearPass authentication information. See Figure 1.

    Figure 1: User Information from the CPPM to the SRX Series Device Routing Engine Synchronized to the ClearPass Authentication Table

    User Information from the CPPM
to the SRX Series Device Routing Engine Synchronized to the ClearPass
Authentication Table

The SRX Series device uses the authenticated user identity information in the following process. When a user attempts to access an internal, protected resource or the Internet, the SRX Series device:

  • Checks the traffic generated by the user for a matching security policy. The source traffic must match all of the tuples specified in the security policy. The match includes the source-identity field, which specifies a username or a group name.

    To identify a match, the SRX Series device compares the username or the group name with the source-identity specification that is configured in a security policy, along with all other security policy values.

  • Checks the ClearPass authentication table for an authentication entry for the user, if a security policy match was found.

    If it does not find an entry in the ClearPass authentication table, the SRX Series device checks other local authentication tables, in the order that you specified, until a match is found. However, it does not check other local authentication tables if the user query function is configured. See Understanding the Integrated ClearPass Authentication and Enforcement User Query Function.

    Note: The SRX Series device can query the CPPM for individual user information, under certain circumstances, when it has not already received that information from the CPPM. This feature is referred to as user query.

Figure 2 illustrates the connection and communication between the SRX Series device and the CPPM. It also shows the paths entailed in authenticating users and allowing them access to the Internet and internal, protected resources.

Figure 2: ClearPass and SRX Series Device Communication and User Authentication Process

ClearPass and SRX Series
Device Communication and User Authentication Process

As Figure 2 depicts, the following activity takes place:

  1. The CPPM initiates a secure connection with the SRX Series device using the Web API.
  2. Three users join the network and are authenticated by the CPPM.
    • A tablet user joins the network across the corporate WAN.
    • A smartphone user joins the network across the corporate WAN.
    • A wireless laptop user joins the network from a wired laptop connected to a Layer 2 switch that is connected to the corporate LAN.
  3. The CPPM sends the user authentication and identity information for the users who are logged in to the network to the SRX Series device in POST request messages using the Web API.

    When traffic from a user arrives at the SRX Series device, the SRX Series device:

    • Identifies a security policy that the traffic matches.
    • Locates an authentication entry for the user in the ClearPass authentication table.
    • Applies the security policy to the traffic after authenticating the user.
  4. Traffic from the smartphone user who is requesting access to an internal, protected resource arrives at the SRX Series device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series device allows the user connection to the protected resource.
  5. Traffic from the wired laptop user who is requesting access to a protected resource arrives at the SRX Series device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series device allows the user connection to the resource.
  6. Traffic from the tablet user who is requesting access to the Internet arrives at the SRX Series device. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series device allows the user connection to the Internet.

Understanding Domains and Interested Groups

How the user identity group information is managed on the SRX Series device is dominated by two concepts:

  • Domain group

    The SRX Series device follows the usual course in regard to how it handles usernames in domain namespaces. It makes use of the namespace to distinguish names that are the same–such as admin—but that are from different sources and are in different domains. Because they belong to different domains, the names are not in conflict.

    Any group that is part of an IP-user mapping will always belong to a domain, whether that domain is a specific domain or the GLOBAL domain. If a domain name is not specified in the IP-user mapping, then the GLOBAL domain is assumed.

    Table 1 illustrates how the domain for a group is determined, based on the IP-user mapping information obtained from the CPPM.

    Table 1: Assigning a Domain to a Group

    Does the IP-User Mapping Contain a Domain Name?

    What Domain Is Applied to the Group?

    No

    For example:

    IP, , user1, group-list

    The second comma serves as a placeholder for the domain name and the GLOBAL domain is applied.

    Groups included in group-list belong to the GLOBAL domain.

    Yes

    For example:

    IP, domain1, user1, group-list

    Note: In this example, the IP-user mapping specifies the domain name as domain1.

    The domain name, domain1, is included in the IP-user mapping from the CPPM, and it is used. It is retained in the entry for the authenticated user in the ClearPass authentication table on the Packet Forwarding Engine.

  • Interested group

    A group qualifies as an interested group if it is referenced by a security policy–that is, if it is specified in a policy’s source-identity field. On the Routing Engine authentication table, each user entry contains a group referenced by a policy list that identifies the names of the groups for which a security policy exists. If a group included in a user entry is not currently used in a security policy, it is not included in this list. A group can move in and out of the groups referenced by a policy list.

    • Interested group lists

      An interested group list, or a list of groups referenced by policies, is a subset of overall groups. It is the intersection of the group list in a user authentication entry and the source-identity list for security policies. That is, any group included in a ClearPass authentication table user entry qualifies as an interested group. The Routing Engine synchronizes to the user entry in the ClearPass authentication table on the Packet Forwarding Engine only those groups that are referenced by security policies.

      Here is how it works:

      • The UserID daemon gets the full IP-user role (group) mapping from the CPPM.
      • For each group, the UserID daemon identifies whether it is an interested group by determining if there is a security policy that references it. Any qualifying groups are included in the groups referenced by a policy list on the Routing Engine. The UserID daemon synchronizes to the user entry in the ClearPass authentication table on the Packet Forwarding Engine interested groups along with the rest of the user authentication and identity information.

      The interested groups list for a user entry on the Routing Engine can change, based on the following events:

      • A new security policy is configured that references a group included in the user entry on the Routing Engine but that is not already in the entry’s referenced groups list.
      • A currently configured security policy that references a group in its source-identity is deleted.

      Consider the following example:

      • Assume that the CPPM posted the following information for two users to the SRX Series device:
        10.1.1.1, abe, group1, group2, group3, group4, healthy10.4.8.1, john, group1, group5, healthy
      • After the SRX Series device maps the posture, defining it as a group, the two user entries in the SRX Series device Routing Engine authentication table appear as follows:
        10.1.1.1, abe, group1, group2, group3, group4, posture-healthy10.4.8.1, john, group1, group5, posture-healthy
      • Assume that several security policies include source-identity fields that reference one of the following: group1, group3, posture-healthy.

        The intersection of the preceding sets—the original group list and the list of security policies that refer to the groups—results in the following interested groups list:

        • For the user john, the groups referenced by policy list includes group1 and posture-healthy.
        • For the user abe, the groups referenced by policy list includes group1, group3, and posture-healthy.

      Now suppose that the security policy whose source-identity field specified group1 was deleted. The groups referenced by policy lists for the user authentication entries for the two users—john and abe—would be changed, producing the following results:

      • For the user John, the list would include only posture-healthy.
      • For the user Abe, the list would include group3 and posture-healthy.

    Table 2 shows how a security policy that references a group affects the ClearPass authentication table. It also shows the effect on the ClearPass authentication table when a group is not referenced by a security policy, and therefore is not an interested group.

    Table 2: Interested Groups: Effect on the ClearPass Authentication Table

    Security Policies Configuration and Modification

    Resulting Effect on ClearPass Authentication Table Packet Forwarding Engine Entries

    Case 1:

    The SRX Series device gets the IP-user mapping for a user from the CPPM.

    None of the groups in the user mapping are referenced by security policies.

    IP-user mapping from the CPPM:

    12.1.1.1, ,user1, g1, g2, g3, g4

    The user authentication entry written to the ClearPass authentication table in the Packet Forwarding Engine for this user does not contain any groups.

    12.1.1.1 , ,user1

    Case 2:

    The SRX Series device gets the IP-user mapping for a user from the CPPM. It checks the groups list against the security policies list and finds that two of the groups are referenced by security policies.

    IP-user mapping on the Routing Engine:

    12.1.1.2, domain1, user2, g1, g2, g3, g4

    The user authentication entry written to the ClearPass authentication table on the Packet Forwarding Engine for this user includes the following groups that are included in the groups referenced by the policy list on the Routing Engine:

    12.1.1.2, domain1, user2, g2, g4

When a User Has Already Been Authenticated By Another Source

It can happen that the SRX Series device Routing Engine authentication table and the individual Packet Forwarding Engine Microsoft Active Directory table, for example, contain an entry for a user who was authenticated by Active Directory. As usual, the CPPM sends the IP-user mapping for the user to the SRX Series device. The SRX Series device must resolve the problem because its Routing Engine authentication table is common to both Active Directory and ClearPass.

Here is how the SRX Series device handles the situation:

  • On the Routing Engine authentication table:
    • The SRX Series device overwrites the Active Directory authentication entry for the user in its common Routing Engine authentication table with the newly generated one from the IP-user mapping for the user from the CPPM.

      There is now no IP address or username conflict.

  • On the Packet Forwarding Engine:
    • The SRX Series device deletes the existing Active Directory authentication entry for the user from the Active Directory authentication table.

      This will delete active sessions associated with the IP address.

    • The SRX Series device generates a new entry for the CPPM-authenticated user in the Packet Forwarding Engine ClearPass authentication table.

      Traffic associated with the IP-user mapping entry will initiate new sessions based on user authentication in the ClearPass authentication table.

Related Documentation

Modified: 2016-05-01