This article helps you to implement layer2(802.1x or MAC) authentication cache when there is layer3 authentication also involved for the same client/user.
Environment : Applicable to ClearPass Policy Manager 6.0 and above.
In this setup we will be updating the authentication time to the endpoint during the Layer3/Captive portal authentication. The updated authentication time-stamp will be used to calculate the cache timer during the Layer2 authentication.
Updating authentication time during Layer3/Captive portal authentication.
Step 1: Creating the required endpoint attribute.
Navigate to Administration >> Dictionaries >> Attributes >> Add and create the attributes as shown in the below figures.
Note: Attributes entity should be "EndPoint" and Data Type can be selected as per your requirement
Step 2: Creating Enforcement Profiles that can update the Attributes to Endpoint.
Use the following SQL query to get the current date and time during the client authentication.
SELECT to_timestamp(to_char(now(), 'YYYY-MM-DD HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS') AS current_date_time
Running the above in any SQL DB will print the current date and time with the attribute "current_date_time", which can be mapped to the Enforcement profile.
Sample output:
testdb=> SELECT to_timestamp(to_char(now(), 'YYYY-MM-DD HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS') AS current_date_time;
current_date_time
------------------------
2014-11-27 16:27:10-08
Add the above query in any one of the Internal authentication sources like [Local User Repository]. Navigate to Configuration >> Authentication >> Sources >> [Local User Repository] >> Attributes >> Add More Filters and add the query as shown below.
Navigate to Configuration >> Enforcement >> Profiles >> Add >> Set the Template as "ClearPass Entity Update Enforcement" and create the Profiles as shown below.
The below sample enforcement profile name is "Auth Time Update"
Note: The Value format should be "%{Authorization:[Local User Repository]:current_date_time}, because the [Local User Repository] will be used as authorization source to fetch the current date and time.
Step 3: Mapping the enforcement profiles to the L3 authentication service.
Map the [Local User Repository] as the authorization source in the service to fetch the date and time.
Assign the Entity Update Enforcement Profiles under the Enforcement Policy >> Conditions as shown below to update the Endpoint attributes during the client authentication.
Using the updated authentication time to calculate the cache timer during Layer2 authentication.
Step 1: Add another Filter in the [Local User Repository] with the below SQL query to calculate the remaining cache timer.
SELECT CASE WHEN cast(extract(EPOCH FROM (to_timestamp('%{Endpoint:authtime}', 'YYYY-MM-DD HH24:MI:SS') + interval '720 minutes' - now())) AS INTEGER) < 0 THEN 0 ELSE cast(extract(EPOCH FROM (to_timestamp('%{Endpoint:authtime}', 'YYYY-MM-DD HH24:MI:SS') + interval '720 minutes' - now())) AS INTEGER) END AS expire_time
The above query is an example to cache the Layer2 authentication for 12 hours. You could modify the interval in minutes as per you requirements. This query will return the output in seconds if there is any remaining expiration. The output of the expired cache will be "0".
Navigate to Configuration >> Authentication >> Sources >> [Local User Repository] >> Attributes >> Add More Filters and add the query as shown below.
Step 2: Create the enforcement policy as shown below in the Layer 2 authentication.
The above conditions are to meant to allow the users on the network, only if the time since the last Layer3 authentication is within 12 hours. Users exceeding the 12 hours cache will be redirected/force to the captive portal authentication again either by denying the access or returning a user role which puts the user into captive portal authentication on the controller.
The below output confirm the authentication time is being updated to the endpoint during the captive portal authentication.
The below output from the access tracker shows the remaining cache time in seconds and confirms the network access to the client without forcing to captive portal authentication.
The remaining cache time will be "0" if the user is not within the 12 hours of cache.
Use cases:
1. This solution can be implemented with the regular guest mac caching, where we need not to query the insight repository for mac caching.
2. We have seen many requests from customers, where the clients will go through the 802.1x authentication first and then also perform Captive Portal authentication. This solution helps to bypass the Captive Portal authentication for the specified cache time.
Additional tips:
The derived remaining expiration time during the laye2 authentication can be returned back to the controller as "Radius:IETF:Session-Timeout" to bounce/disconnect the client device when the cache expires.
Create an enforcement profile as shown below and map it to the Layer2 authentication service enforcement policy.
Please find below a sample out put of remaining expiration/cache time is being returned to the controller as Radius:IETF:Session-Timeout.
