Aruba ClearPass

Benefits

• Quick and easy access to data that help to manage and maintain your networks, clients, and devices.

• Continuous monitoring and advance analytics that offer real-time visibility into your network.

How communication happens between the firewall and the ClearPass?

Why you need Aruba ClearPass with Enforcement Security?

1. Risk and Challenges—Use of company smartphones poses one of the biggest IT security risks to businesses.

   • Today’s network environments are more open to attacks of various kinds because they support anywhere, anytime, any device access, to a greater or lesser degree, and they allow a user to use multiple concurrently network-connected devices.

   • Attackers can gain access to nearby company-owned mobile devices and install malware on them that they can then use to capture data at any time.

   • Attackers can launch information-gathering ventures, stop business activity, and steal sensitive corporate data.

2. Need for Business—The proliferation of mobile devices and cloud services and securing them has become a fundamental strategic part of enterprise cybersecurity.

   • In a work environment that supports mobile devices, knowing the identity of the user is important.

   • An identity of the user provides IT administrators with improved advantage in identifying the source of the attack and stemming future potential attacks that follow the same strategy.

   • The ClearPass with enforcement security protects against malicious intrusions introduced through use of mobile devices and multiple concurrently connected devices.

3. Protection using ClearPass—The ClearPass with enforcement security can protect you against attacks and intrusions by allowing you to configure security policies that identify users by their usernames or by the groups that they belong to.

   • ClearPass identifies threats and attacks perpetrated against your network environment and provides this information to the CPPM.

   • As administrator of the CPPM, you can better align your security enforcement to protect against possible future attacks of the same kind.

   • If a user is logged in to the network with more than one device, you can keep track of their activity based on their identity and not only by their devices.

   • You can easily control their network access and any egregious activity on their behalf, whether intended or not.

How Aruba ClearPass with Enforcement Security works?

The Aruba ClearPass with enforcement security delivers the protection of the SCREENS, IDP and Content Security features to defend your network against a wide range of attack strategies. In addition to protecting the company’s network resources, the device can make available to the CPPM log records generated by these protective security features in response to attack or attack threats. Knowing about threats and specific attacks that have already occurred can help IT departments to identify noncompliant systems and exposed areas of the network. With this information, they can harden their security by enforcing device compliance and strengthening protection of their resources.

The ClearPass with enforcement security gives you granular control at the user level:

• As administrator of the device, you can now specify in the identity source parameter of identity-awaresecurity policies a username or a role (group) name that the CPPM posts to the device. You are no longer restricted to relying solely on the IP address of the device as a means of identifying the user. Honing in on the user of the device, rather than only the device, enhances your control over security enforcement.

• In addition to providing the SRX Series Firewall with authenticated user information, the CPPM can map a device type to a role and assign users to that role. It can then send that role mapping to the SRX Series Firewall. This capability allows you to control through security policies a user’s access to resources when they are using a specific type of device.

For example, suppose that the administrator of the CPPM configured a role called marketing-company-device and mapped to that role both company devices and members of the Marketing department. As administrator of the device, you could specify that role in a security policy as if it were a group. The security policy would then apply to all users mapped to the role, inherently controlling their network activity when they use that type of device type.

SRX Series Firewall security policies protect the company’s resources and enforce access control at a fine-grain level, taking advantage of the user authentication and identity information sent to the device from the CPPM. The CPPM acts as the authentication source. It uses its own internal RADIUS server to authenticate users. It can also rely on an external authentication source to perform the authentication for it, such as an external RADIUS server or Active Directory.

The CPPM authentication is triggered by requests from NAS devices such as switches and access controllers. The CPPM uses the XML portion of the RESTful Web services that the device exposes to it to send in POST request messages to the device authenticated user identity and device posture information.

The firewall and Aruba ClearPass simplify the complex and complicated security tasks required to safeguard company resources and enforce Internet access policy for mobile devices. This security is essential in a network environment that supports the mobile experience and that gives the user latitude to use a wide range of devices, including their own systems, smartphones, and tablets.

Integrity of Data Sent from ClearPass to the Firewall

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

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

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

• The HTTP/HTTPS content that the CPPM posts to the 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 CPPM:

