Configure Integrated ClearPass Authentication and Enforcement
SRX Series and NFX Series devices collaborate with ClearPass to control the user access from the user level by their usernames or by the groups that they belong to, not the IP address of the device. The device Web API acts as an HTTP server and sends user identity information from ClearPass to the device for authentication. Also, the user query function helps to query an individual user for user identity information.
Understanding How ClearPass Initiates a Session and Communicates User Authentication Information Using the Web API
The integrated ClearPass authentication and enforcement feature enables the SRX Series or NFX Series device and Aruba ClearPass to collaborate in protecting your company’s resources by enforcing security at the user identity level in environments in which they are deployed together. The ClearPass Policy Manager (CPPM) can authenticate users across wired, wireless, and VPN infrastructures and post that information to the device, which, in turn, uses it to authenticate users requesting access to your protected resources and to the internet. The device can provide the CPPM with threat and attack logs associated users’ devices so that you can better harden your security at the ClearPass end.
- Web API
- ClearPass Authentication Table
- Using HTTPS or HTTP for the Connection Protocol Between ClearPass and the Device
- Ensuring the Integrity of Data Sent from ClearPass to the Device
- Data Size Restrictions and Other Constraints
- Posture States and the Posture Group
Web API
The device exposes to the CPPM its Web API daemon (webapi) interface that enables the CPPM to integrate with it and efficiently send authenticated user identity information to the device. The Web API daemon acts as an HTTP server in that it implements part of the RESTful Web services that supports concurrent HTTP and HTTPS requests. In this relationship, the CPPM is the client. The Web API daemon is restricted to processing only HTTP/HTTPS requests. Any other type of request it receives generates an error message.
If you are deploying the integrated ClearPass Web API function and Web management at the same time, you must ensure that they use different HTTP or HTTPS service ports.
However, for security considerations, we recommend that you use HTTPS instead of HTTP. HTTP is supported primarily for debugging purposes.
The Web API daemon runs on the primary Routing Engine in a chassis cluster environment. After an Chassis Cluster switchover, the daemon will start automatically on the new primary Routing Engine. It has no effect on the Packet Forwarding Engine.
Starting with Junos OS Release 15.1X49-D130, you can configure the IPv6 address for Web API function to allow the ClearPass to initiate and establish a secure connection. Web API supports the IPv6 user entries obtained from CPPM. Prior to Junos OS Release 15.1X49-D130, only IPv4 address was supported.
ClearPass Authentication Table
After the device receives information posted to it from the CPPM, the device extracts the user authentication and identity information, analyzes it, and distributes it to the appropriate processes for handling. The device creates a ClearPass authentication table on the Packet Forwarding Engine side to hold this user information. When the device receives the information sent to it from ClearPass, the device generates entries in the ClearPass authentication table for the authenticated users. When the device receives an access request from a user, it can check its ClearPass authentication table to verify that the user is authenticated, and then apply the security policy that matches the traffic from the user.
Starting with Junos OS Release 15.1X49-D130, device can receive the IPv6 addresses from CPPM, and the ClearPass authentication table supports IPv6 addresses.
Using HTTPS or HTTP for the Connection Protocol Between ClearPass and the Device
When you configure the Web API, you specify a certificate key if you are using HTTPS as the connection protocol. To ensure security, the HTTPS default certificate key size is 2048 bytes. If you do not specify a certificate size, the default size is assumed. There are three methods that you can use to specify a certificate:
Default certificate
Certificate generated by PKI
Custom certificate and certificate key
The SRX Series Web API supports only the Privacy-Enhanced Mail (PEM) format for the certificate and certificate key configuration.
If you enable the Web API on the default ports—HTTP (8080)
or HTTPS (8443)—you must enable host inbound traffic on the
ports. If you enable it on any other TCP port, you must enable host
inbound traffic specifying the parameter any-service. For
example:
user@host# set security zones security-zone trust host-inbound-traffic system-services any-service
Ensuring the Integrity of Data Sent from ClearPass to the Device
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:
/api/userfw/v1/post-entry
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.
Note:The CPPM checks the health and posture of a device and it can send that information to the SRX Series Firewall or NFX Series device as part of the user information that it posts. You cannot define posture on the SRX Series Firewall or NFX Series device. Also, the SRX Series Firewall or NFX Series device 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
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)
See Also
Example: Configuring the SRX Series Integrated ClearPass Feature to Allow the Device to Receive User Authentication Data from ClearPass
The SRX Series Firewall and the ClearPass Policy Manager (CPPM) collaborate to control access to your protected resources and to the Internet. To carry this out, the SRX Series Firewall must authenticate users in conjunction with applying security policies that match their requests. For the integrated ClearPass authentication and enforcement feature, the SRX Series Firewall relies on ClearPass as its authentication source.
The Web API function, which this example covers, exposes to the CPPM an API that enables it to initiate a secure connection with the SRX Series Firewall. The CPPM uses this connection to post user authentication information to the SRX Series Firewall. In their relationship, the SRX Series Firewall acts as an HTTPS server for the CPPM client.
Requirements
This section defines the software and hardware requirements for the topology for this example. See Figure 2 for the topology design.
The hardware and software components are:
Aruba ClearPass Policy Manager (CPPM). The CPPM is configured to use its local authentication source to authenticate users.
Note:It is assumed that the CPPM is configured to provide the SRX Series Firewall with user authentication and identity information, including the username, a list of the names of any groups that the user belongs to, the IP addresses of the devices used, and the device posture token.
SRX Series Firewall running Junos OS that includes the integrated ClearPass feature.
A server farm composed of six servers, all in the servers-zone:
marketing-server-protected (203.0.113.23 )
human-resources-server (203.0.113.25 )
accounting-server (203.0.113.72)
public-server (192.0.2.96)
corporate-server (203.0.113.71)
sales-server (203.0.113.81)
AC 7010 Aruba Cloud Services Controller running ArubaOS.
Aruba AP wireless access controller running ArubaOS.
The Aruba AP is connected to the AC7010.
Wireless users connect to the CPPM through the Aruba AP.
Juniper Networks EX4300 switch used as the wired 802.1 access device.
Wired users connect to the CPPM using the EX4300 switch.
Six end-user systems:
Three wired network-connected PCs running Microsoft OS
Two BYOD devices that access the network through the Aruba AP access device
One wireless laptop running Microsoft OS
Overview
You can configure identity-aware security policies on the SRX Series Firewall to control a user’s access to resources based on username or group name, not the IP address of the device. For this feature, the SRX Series Firewall relies on the CPPM for user authentication. The SRX Series Firewall exposes to ClearPass its Web API (webapi) to allow the CPPM to integrate with it. The CCPM posts user authentication information efficiently to the SRX Series Firewall across the connection. You must configure the Web API function to allow the CPPM to initiate and establish a secure connection. There is no separate Routing Engine process required on the SRX Series Firewall to establish a connection between the SRX Series Firewall and the CPPM.
Figure 1 illustrates the communication cycle between the SRX Series Firewall and the CPPM, including user authentication.
As depicted, the following activity takes place:
-
The CPPM initiates a secure connection with the SRX Series Firewall using Web API.
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.
-
The CPPM sends the user authentication and identity information for the users who are logged in to the network to the SRX Series Firewall in POST request messages using the Web API.
When traffic from a user arrives at the SRX Series Firewall, the SRX Series Firewall:
-
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.
-
-
Traffic from the smartphone user who is requesting access to an internal, protected resource arrives at the SRX Series Firewall. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series Firewall allows the user connection to the protected resource.
-
Traffic from the wired laptop user who is requesting access to a protected resource arrives at the SRX Series Firewall. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series Firewall allows the user connection to the resource.
-
Traffic from the tablet user who is requesting access to the Internet arrives at the SRX Series Firewall. Because all of the conditions identified in Step 3 are met and the security policy permits it, the SRX Series Firewall allows the user connection to the Internet.
The Web API daemon is not enabled by default for security reasons. When you start up the Web API daemon, by default it opens either the HTTP (8080) or the HTTPS (8443) service port. You must ensure that one of these ports is configured, depending on which version of the HTTP protocol you want to use. We recommend that you use HTTPS for security reasons. Opening these ports makes the system more vulnerable to service attacks. To protect against service attacks that might use these ports, the Web API daemon will start up only after you enable it.
The Web API is a RESTful Web services implementation. However, it does not fully support the RESTful Web services. Rather, it acts as an HTTP or HTTPS server that responds to requests from the ClearPass client.
The Web API connection is initialized by the CPPM using the HTTP service port (8080) or HTTPS service port (8443). For ClearPass to be able to post messages, you must enable and configure the Web API daemon.
To mitigate abuse and protect against data tampering, the Web API daemon:
Requires ClearPass client authentication by HTTP or HTTPS basic user account authentication.
Allows data to be posted to it only from the IP address configured as the client source. That is, it allows HTTP or HTTPS POST requests only from the ClearPass client IP address, which in this example is 192.0.2.199.
Requires that posted content conforms to the established XML data format. When it processes the data, the Web API daemon ensures that the correct data format was used.
Note that if you deploy Web management and the SRX Series Firewall together, they must run on different HTTP or HTTPS service ports.
See Understanding How ClearPass Initiates a Session and Communicates User Authentication Information to the SRX Series Device Using the Web API for further information on how this feature protects against data tampering.
The SRX Series UserID daemon processes the user authentication and identity information and synchronizes it to the ClearPass authentication table on the Packet Forwarding Engine. The SRX Series Firewall creates the ClearPass authentication table to be used for information received only from the CPPM. The ClearPass authentication table does not contain user authentication information from other authentication sources. The SRX Series Firewall checks the ClearPass authentication table to authenticate users attempting to access protected network resources on the Internet using wired or wireless devices and local network resources.
For the CPPM to connect to the SRX Series Firewall and post authentication information, it must be certified using HTTPS authentication. The Web API daemon supports three methods that can be used to refer to an HTTPS certificate: a default certificate, a PKI local certificate, and a customized certificate implemented through the certificate and certificate-key configuration statements. These certificate methods are mutually exclusive.
This example uses HTTPS for the connection between the CPPM and the SRX Series Firewall. To ensure security, the integrated ClearPass feature default certificate key size is 2084 bits.
Whether you use any method—the default certificate, a PKI-generated certificate, or a custom certificate—for security reasons, you must ensure that the certificate size is 2084 bits or greater.
The following example shows how to generate a certificate and key using PKI:
user@host>request security pki generate-key-pair certificate-id aruba size 2048 user@host>request security pki local-certificate generate-self-signed certificate-id aruba domain-name mycompany.net email jxchan@mycompany.net ip-address 192.51.100.21 subject “CN=John Doe,OU=Sales ,O=mycompany.net ,L=MyCity ,ST=CA,C=US"
Topology
Figure 2 shows the topology used for the integrated ClearPass deployment examples.
Configuration
This section covers how to enable and configure the SRX Series Web API.
You must enable the Web API. It is not enabled by default.
- CLI Quick Configuration
- Configuring the SRX Series Web API Daemon
- Configuring the ClearPass Authentication Table Entry Timeout and Priority
CLI Quick Configuration
To quickly configure this example, copy the following statements, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the statements into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set system services webapi user sunny password i4%rgd set system services webapi client 192.0.2.199 set system services webapi https port 8443 set system services webapi https pki-local-certificate aruba set system services webapi debug-level alert set interfaces ge-0/0/3.4 vlan-id 340 family inet address 192.51.100.21 set security zones security-zone trust interfaces ge-0/0/3.4 host-inbound-traffic system-services webapi-ssl set security user-identification authentication-source aruba-clearpass priority 110 set security user-identification authentication-source local-authentication-table priority 120 set security user-identification authentication-source active-directory-authentication-table priority 125 set security user-identification authentication-source firewall-authentication priority 150 set security user-identification authentication-source unified-access-control priority 200
Configuring the SRX Series Web API Daemon
Step-by-Step Procedure
Configuring the Web API allows the CPPM to initialize a connection to the SRX Series Firewall. No separate connection configuration is required.
It is assumed that the CPPM is configured to provide the SRX Series Firewall with authenticated user identity information, including the username, the names of any groups that the user belongs to, the IP addresses of the devices used, and a posture token.
Note that the CPPM might have configured role mappings that map users or user groups to device types. If the CPPM forwards the role mapping information to the SRX Series Firewall, the SRX Series Firewall treats the role mappings as groups. The SRX Series Firewall does not distinguish them from other groups.
To configure the Web API daemon:
Configure the Web API daemon (webapi) username and password for the account.
This information is used for the HTTPS certification request.
[edit system services] user@host# set webapi user sunny password i4%rgd
-
Configure the Web API client address–that is, the IP address of the ClearPass webserver’s data port.
The SRX Series Firewall accepts information from this address only.
Note:The ClearPass webserver data port whose address is configured here is the same one that is used for the user query function, if you configure that function.
[edit system services] user@host# set webapi client 192.0.2.199
Note:Starting with Junos OS Release 15.1X49-D130, SRX Series Firewall supports IPv6 addresses to configure the Web API client address. Prior to Junos OS Release 15.1X49-D130, only IPv4 addresses were supported.
Configure the Web API daemon HTTPS service port.
If you enable the Web API service on the default TCP port 8080 or 8443, you must enable host inbound traffic on that port.
In this example, the secure version of the Web API service is used (webapi-ssl), so you must configure the HTTPS service port, 8443.
[edit system services] user@host# set webapi https port 8443
Configure the Web API daemon to use the HTTPS default certificate.
[edit system services] user@host# set webapi https pki-local-certificate aruba
Configure the trace level for the Web API daemon.
The supported trace levels are notice, warn, error, crit, alert, and emerg. The default value is error.
[edit system services] user@host# webapi debug-level alert
Configure the interface to use for host inbound traffic from the CPPM.
user@host# set interfaces ge-0/0/3.4 vlan-id 340 family inet address 192.51.100.21
Enable the Web API service over HTTPS host inbound traffic on TCP port 8443.
[edit security zones] user@host# set security-zone trust interfaces ge-0/0/3.4 host-inbound-traffic system-services webapi-ssl
Results
From configuration mode, confirm your Web API configuration by entering the show system services webapi command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user {
sunny;
password "$ABC123"; ## SECRET-DATA
}
client {
192.0.2.199;
}
https {
port 8443;
pki-local-certificate aruba;
}
debug-level {
alert;
}
From configuration mode, confirm the configuration for the interface used for host inbound traffic from the CPPM by entering the show interfaces ge-0/0/3.4 command. If the output does not display the intended configuration, repeat the verification process in this example to correct it.
vlan-id 340;
family inet {
address 192.51.100.21/32;
}
From configuration mode, confirm your security zone configuration that allows host-inbound traffic from the CPPM using the secure Web API service (web-api-ssl) by entering the show security zones security-zone trust command. If the output does not display the intended configuration, repeat the verification process in this example to correct it.
interfaces {
ge-0/0/3.4 {
host-inbound-traffic {
system-services {
webapi-ssl;
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring the ClearPass Authentication Table Entry Timeout and Priority
Step-by-Step Procedure
This procedure configures the following information:
The timeout parameter that determines when to age out idle authentication entries in the ClearPass authentication table.
The ClearPass authentication table as the first authentication table in the lookup order for the SRX Series Firewall to search for user authentication entries. If no entry is found in the ClearPass authentication table and there are other authentication tables configured, the SRX Series Firewall will search them, based on the order that you set.
-
Set the timeout value that is used to expire idle authentication entries in the ClearPass authentication table to 20 minutes.
[edit services user-identification] user@host# set authentication-source aruba-clearpass authentication-entry-timeout 20
The first time that you configure the SRX Series Firewall to integrate with an authentication source, you must specify a timeout value to identify when to expire idle entries in the ClearPass authentication table. If you do not specify a timeout value, the default value is assumed.
-
default = 30 minutes
-
range = If set, the timeout value should be within the range [10,1440 minutes]. A value of 0 means that the entry will never expire.
-
-
Set the authentication table priority order to direct the SRX Series Firewall to search for user authentication entries in the ClearPass authentication table first. Specify the order in which other authentication tables are searched if an entry for the user is not found in the ClearPass authentication table.
Note:You need to set this value if the ClearPass authentication table is not the only authentication table on the Packet Forwarding Engine.
[edit security user-identification] user@host# set authentication-source aruba-clearpass priority 110 user@host# set authentication-source local-authentication-table priority 120 user@host# set authentication-source active-directory-authentication-table priority 125 user@host# set authentication-source firewall-authentication priority 150 user@host# set authentication-source unified-access-control priority 200
The default priority value for the ClearPass authentication table is 110. You must change the local authentication table entry from 100 to 120 to direct the SRX Series Firewall to check the ClearPass authentication table first if there are other authentication tables on the Packet Forwarding Engine. Table 1 shows the new authentication table search priority.
Table 1: SRX Series Firewall Authentication Tables Search Priority Assignment SRX Series Authentication Tables
Set Value
ClearPass authentication table
110
Local authentication table
120
Active Directory authentication table
125
Firewall authentication table
150
UAC authentication table
200
Results
From configuration mode, confirm that the timeout value set for aging out ClearPass authentication table entries is correct. Enter the show services user-identification command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
authentication-source aruba-clearpass {
authentication-entry-timeout 20;
}
Understanding the Integrated ClearPass Authentication and Enforcement User Query Function
This topic focuses on how you can obtain user authentication and identity information for an individual user when that information is not posted directly to the SRX Series or NFX Series device by the ClearPass Policy Manager (CPPM).
The integrated ClearPass authentication and enforcement feature allows the device and Aruba ClearPass to control access to protected resources and the Internet from wireless and wired devices. For this to occur, ClearPass sends user authentication and identity information to the device. The device stores the information in its ClearPass authentication table. To send this information, usually the CPPM uses the Web API (webapi) services implementation, which allows it to make HTTP or HTTPS POST requests to the device.
It can happen that the CPPM does not send user authentication information for a user, for various reasons. When traffic from that user arrives at the SRX Series Firewall or NFX Series device, the device cannot authenticate the user. If you configure the device to enable the user query function, it can query the ClearPass webserver for authentication information for an individual user. The device bases the query on the IP address of the user’s device, which it obtains from the user’s access request traffic.
If the user query function is configured, the query process is triggered automatically when the device does not find an entry for the user in its ClearPass authentication table when it receives traffic from that user requesting access to a resource or the Internet. The device does not search its other authentication tables. Rather, it sends a query to the CPPM requesting authentication information for the user. Figure 3 depicts the user query process. In this example:
-
A user attempts to access a resource. The device receives the traffic requesting access. The SRX Series Firewall searches for an entry for the user in its ClearPass authentication table, but none is found.
The device requests authentication for the user from the CPPM.
The CPPM authenticates the user and returns the user authentication and identity information to the device.
The device creates an entry for the user in its ClearPass authentication table, and grants the user access to the Internet.
You can control when the device sends its requests automatically by configuring the following two mechanisms:
The
delay-query-timeparameterTo determine the value to set for the
delay-query-timeparameter, it helps to understand the events and duration involved in how user identity information is transferred to the device from ClearPass, and how thedelay-query-timeparameter influences the query process.A delay is incurred from when the CPPM initially posts user identity information to the device using the Web API to when the device can update its local ClearPass authentication table with that information. The user identity information must first pass through the ClearPass device’s control plane and the control plane of the device. In other words, this process can delay when the device can enter the user identity information in its ClearPass authentication table.
While this process is taking place, traffic might arrive at the device that is generated by an access request from a user whose authentication and identity information is in transit from ClearPass to the device.
Rather than allow the device to respond automatically by sending a user query immediately, you can set a
delay-query-timeparameter, specified in seconds, that allows the device to wait for a period of time before sending the query.After the delay timeout expires, the device sends the query to the CPPM and creates a pending entry in the Routing Engine authentication table. During this period, the traffic matches the default policy and is dropped or allowed, depending on the policy configuration.
Note:If there are many query requests in the queue, the device can maintain multiple concurrent connections to ClearPass to increase throughput. However, to ensure that ClearPass is not stressed by these connections, the number of concurrent connections is constrained to no more than 20 (<=20). You cannot change this value.
A default policy, which is applied to a packet if the device does not find an entry for the user associated with the traffic in its ClearPass authentication table.
The system default policy is configured to drop packets. You can override this action by configuring a policy that specifies a different action to apply to this traffic.
Table 2 shows the effect on the user query function in regard to whether or not Active Directory is enabled.
Active Directory Is Configured |
ClearPass User Query Function Is Enabled |
CLI Check Result |
|---|---|---|
No |
No |
Pass |
No |
Yes |
Pass |
Yes |
No |
Pass |
Yes |
Yes |
Fail |
To avoid the failure condition reflected in the bottom row of the table, you must disable either Active Directory or the user query function. If both are configured, the system displays the following error message:
The priority of CP auth source is higher than AD auth source, and the CP user-query will shadow all AD features. Therefore, please choose either disabling CP user-query or not configuring AD.
In its response to the user query request, the ClearPass web server returns information for the user’s device whose IP address was specified in the request. This response includes a time stamp, which is expressed in UTC (Coordinated Universal Time) as defined by ISO 8601.
Here are some examples:
2016-12-30T09:30:10.678123Z
2016-12-30T09:30:10Z
2016-06-06T00:31:52-07:00
Table 3 shows the components that comprise a timestamp format.
Format Component |
Meaning |
|---|---|
YYYY |
two-digit month |
DD |
two-digit day of month |
hh |
two-digits of hour (00 through 23) |
mm |
two-digits of minute |
ss |
two-digits of second |
s |
one or more digits representing a decimal fraction of a second |
TZD |
time zone designator: Z or +hh:mm or -hh:mm |
Example: Configuring the Integrated ClearPass Authentication and Enforcement User Query Function
This example covers how to configure the SRX Series Firewall to enable it to query Aruba ClearPass automatically for user authentication and identity information for an individual user when that information is not available.
The user query function is supplementary to the Web API method of obtaining user authentication and identity information, and it is optional.
Requirements
This section defines the software and hardware requirements for the overall topology that includes user query requirements. See Figure 5 for the topology. For details on the user query process, see Figure 4.
The hardware and software components are:
Aruba ClearPass (CPPM). The CPPM is configured to use its local authentication source to authenticate users.
Note:It is assumed that the CPPM is configured to provide the SRX Series Firewall with user authentication and identity information, including the username, a list of the names of any groups that the user belongs to, the IP addresses of the devices used, and the device posture token.
SRX Series Firewall running Junos OS that includes the integrated ClearPass feature.
A server farm composed of six servers, all in the servers-zone:
marketing-server-protected (203.0.113.23 )
human-resources-server (203.0.113.25 )
accounting-server (203.0.113.72)
public-server (203.0.113.91)
corporate-server (203.0.113.71)
sales-server (203.0.113.81)
AC 7010 Aruba Cloud Services Controller running ArubaOS.
Aruba AP wireless access controller running ArubaOS.
The Aruba AP is connected to the AC7010.
Wireless users connect to the CPPM through the Aruba AP.
Juniper Networks EX4300 switch used as the wired 802.1 access device.
Wired users connect to the CPPM using the EX4300 switch.
Six end-user systems:
Three wired network-connected PCs running Microsoft OS
Two BYOD devices that access the network through the Aruba AP access device
One wireless laptop running Microsoft OS
Overview
You can configure the user query function to enable the SRX Series Firewall to obtain authenticated user identity information from the CPPM for an individual user when the device’s ClearPass authentication table does not contain an entry for that user. The SRX Series Firewall bases the query on the IP address of the user’s device that generated the traffic issuing from the access request.
There are a number of reasons why the device might not already have authentication information from the CPPM for a particular user. For example, it can happen that a user has not already been authenticated by the CPPM. This condition could occur if a user joined the network through an access layer that is not on a managed switch or WLAN.
The user query function provides a means for the SRX Series Firewall to obtain user authentication and identity information from the CPPM for a user for whom the CPPM did not post that information to the SRX Series Firewall using the Web API. When the device receives an access request from a user for which there is not an entry in its ClearPass authentication table, it will automatically query the CPPM for it if this function is configured.
Figure 4 shows the user query flow process, which encompasses the following steps:
-
A user attempts to access a resource. The SRX Series Firewall receives the traffic requesting access. The device searches for an entry for the user in its ClearPass authentication table, but none is found.
The device requests authentication for the user from the CPPM.
The CPPM authenticates the user and returns the user authentication and identity information to the device.
The device creates an entry for the user in its ClearPass authentication table, and grants the user access to the Internet.
For details on the parameters that you can use to control when the device issues the query, see Understanding the Integrated ClearPass Authentication and Enforcement User Query Function.
You can also manually query the CPPM for authentication information for an individual user when this feature is configured.
The ClearPass endpoint API requires use of OAuth (RFC 6749) to authenticate and authorize access to it. For the device to be able to query the CPPM for individual user authentication and authorization information, it must acquire an access token. For this purpose, the device uses the Client Credentials access token grant type, which is one of the two types that ClearPass supports.
As administrator of the ClearPass Policy Manager (CPPM), you must create an API client on the CPPM with the grant_type set to “client_credentials”. You can then configure the device to use that information to obtain an access token. Here is an example of the message format for doing this:
curl https://{$Server}/api/oauth – – insecure – – data
“grant_type=client_credentials&client_id=Client2&client_secret= m2Tvcklsi9je0kH9UTwuXQwIutKLC2obaDL54/fC2DzC"
A successful request from the device to obtain an access token results in a response that is similar to the following example:
{
“access_token”:”ae79d980adf83ecb8e0eaca6516a50a784e81a4e”,
“expires_in”:2880,
“token_type”:”Bearer”,
“scope”=nu;
}
Before the access token expires, the device can obtain a new token using the same message.
Topology
Figure 5 shows the overall topology for this deployment, which encompasses the user query environment.
Configuration
To enable and configure the user query function, perform these tasks:
- CLI Quick Configuration
- Configure the User Query Function (Optional)
- Manually Issuing a Query to the CPPM for Individual User Authentication Information (Optional)
CLI Quick Configuration
To quickly configure this example, copy the following statements, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the statements into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set services user-identification authentication-source aruba-clearpass user-query web-server cp-webserver address 192.0.2.199 set services user-identification authentication-source aruba_clearpass user-query ca-certificate RADUISServerCertificate.crt set services user-identification authentication-source aruba-clearpass user-query client-id client-1 set services user-identification authentication-source aruba-clearpass user-query client-secret 7cTr13# set services user-identification authentication-source aruba-clearpass user-query token-api “api/oauth” set services user-identification authentication-source aruba-clearpass user-query IP address “api/vi/insight/endpoint/ip/$IP$”
Configure the User Query Function (Optional)
Step-by-Step Procedure
Configure the user query function to allow the SRX Series Firewall to connect automatically to the ClearPass client to make requests for authentication information for individual users.
The user query function supplements input from the CPPM sent using the Web API. The Web API daemon does not need to be enabled for the user query function to work. For the user query function, the SRX Series Firewall is the HTTP client. By it sends HTTPS requests to the CPPM on port 443.
To enable the SRX Series Firewall to make individual user queries automatically:
Configure Aruba ClearPass as the authentication source for user query requests, and configure the ClearPass webserver name and its IP address. The device requires this information to contact the ClearPass webserver.
Starting with Junos OS Release 15.1X49-D130, you can configure Aruba Clearpass server IP address with IPv6 address, in addition to IPv4 address. Prior to Junos OS Release 15.1X49-D130, IPv4 address was only supported.
Note:You must specify aruba-clearpass as the authentication source.
[edit services user-identification] user@host# set authentication-source aruba-clearpass user-query web-server cp-webserver address 192.0.2.199
Note:You can configure only one ClearPass webserver.
Optionally, configure the port number and connection method, or accept the following values for these parameters. This example assumes the default values.
connect-method (default is HTTPS)
port (by default, the device sends HTTPS requests to the CPPM on port 443
However, if you were to explicitly configure the connection method and port, you would use these statements:
set services user-identification authentication-source aruba-clearpass user-query web-server cp-webserver connect method <https/http> set services user-identification authentication-source aruba-clearpass user-query web-server cp-webserver port port-number
-
(Optional) Configure the ClearPass CA certificate file for the device to use to verify the ClearPass webserver. (The default certificate is assumed if none is configured.)
[edit services user-identification] user@host# set authentication-source aruba_clearpass user-query ca-certificate RADUISServerCertificate.crt
The ca-certificate enables the SRX Series Firewall to verify the authenticity of the ClearPass webserver and that it is trusted.
Before you configure the certificate, as administrator of the ClearPass device you must take the following actions:
-
Export the ClearPass webserver’s certificate from CPPM and import the certificate to the device.
-
Configure the ca-certificate as the path, including its CA filename, as located on the SRX Series Firewall. In this example, the following path is used:
/var/tmp/RADUISServerCertificate.crt
-
-
Configure the client ID and the secret that the SRX Series Firewall requires to obtain an access token required for user queries.
[edit services user-identification] user@host# set authentication-source aruba-clearpass user-query client-id client-1 user@host# set authentication-source aruba-clearpass user-query client-secret 7cTr13#
The client ID and the client secret are required values. They must be consistent with the client configuration on the CPPM.
Tip:When you configure the client on the CPPM, copy the client ID and secret to use in the device configuration.
Configure the token API that is used in generating the URL for acquiring an access token.
Note:You must specify the token API. It does not have a default value.
[edit services user-identification] user@host# set authentication-source aruba-clearpass user-query token-api “api/oauth”
In this example, the token API is
api/oauth. It is combined with the following information to generate the complete URL for acquiring an access tokenhttps://192.0.2.199/api/oauthThe connection method is HTTPS.
In this example, the IP address of the ClearPass webserver is 192.0.2.199.
Configure the query API to use for querying individual user authentication and identity information.
[edit services user-identification] user@host# set authentication-source aruba-clearpass user-query query-api ’api/vi/insight/endpoint/ip/$IP$’
In this example, the query-api is
api/vi/insight/endpoint/ip/$IP$. It is combined with the URLhttps://192.0.2.199/api/oauthresulting inhttps://192.0.2.199/api/oauth/api/vi/insight/endpoint/ip/$IP$.The $IP variable is replaced with the IP address of the end-user’s device for the user whose authentication information the SRX Series is requesting.
Configure the amount of time in seconds to delay before the device sends the individual user query.
[edit services user-identification] user@host# set authentication-source aruba-clearpass user-query delay-query-time 10
Manually Issuing a Query to the CPPM for Individual User Authentication Information (Optional)
Step-by-Step Procedure
Configure the following statement to manually request authentication information for the user whose device’s IP address is 203.0.113.46.
root@device>request service user-identification authentication-source aruba-clearpass user-query address 203.0.113.46
Verification
Use the following procedures to verify that the user query function is behaving as expected:
- Verifying That the ClearPass Webserver Is Online
- Enabling Trace and Checking the Output
- Determining If the User Query Function Is Executing Normally
- Determining If a Problem Exists by Relying on User Query Counters
Verifying That the ClearPass Webserver Is Online
Purpose
Ensure that the ClearPass webserver is online, which is the first mean of verifying that the user query request can complete successfully.
Action
Enter the show service user-identification authentication-source authentication-source user-query status command to verify that ClearPass is online.
show service user-identification authentication-source aruba-clearpass user-query status Authentication source: aruba-clearpass Web server Address: 192.0.2.199 Status: Online Current connections: 0
Enabling Trace and Checking the Output
Purpose
Display in the trace log any error messages generated by the user query function.
Action
Set the trace log file name and enable trace using the following commands:
set system services webapi debug-log trace-log-1 set services user-identification authentication-source aruba-clearpass traceoptions flag user-query
Determining If the User Query Function Is Executing Normally
Purpose
Determine if there is a problem with user query function behavior.
Action
Check syslog messages to determine if the user query request failed.
If it failed, the following error message is reported:
LOG1: sending user query for IP <ip-address> to ClearPass web server failed. :reason
The reason might be “server unconnected” or “socket error”.
Determining If a Problem Exists by Relying on User Query Counters
Purpose
Display the user query counters to home in on the problem, if one exists, by entering the show service user-identification authentication-source authentication-source user-query counters command.
The timestamp returned by ClearPass in response to the user query request can be specified in any of the ISO 8601 formats, including the format that includes a time zone.
Action
show service user-identification authentication-source aruba-clearpass user-query counters
Authentication source: aruba-clearpass
Web server Address: Address: ip-address
Access token: token-string
RE quest sent number: counter
Routing received number: counter
Time of last response: timestampChange History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.