• The CPPM must control the size of the data that it posts. Otherwise the Web API daemon is unable to process it. Presently the Web API 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 SRX Series Firewall can process a maximum of 209 roles.

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

  • The CPPM checks the health and posture of a firewall and it can send that information to the firewall as part of the user information that it posts.

  • You cannot define posture on the firewall. Also, firewall does not check posture information that it receives.

Posture States and the Posture Group

User, role, and posture token fields are distinct in the context of the CPPM. Each set of user identity information contains user and role (group) identity and a posture token. Because the SRX Series Firewall or NFX Series device supports only user and role (group) fields, the posture token value is mapped to a role by adding the prefix posture–. You can then use that role in a security policy as a group and that policy will be applied to all traffic that matches the policy.

The predefined posture identity states are:

• posture-healthy (HEALTHY)

• posture-checkup (CHECKUP)

• posture-transition (TRANSITION)

• posture-quarantine (QUARANTINE)

• posture-infected (INFECTED)

• posture-unknown (UNKNOWN)

How ClearPass Detect Threats and Attacks and Notifies the CPPM

When the firewall detect threat and attack events, the event is recorded in the firewall event log. The firewall uses syslog to forward the logs to the CPPM. The CPPM can evaluate the logs and take action based on matching conditions. As administrator of ClearPass, you can use the information from the firewall and define appropriate actions on the CPPM to harden your security.

Junos OS on the SRX Series Firewall generates over 100 different types of log entries issued by more than 10 of its modules. Among the firewall that generate threat and attack logs are SCREENS, IDP, and Content Security. To avoid overburdening the firewall and the log server, the ClearPass allows you to configure the firewall to send to the CPPM only attack and threat log entries that were written to the event log in response to activity detected by the SCREENS, IDP, and Content Security features.

You can set the following conditions to control the log transmission:

• A log stream filter to ensure that only threat and attack logs are sent.

• A rate limiter to control the transmission volume. The device log transmission will not exceed the rate-limiting conditions that you set.

For the CPPM to analyze the log information that the sends to it, the content must be formatted in a standard, structured manner. The firewall log transmission follows the syslog protocol, which has a message format that allows vendor-specific extensions to be provided in a structured way.

Threat and Attack Logs Sent to Aruba ClearPass

The firewall and enforcement feature collaborates with Aruba ClearPass in protecting a company’s resources against potential and actual attacks through use of attack and threat event logs. These logs that are generated by the SRX Series SCREENS, IDP, and Content Security components clearly identify the types of attacks and threats that threaten a company’s network security.

The firewall filters from the overall log entries the logs that report on threat and attack events, and it forwards these log entries to the ClearPass Policy Manager (CPPM) to be used in assessing and enforcing the company’s security policy. The SRX Series Firewall transmits the logs in volumes determined by the rate-limiting conditions that you set.

How ClearPass works with JIMS?

When a user gets authenticated by CPPM, the CPPM uses a Web API to push user or device information to a firewall. The firewall builds up the authentication entry or device information for the user, and the user traffic can pass-through the firewall based on security policy. When windows Active Directory client log on to domain, firewall obtains client’s user or device information from JIMS via batch query. The authentication table gets updated with entry provided by JIMS. The user traffic can pass-through the device based on security policy.

When both JIMS IP query and ClearPass user query are enabled, firewall always queries ClearPass first. If CPPM returns with IP-user mapping information, then the information is subsequently added to authentication table. If CPPM does not return the IP-user mapping information or if a firewall receives a response from CPPM without IP-user mapping, then the firewall queries JIMS to obtain IP-user or group mapping.

When the IP-user or group mapping is received from both JIMS and CPPM, firewall considers the latest authentication entries and overwrites the existing authentication entries.

You can set a delay-query-time parameter, specified in seconds, that allows the device to wait for a period of time before sending the query. The delay time should be the same value for ClearPass and JIMS. Otherwise, an error message is displayed and the commit check fails.

When the IP-user or group mapping is received from both JIMS and CPPM, the device considers the latest authentication entries and overwrites the existing authentication entries.

Different Scenarios of how ClearPass works with JIMS

A detailed explanation with scenarios of how ClearPass with JIMS works is as follows:

Domain Group

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

IP, , user1, group-list

IP, domain1, user1, group-list

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

  • After the device maps the posture, defining it as a group, the two user entries in the device Routing Engine authentication table appear as follows:

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

203.0.113.9, ,user1, g1, g2, g3, g4

203.0.113.9 , ,user1 

192.0.2.1, domain1, user2, g1, g2, g3, g4

192.0.2.1, domain1, user2, g2, g4

When a user has already been authenticated by another source

It can happen that the device Routing Engine authentication table and the individual Microsoft Active Directory authentication table on the Packet Forwarding Engine, 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 device. The device must resolve the problem because its Routing Engine authentication table is common to both Active Directory and ClearPass.

Here is how the device handles the situation:

• On the Routing Engine authentication table:

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

How the Firewall manages the ClearPass Authentication Table?

The firewall 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. ClearPass acts as the authentication source for the firewall. The CPPM sends to the firewall identity information about users that it has authenticated. The UserID daemon process in the firewall 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 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 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.

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.

User Authentication Entries in the ClearPass Authentication Table

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 firewall is tied to the username and its groups in the ClearPass authentication table entry. 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. The 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.

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:

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

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

In the following example, the user belongs to two groups, the human-resources-grp group and the posture-healthy group. The firewall 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).

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

Assume that the firewall 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:

If more than 2048 sessions are associated with a single authentication entry in the ClearPass authentication table, the active directory for ClearPass will not manage the sessions that caused the overflow. Consequently, there will be no user identification information for those sessions reported in the session close log for those sessions.

What is timeout setting for Aruba ClearPass?

Authentication entries in the Aruba ClearPass authentication table contain a timeout value after which the entry expires. You can protect invalid user authentication entries in an authentication table from expiring before the user can be validated by configuring a timeout setting that is specific to invalid entries. The invalid authentication entry timeout setting is separate from the common authentication entry timeout setting that is applied to valid entries.

For the ClearPass feature, if an unauthenticated user attempts to join the network and the IP address of the user’s device is not found—that is, it is not in the Packet Forwarding Engine—the device queries Aruba ClearPass for the user’s information. If the query is unsuccessful, the system generates an INVALID authentication entry for the user. If you configure a value for the invalid timeout setting, that timeout is applied to the entry. If you don't configure the invalid entry timeout, then its default timeout of 30 minutes is applied to the new entry. The invalid entry timeout is also applied to entries whose state is changed from valid or pending to INVALID.

How timeout setting for Aruba ClearPass works?

Use the following command to configure the invalid authentication entry timeout for entries in the ClearPass authentication table. Here, invalid authentication entries in the ClearPass authentication table expires 22 minutes after they are created.

• When you initially configure the invalid authentication entry timeout value for ClearPass, it is applied to any invalid authentication entries that are generated after it was configured. However, all existing invalid authentication entries retain the default timeout of 30 minutes.

• If you do not configure the invalid authentication entry timeout setting, the default timeout of 30 minutes is applied to all invalid authentication entries.

  If you configure the invalid authentication entry timeout setting and delete it later, the default value is applied to new invalid authentication entries generated after the deletion. However, any existing invalid authentication entries to which a configured value had been applied previously retain that value.

• If you change the setting for the invalid authentication entry timeout value, the new value is applied to all invalid authentication entries that were created after the value was changed. However, all existing invalid authentication entries retain the former invalid authentication entry timeout setting applied to them. Those entries to which the default value of 30 minutes had been applied previously retain that setting.

• When the pending or valid state of an entry is changed to invalid, the invalid authentication entry timeout setting is applied to it.

  When the state of an invalid authentication entry is changed to pending or valid, the invalid authentication entry timeout setting is no longer applicable to it. The timeout value set for the common authentication entry timeout is applied to it.

  Table 7: Invalid Authentication Timeout for Invalid Entries in the ClearPass Authentication Table

  Invalid Entry Timeout Setting	Intial Invalid Entry Timeout Setting	Elapse Time	New Invalid Entry Timeout Configuration Setting	Final Timeout Setting for Existing Invalid Entry
  New invalid authentication entry			50	50
  Existing invalid entry timeout	20	5	50	15
  Existing invalid entry timeout	0	40	20	0
  Existing invalid entry timeout	40	20	0	20