CPPM TechNote - 3rd Party Enforcement Points (CheckPoint) v1

ClearPass 6.5
Tech Note: ClearPass
Integration with 3rd Party Enforcement Points

ClearPass & Checkpoint utilizing RESTful
API and RADIUS Accounting

Version Date Modified By Comments
0.1 / 0.2 Jan /Feb 2015 Danny Jump Early Draft Versions
1.0 Mar 2015 Danny Jump Initial Published Version

ClearPass 6.x Tech Note: CPPM Integration with 3rd Party Enforcement Points [CheckPoint]
Introduction ........................................................................................................................... 4
Audience .......................................................................................................................................... 5
CPPM 6.5 Post Auth Framework Additions ............................................................................. 6
Configuring CheckPoint & ClearPass for REST ......................................................................... 7
ClearPass Configuration .................................................................................................................... 7
Check Point Configuration – Where the UserID is verifiable ............................................................ 13
Check Point Configuration – Where the UserID is a Guest account .................................................. 19
Configuring Radius Accounting Proxy .................................................................................... 23
Configuring RADIUS Accounting on ClearPass ................................................................................. 23
Configuring RADIUS Accounting on a Checkpoint Firewall ............................................................... 25
Configuration of ClearPass to add Accounting Attributes [e.g. user role] ........................................ 30
Configuration of CheckPoint to parse Accounting Attributes [e.g. user role] ................................... 31

Figure 1 -‐ ClearPass Attributes sent to Firewalls ..................................................................... 4

Figure 2 -‐ New Session Notification Enforcement Profile ........................................................ 6
Figure 3 -‐ Adding a Generic HTTP Context Server .................................................................... 7
Figure 4 -‐ Context Server – Action Tab .................................................................................... 8
Figure 5 -‐ Context Server – Header Tab ................................................................................... 8
Figure 6 -‐ Context Server – Content Tab .................................................................................. 9
Figure 7 -‐ Context Server – Attributes Tab ............................................................................. 10
Figure 8 -‐ Check Login & Logout against CheckPoint endpoint ................................................ 10
Figure 9 – ‘Session Notification’ Enforcement Profile ............................................................. 11
Figure 10 -‐ Check Point Logout – Action Tab .......................................................................... 11
Figure 11 -‐ Check Point Logout – Content Tab ........................................................................ 12
Figure 12 -‐ Select the firewall to be configured ...................................................................... 13
Figure 13 -‐ Setting the RESTful PSK between CPPM and Check Point ...................................... 13
Figure 14 -‐ Set or Generate the IA PSK ................................................................................... 14
Figure 15 -‐ Enabling Active Directory ‘Addition’ wizard .......................................................... 14
Figure 16 -‐ Adding AD Server to Check Point .......................................................................... 15
Figure 17 -‐ Checking AD is added to Check Point .................................................................... 15
Figure 18 -‐ Adding a firewall rule to reference a username .................................................... 16
Figure 19 -‐ Install Firewall Policy ............................................................................................ 16
Figure 20 -‐ Installation of Policy in Progress ........................................................................... 17
Figure 21 -‐ Successful Installation of Firewall Policy ............................................................... 17
Figure 22 -‐ AD user authenticated on Check Point ................................................................. 18
Figure 23 -‐ non-‐AD user rejected by Check Point .................................................................... 19
Figure 24 -‐ Context Server Action for Guest users where the user_groups attribute is set ...... 20
Figure 25 -‐ Adding a 'Group' to match 'role' sent from ClearPass ........................................... 21
Figure 26 -‐ Adding an Access Role to use User Groups ........................................................... 21
Figure 28 -‐ Guest user being 'labeled' with access tag ............................................................ 22
Figure 29 -‐ Firewall Policy denying access to corporate resources .......................................... 22
Figure 30 -‐ Adding a PROXY Target ........................................................................................ 23
Aruba Networks Confidential 2

Figure 31 -‐ Enabling Accounting Proxy Configuration ............................................................. 24

Figure 32 -‐ Configuring Accounting Proxy on an example service ........................................... 24
Figure 33 -‐ Select the firewall to be configured ...................................................................... 25
Figure 34 -‐ Enabling and RADIUS accounting on Check Point .................................................. 25
Figure 35 -‐ Defining a HOST Object in Check Point ................................................................. 26
Figure 36 -‐ Configuring RADIUS accounting on the Check Point firewall ................................. 26
Figure 37 -‐ Showing user logging-‐in of SmartView Tracker ..................................................... 27
Figure 38 -‐ Adding Accounting attribute to ClearPass Proxy ................................................... 30
Figure 39 -‐ using authz attributes to pass 'role/group' to Checkpoint ..................................... 30
Figure 40 -‐ Creating User Groups & Access Roles ................................................................... 31
Figure 41 -‐ Aligning Groups to Roles ...................................................................................... 31
Figure 42 -‐ Grabbing RADIUS attributes from CPPM ............................................................... 32

Introduction
This series of Tech Notes describes the integration with 3rd Party firewall vendors. Within
this document we have captured the integration with CheckPoint. There are two methods
of integration between ClearPass Policy Manager and CheckPoint. One uses HTTP JSON
encoded RESTful APIs the other uses RADIUS Accounting. In the table below we have
captured the features and restrictions of different vendors and the capabilities they
support.
Note that the framework we have developed is not limited to only the below vendors.

Similar to the integration that exists between ClearPass and other vendors, CheckPoint
supports at a basic level the ability to pass username and source IP address attributes. But
other attributes shown below can also be passed. As a summary this is a list of the
attributes we pass from CPPM 6.5 to the vendors we have tested.
Feature/ CheckPoint Fortinet SonicWall Palo Alto

Firewall
Source IP ✓ ✓ ✓ ✓
Username ✓ ✓ ✓ ✓
User Role ✓ ✓ [a] ✗ ✗
Domain ✓ ✗ ✗ ✓
Device Type ✗ ✗ ✗ ✓
Machine OS ✗ ✗ ✗ ✓
Machine Name ✓ [b] ✗ ✗ ✓
Health/Posture ✗ ✗ ✗ ✓
Figure 1 -‐ ClearPass Attributes sent to Firewalls
[a] = Available from RADIUS Accounting, not from HTTP REST API calls
[b] = Available from HTTP REST API calls not from RADIUS Accounting.

The intent of this Tech Note is to document the integration between CPPM and CheckPoint
firewalls. This document focuses on testing and integration. CheckPoint has produced their
own document “sk104958” which also covers this topic and should be referenced for
details about our level of integration. Where it is practical, best practices will be

documented, although not every conceivable use case or deployment can or will be covered
here in this document.

Note: Within this document where you see a red-‐chili this is used to signify a ‘hot’
important point and highlights that this point is to be taken as a best-‐practice
recommendation.

Audience
The reader is assumed to be familiar with the ClearPass family of products, including Policy
Manager, Insight, Guest and Onboard. Basic knowledge of IP networks and wide-‐area
networking is also assumed. A general understanding and previous experience in the
deployment/configuration of CheckPoint is also assumed. We also make the assumption
that the firewall is already deployed. We will not cover the firewall deployment or
configuration beyond the steps to integrate ClearPass.

CPPM 6.5 Post Auth Framework Additions

Historically the Post Auth framework has provided multiple functions such as Palo Alto
Networks Integration, RADIUS Accounting, Session Restrictions such as Bandwidth Usage
or Multiple Device Enforcement, etc. Starting in CPPM 6.5 we released an enhancement to
the Post Auth framework. This will allow ClearPass to provide an enhanced level of
integration and possibly allow the enduser/customer the ability to add additional 3rd party
systems without Aruba having to specifically add support for the vendor directly into
ClearPass. This follows a similar approach to ClearPass Exchange where the flexibility of
ClearPass Exchange encourages and allows for the integration into 3rd party systems
supporting HTTP RESTful frameworks.
The new Enforcement Profile is a ‘Session Notification Enforcement’. Through the next
few sections we will cover this in detail. This new Enforcement Profile enhances the
functionality we previously provided within the ‘Session Restriction Enforcement Profile’.

Figure 2 -‐ New Session Notification Enforcement Profile
Note: When you migrate a system from a previous CPPM 6.x software level (6.4.x and
lower), if previously you had configured integration with a Palo Alto Networks firewall, this
would have been defined using a Session Restriction Enforcement Profile [Type – Session
Check IP-‐Address-‐Change-‐Notify]. These Enforcement Profiles are NOT supported under
CPPM 6.5 and any configuration using these profiles is migrated as you upgrade to CPPM
6.5. .

Configuring CheckPoint & ClearPass for REST

Configuration is required on both the ClearPass and CheckPoint nodes. For CheckPoint,
some of the functionality is still in an early release program and is not due for complete GA
until later in 2015, the expectation is calendar Q2 2015. Please contact CheckPoint for
advice and guidance. CheckPoint has produced a document “sk104958” which also covers
this topic. Within ClearPass you need a minimum s/w release of CPPM 6.5. The following
sections walk you through the ClearPass and CheckPoint configuration.
ClearPass Configuration
HTTP Context Server: First you need to add a generic HTTP Context Servers Endpoint (this
is the CheckPoint endpoint) at Administration -‐> External Servers -‐> Endpoint Context
Servers [Add]. Note that there is NO Username or Password defined on the Context Server.

Figure 3 -‐ Adding a Generic HTTP Context Server
Add the appropriate Server Name (IP Address), this will be translated into the Server Base
URL. No Username/Password credentials are required to communicate with the
CheckPoint firewall. Authentication is performed via the PSK configured in a later step.
Context Server Actions: Now that we have defined the Firewall endpoint, we need to amend
the CheckPoint context server actions ‘Login & Logout’ to use this endpoint.
It’s very important that you modify both the Login and Logout Server Actions. These are
what update the Firewall of a user’s session going active/de-‐active. ClearPass will then
update the CheckPoint firewall which will permit/deny this user. We don’t want to update
the firewall of a session starting and not clear it when the user leaves.

Note: There is a timeout value on the firewall but ensuring that the Context Server Logout
action is performed is cleaner and more secure.
Note: It’s recommended that you copy the supplied/original CheckPoint Login/Logout
context server actions templates and modify the copied items.

There are two Context server actions that need to be modified. These can be found under
Administration -‐> Dictionaries -‐> Context Server Actions filter on ‘check’ with a Filter =
‘Action Name’… then look for the below ‘Check Point’ action.
The first Context Server Action that needs to be modified is the ‘Check Point Login’….
Note: The below URL path is set to /idasdk/add-‐identity. As noted earlier in this
document the CheckPoint software is not generally released as of March 2015, and as such
the url path could change between the software used here and its GA release.
Within the ‘Action’ tab the ‘Server Name’ needs to be changed to that of the HTTP server
you added in the previous section above. The default will be localhost, select as appropriate
from the drop down.

Figure 4 -‐ Context Server – Action Tab
Within the ‘Header’ tab, nothing needs to be changed. Below is a copy of the parameters in
the default context server for your reference.

Figure 5 -‐ Context Server – Header Tab

Within the ‘Content’ tab, nothing needs to be changed. Note that as well as the
substitutional variables we send to the CheckPoint firewall, the identity-‐source attribute is
set permanently as ‘Aruba ClearPass Policy Manger’. There are several other important
parameters within this section, shared-‐secret, session-‐timeout, calculate-‐roles, fetch-‐user-‐
groups and fetch-‐machine-‐groups. The timeout setting has been set to 28800 seconds (8
hours), you can change this if required, however the logout is the action that should deal
with logging out Users from the firewall. With the new API, it is required to specify “fetch-‐
user-‐groups” and “fetch-‐machine-‐groups” (and set them both to “0”) if you want to make
sure the identity will not be verified against CP identity sources. “fetch-‐machine-‐groups” is
only relevant for machine identities.
Note: Now, this is very important for 6.5 and Guest Users. When using the CheckPoint
Identity Awareness feature (RESTful API or RADIUS Accounting) the userID that is received
by the firewall has to be verifiable as a valid user. CheckPoint typically will ensure the user
exists within an authoritative Identity Store, like Active Directory. Obviously for Guest
users their userIDs do not exist as they are transient users. Some guest accounts could exist
within a directory but that is not usual. So, as part of the integration we have to identity
these users and link them to a user group (a configurable CheckPoint attribute called
access role). The other really important attribute below in the Content tab is the calculate-‐
roles and fetch-‐user-‐groups. When we are posting a guest userID to CheckPoint these
values need to be set to ‘0’, that's a zero.
Details of the above is covered in detail in the section Check Point Configuration – Where
the UserID is a Guest account starting on page 18.
To achieve a full integration between CPPM and CheckPoint, you may have to have TWO
Context-‐Server’s definitions for the CheckPoint Firewall, each definition will reference
different Context-‐Server-‐Action, i.e. one group of configurations for AD/verifiable users the
other definition for Guests.

Figure 6 -‐ Context Server – Content Tab

Within the ‘Attributes’ tab, nothing is required. A copy for your reference is below.

Figure 7 -‐ Context Server – Attributes Tab
To check that all of the Context Server actions have been successfully configured, if you
return to the Endpoint Context Server, and look on the ‘Actions’ tab, you should see the
actions (hopefully you will have made a copy of the default server actions) listed against
your endpoint, ensure you see Login and Logout as shown in our example below.

Figure 8 -‐ Check Login & Logout against CheckPoint endpoint

Enforcement Profile: Finally a Session Notification Enforcement profile must be

configured. The Session Notification profile is new in CPPM 6.5. Below is an example of a
configured profile. Note that there are four session-‐notify attributes you must add to the
profile to make it complete, failure to add all four will certainly ensure your integration will
fail…!!!
1. Server-‐Type [Generic HTTP]

2. Server IP [IP address of previously defined HTTP Context Server]
3. Login Action [Configured and assigned to the Context server Login Action]
4. Logout Action [Configured and assigned to the Context server Logout Action]



Figure 9 – ‘Session Notification’ Enforcement Profile

Once the above configuration has been completed the normal process of applying the
context server actions to an enforcement profile should be followed. Then, following a
‘standard’ network authentication (e.g. dot1x) CPPM will post the userID attributes etc. to
the firewall, the posting is pretty much real-‐time. UserID should appear within 2 seconds.
NOTE: ENSURE YOU SET THE SHARED SECRET ON THE Check Point LOGOUT ACTION.

Figure 10 -‐ Check Point Logout – Action Tab
Note: The above URL may change when the CheckPoint software supporting this
integration is fully released.


Figure 11 -‐ Check Point Logout – Content Tab

Check Point Configuration – Where the UserID is verifiable

As previously noted, the software we have tested with is a restricted release code and not
due for GA until later in 2015. Note that the configuration shown below could change when
the Check Point software is fully released.
Signin to the CheckPoint firewall with the SmartDashboard management application.
Config Identity-‐Awareness API Service The first item of configuration required is that the
Identity Awareness (IA) API Service is enabled and the pre-‐shared secret is configured.
From the ‘Network Objects -‐ Checkpoint’ section, select (double-‐click) the enforcement
point you want to configure, in our case the firewall is the IArest object as shown below.

Figure 12 -‐ Select the firewall to be configured
From the following configuration screen ensure that ‘API Service’ is selected to enable the
feature. Then click on Settings to generate or set the PSK that will be configured in CPPM.

Figure 13 -‐ Setting the RESTful PSK between CPPM and Check Point
Note: that the API Service option shown above is a new option in the R80 product version.


Figure 14 -‐ Set or Generate the IA PSK
You can use the ability of the application to randomly generate a PSK or you can choose to
configure your own. The pre-‐shared secret configured here is what must match that of the
Login, Logout context server actions configured in CPPM.
Adding AD/LDAP Server If you need to add AD servers to CheckPoint, again edit the
CheckPoint firewall object. If you select/un-‐select Identity Awareness, the following
screen will be shown where you can use the AD Query wizard to add your AD Server to the
Check Point firewall.

Figure 15 -‐ Enabling Active Directory ‘Addition’ wizard
Q? -‐ Why would I want to do this? Well, the userID details that are sent by CPPM need to
either match a user-‐group or be verifiable with some other identity source, i.e. AD.

Add the required details, admin account, FQDN, etc. to add an AD to the CheckPoint
firewall. Take notice of the successful completion message at the bottom of the wizard.

Figure 16 -‐ Adding AD Server to Check Point
Once the AD server has been added, you can check this is successful by navigating to the
Users and Administrators tab (shown below). The AD server configured should show up
and you can expand it to see the configured DN.

Figure 17 -‐ Checking AD is added to Check Point

Finally you can see if the users are available to CheckPoint by writing a Policy rule
referencing one of the expected AD users. It's a good way to be sure AD was added
correctly and that the CheckPoint firewall can read the AD directory.

Add a new rule, for the Source, right click and ‘Add User/Access role’. Then select the
Users tab, then ‘Source users/groups’ and the green + to bring up the query box where
you can enter a user-‐name. Below we set this to ‘danny’ for the purpose of this
configuration step. If this user is located from the search of AD it will be shown in the
results search. This rule will now match on a user where the source traffic is from a
username matching ‘danny’, and in this case referenced and validated back to AD.



Figure 18 -‐ Adding a firewall rule to reference a username

Finally you need to install the policy, click on ‘Install Policy’ from Smart Dashboard, to
install and activate the configuration on the firewall blade.

Figure 19 -‐ Install Firewall Policy
In the screen above, you can see the policy being installed in the firewall IArest.

Below you can see the policy is being verified and the installation, progress bar advancing.

Figure 20 -‐ Installation of Policy in Progress
At the end of the installation you should see a screen similar to the below, showing a
successful installation of the firewall policy.

Figure 21 -‐ Successful Installation of Firewall Policy

Assuming the above configuration is complete, if we load the CheckPoint SmartView
Tracker, and filter using the Identity Awareness Blade we can look at the authenticated
users on the system. Below you can see (if you squint..!!) the user djump authenticated and
the Identity Source shows as ‘Aruba ClearPass Policy Manager’.

Figure 22 -‐ AD user authenticated on Check Point
Note that the “user-‐groups” and “machine-‐groups” parameters can take a comma-‐
separated list, it’s not mentioned above as our above example shows one group only.
So that's all good if the user belongs to a directory where CheckPoint is able to verify the
user. Next we cover the scenario where the user is essentially a Guest and CheckPoint
cannot verify the user’s identity beyond what ClearPass sends.


Check Point Configuration – Where the UserID is a Guest account

For a userID sent by ClearPass where the CheckPoint firewall is unable to verify the
account, we need to complete some additional configuration. We need to basically tell
CheckPoint that the userID belongs to a group that CheckPoint is aware of (i.e. a Guest
group). This requires us to pre-‐create the group and then have ClearPass include the group
information when we post the userID to the Check Point firewall. In the below, we have
tried to authenticate a user ‘qwerty’. In this example the user is a locally defined user in
ClearPass, but is not known to Active Directory. The CheckPoint firewall tried to verify the
userID exits but fails. From the log you can see this user is rejected. In essence this
simulated a guest (i.e. an unknown/unverifiable account) being denied by CheckPoint.

Figure 23 -‐ non-‐AD user rejected by Check Point
To support Guest users we need to make changes to the context-‐server-‐actions to make it
clear to the CheckPoint firewall that the userID sent from ClearPass is a GUEST and the
firewall must not try to verify the userID but take it at as being a known and trusted user.


A new Context Server Action will have to be created specifically for the Guests and then
modify the Content Tab as required. In the example below we define a user-‐groups in the
context-‐server-‐action called aruba-‐guest, this group will have to be created on the
CheckPoint firewall. Take care as no validation is performed and the spelling needs to be
exactly the same. The creation of this item on the firewall is covered later in the document.
Note: The user-‐groups attribute shown below in the ‘CONTENT’ tab is NOT included in the
initial 6.5 code release. You will have to manually add this and configure it as appropriate.
The important points to call out below are that we have added a field groups and this is set
in our example to aruba-‐guest. We also added roles and have changed the fetch-‐user-‐
groups to 0.

Figure 24 -‐ Context Server Action for Guest users where the user_groups attribute is set
The groups setting we POST from ClearPass must match configuration on the CheckPoint
firewall. The configuration it must match is called a Group, configure this under Users and
Administrator, then User Groups as shown below.
Note: The naming of the Group must be different from the Access-‐Role below which needs
to match ‘group/role’ sent from ClearPass. You cannot have multiple items of the same
name, even if they are configured in different functional areas of the CheckPoint firewall.


Figure 25 -‐ Adding a 'Group' to match 'role' sent from ClearPass
Following the creation of the Group, you can then create an Access Roles that encompasses
the User Group configured above. The Access Role aruba-‐guest is configured to match
specific Users. Note that the aruba-‐guest-‐group is under ‘Internal User Groups’. Follow
the below configuration example…. Access Role, Users, Specific users/groups, [add a
user/group], Internal User Groups, [select User Group] which was just configured for
our Guest users.

Figure 26 -‐ Adding an Access Role to use User Groups

We can see from the SmartView Tracker below, user danny being authenticated and
labeled with a role of aruba-‐guest.

Figure 27 -‐ Guest user being 'labeled' with access tag

Now that we have users being accepted and labeled in CheckPoint, Policy can be used to
reference the Guest users by the aruba-‐guest label. So in the below example, I created an
address-‐range object for our 10.0.0.0 internal network. In the simple rule below I used this
to deny guests effectively accessing any of our corporate network objects.

Figure 28 -‐ Firewall Policy denying access to corporate resources
This completes the Check Point firewall Configuration to enable the RESTful integration
between ClearPass and CheckPoint.

Configuring Radius Accounting Proxy

An additional integration method to support 3rd Party vendors was also added to the CPPM
6.5 release. We support the ability to configure a RADIUS Accounting Proxy. This allows
CPPM to proxy the RADIUS accounting data that is received to an external system such as
an external firewall or SIEM. When CPPM processes an authentication, as part of the
session configuration on CPPM a RADIUS Accounting Proxy target can also be configured.
This allows CPPM to forward the interim accounting updates it receives from the NAS to
this external target.
Configuring RADIUS Accounting on ClearPass

Configure Accounting Proxy on CPPM as shown below. First configure your targets, under
Configuration-‐> Network -‐> Proxy Targets just like previously as if you were configuring
RADIUS authentication proxy-‐ing.

Figure 29 -‐ Adding a PROXY Target

By default the Account Proxy Tab is not shown, you must enable it in the Service Definition
as highlighted below.

Figure 30 -‐ Enabling Accounting Proxy Configuration
Now that the target is defined and the Accounting Proxy is enabled the remaining
configuration can be completed.
Below is an example of adding the Accounting Proxy to the above service definition. We
added a proxy target from one of the targets configured in the previous step.

Figure 31 -‐ Configuring Accounting Proxy on an example service
Note: Whatever RADIUS accounting data we receive from the NAS will be forwarded to the
Accounting Proxy target. We can also add VSA and IETF standard attributes to the data we
forward. However, to add a VSA we must have the Dictionary’s for that vendor’s product
installed/enabled within CPPM. Some vendors have multiple RADIUS Dictionaries across
their product ranges, so just because we have one for company X does not mean it will
encompass all their products and the VSA’s they support.

Configuring RADIUS Accounting on a Checkpoint Firewall

Configure Identity-‐Awareness RADIUS Accounting The first item of configuration required is
that the Identity Awareness RADIUS Accounting is enabled
From the ‘Network Objects -‐ Checkpoint’ section, select (double-‐click) the enforcement
point you want to configure, in our case the firewall is the IArest object shown below.

Figure 32 -‐ Select the firewall to be configured
From the following configuration screen ensure that ‘RADIUS Accounting’ is selected to
enable the feature. Then click on Settings to configure the RADIUS accounting attributes.

Figure 33 -‐ Enabling and RADIUS accounting on Check Point

Note: You must configure the CPPM server as a network object (it just needs a name and a
IP address) now or prior to this step. Below is an example of creating a Network Host
object. This can then be referenced in the RADIUS accounting section that follows.

Figure 34 -‐ Defining a HOST Object in Check Point
Below is the RADIUS accounting configuration. There are two very important sections
highlighted. The first is defining/adding the CPPM host (RADIUS accounting source). You
may have already added this previously as a network object or you can add it now via the
green + below. Note: Don’t forget to set the PSK for the CPPM node.

Figure 35 -‐ Configuring RADIUS accounting on the Check Point firewall

The second section is to define the accounting attributes that Check Point will parse from
the RADIUS accounting data CPPM sends. It’s possible that CPPM will forward a lot of
additional data that the target system neither wants nor can process, VSA attributes for
example. This data is typically just ignored. In a later release, we intend to allow CPPM to
remove the accounting data that is not required by the target system before we send it.
Above, we have configured accounting attributes 31, 1 and 8. These are the three attributes
CheckPoint will parse and map to Machine-‐Name, Username and Endpoint SRC IP address.
The attributes you require may differ.
Note: the default attributes configured out-‐of-‐the-‐box are attributes 0, 31 and 8.
Once this is configured and the Policy installed, you should be able have the Check Point
firewall receive and parse the mapped attributes from the RADIUS accounting data.
Below is an example from the SmartView Tracker showing user ‘danny’ logging-‐in from a
source-‐ip-‐address of 10.2.100.165 and the user identity source was radius-‐accounting. You
can also see that danny was associated to a role ‘match-‐user-‐danny’ in the Associated Roles.

Figure 36 -‐ Showing user logging-‐in of SmartView Tracker
The above solution provides for mapping THREE RADIUS accounting attributes. There is a
method discussed below which allows for a fourth Accounting attribute to be exposed. This
is extremely useful and allows for ClearPass to attach what can be thought of as a ‘user-‐
role’ to the user name in the Accounting data. CheckPoint can then use this ‘user-‐role’ to
enforce policy against different ‘classes’ of users based upon the ‘user-‐role’.

Configure CheckPoint RADIUS Accounting to expose a fourth attribute

CheckPoint can make available a special hotfix patch that extends the number of attributes
parsed to four, today we believe this to be available for s/w version 77.10 and 77.20.
CPPM will add and set an IETF standard (e.g. attribute-‐77 Connect-‐Info) with a label e.g.
cppm-‐guests in the RADIUS accounting data. CheckPoint could then parse this attribute and
associate the username to a Guest role for example. The Check Point firewall would then be
able to apply policy restrictions against this user, but using the label as the differentiator.
The first step is to obtain the HotFix from CheckPoint. Its name is ‘RADIUS Accounting
Groups’, and was released in July 2014. RADIUS Accounting is an existing feature in the
Identity Awareness blade. It enables receiving identity information from external
authentication servers, using the RADIUS Accounting protocol.
Typically RADIUS Accounting user group information is retrieved from identity servers
(AD/LDAP servers or internal databases), but by utilizing this Hotfix we can bypass the
typical logic processing of the CheckPoint firewall and ‘force’ the firewall to trust the
group/role information ClearPass sends.

CheckPoint Installation of Hotfix Download from the CheckPoint support site the hotfix…..

fw1_wrapper_HOTFIX_GYPSY_RADIUS_286.tgz
Install this Hotfix on each R77.x0 firewall. Then separately on each of the Firewall with
Identity Awareness enabled you must manually install the fix. Start by SSH’ing to the CLI,
ensure you Log into Expert mode and then upload the Hotfix to a temporary directory.
The file that has been uploaded is a Gzipped Tar file. Before it can be installed it needs to be
unzipped/unpacked. Use the following command, pay particular attention to the flags…
tar –xzvf fw1_wrapper_HOTFIX_GYPSY_RADIUS_286.tgz
Now to installed the contents from the file…
./fw1_wrapper_HOTFIX_GYPSY_RADIUS_286_990286007_1
Plan this installation accordingly as once this installation has completed you must reboot
the system to complete the installation.

Configuration of CheckPoint Hotfix

Following the installation of this Hotfix, make sure that the RADIUS Accounting feature is
enabled on the Security Gateways with Identity Awareness. This has been covered above.
Enabling the RADIUS Accounting Group Hotfix

We need to edit the following file $FWDIR/conf/pdp_overriding_attrs.C
If this pathname does not exist, create it. If the file is empty, add a left parenthesis at the top
and add a right parenthesis at the bottom. The file should look like the below. Note as can
be seen we have used a standard IETF RADIUS attribute [77] that will be the key-‐pair-‐value
holding the user role.
Add to a new line inside the parenthesis :user_groups_index (<index>)
[Expert@gw-fcac73:0]# cat conf/pdp_overriding_attrs.C

(
:user_groups_index (77)
)
[Expert@gw-fcac73:0]#
Where <index> is the Accounting attribute number in the RADIUS Accounting Message
packet. Note the parenthesis around the attribute value..!!
Monitoring this function on the Firewall

From the CLI you can monitor the users with the following command pdp m user <user>
below is an example of the output from this command.
[Expert@gw-fcac73:0]# pdp m user danny
Session: 4eb46504
Session UUID: {21C2E80C-DD9A-A814-C5AE-8A06FFCFB188}
Ip: 10.2.100.167
Users:
danny {63f9a734}
Groups: geek-group
Roles: geek-group_access_role
Client Type: Radius Accounting
Authentication Method: Trust
Connect Time: Fri Mar 6 15:43:17 2015
Next Reauthentication: Sat Mar 7 03:43:47 2015
Next Connectivity Check: -
Packet Tagging Status: Not Active

Published Gateways: Local
***********************************************************************

Configuration of ClearPass to add Accounting Attributes [e.g. user role]

Within ClearPass Policy Manager we now need to amend the Accounting Proxy to add an
attribute [connect-‐info attribute 77) we will populate with a Role/Group value. This is the
attribute we defined within the configuration of the CheckPoint firewall hotfix previously.
Note: We are not locked to this attribute, as long as both ends are using a common value.
Navigate to Configuration -‐> Service [edit your service] and click on the Proxy Tab.
Within here you need to add the RADIUS Accounting attribute. From the ‘Type’ select
Radius: IETF, from the Name we’ve chosen ‘Connect-‐Info’ and then as shown below set as
required, we’ve set ours to a static value ‘geek-‐group’ for the purpose of this test.

Figure 37 -‐ Adding Accounting attribute to ClearPass Proxy
Note: The value field below can be a substitutional attribute, an example could be to choose
from the Authorization AD ‘memberOf’. Now that ClearPass is adding this attribute, policy
can be defined on CheckPoint to make policy enforcement to different user groups.

Figure 38 -‐ using authz attributes to pass 'role/group' to Checkpoint

Configuration of CheckPoint to parse Accounting Attributes [e.g. user role]
To have CheckPoint use the ‘role/group’ data we append to the RADIUS Accounting data
we need to configure some corresponding data within the Checkpoint firewall. In the
testing we show below we will use the following three groups, PLM, TME and geek-‐group.
PLM and TME are groups within our AD environment whilst geek-‐group is a static group
created for the purpose of this test. First, create your User-‐Groups, this is the ‘label’ that
matches the incoming attribute from the RADIUS Accounting data. Then you need to create
your Access Roles.

Figure 39 -‐ Creating User Groups & Access Roles
Once the above Roles/Groups have been created you need to align the Groups to the Access
Roles. This can also be done at creation time. Edit the Roles as necessary.

Figure 40 -‐ Aligning Groups to Roles

Below we can see from the Logs in CPPM, the users authenticated in Access-‐Tracker. We
are taking Calling-‐Station-‐ID and User-‐Name from here. The Framed IP Address comes
from the Accounting data.

Figure 41 -‐ Grabbing RADIUS attributes from CPPM
Below is the data received within the CheckPoint Smartview Tracker.

Above can be seen that the user danny, has been assigned to the User-‐Group ‘geek-‐group’
which has further been assigned an Access-‐Role of ’geek-‐group_access_role’.

CPPM TechNote - 3rd Party Enforcement Points (CheckPoint) v1

Uploaded by

Copyright:

Available Formats

CPPM TechNote - 3rd Party Enforcement Points (CheckPoint) v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CPPM TechNote - 3rd Party Enforcement Points (CheckPoint) v1

Uploaded by

Copyright:

Available Formats

Integration with 3rd Party Enforcement Points

1.0 Mar 2015 Danny Jump Initial Published Version

Figure 1 -­‐ ClearPass Attributes sent to Firewalls ..................................................................... 4

Aruba Networks Confidential 2

Figure 31 -­‐ Enabling Accounting Proxy Configuration ............................................................. 24

Aruba Networks Confidential 3

Feature/ CheckPoint Fortinet SonicWall Palo Alto

Figure 1 -­‐ ClearPass Attributes sent to Firewalls

Aruba Networks Confidential 4

Aruba Networks Confidential 5

CPPM 6.5 Post Auth Framework Additions

Aruba Networks Confidential 6

Configuring CheckPoint & ClearPass for REST

Figure 3 -­‐ Adding a Generic HTTP Context Server

Aruba Networks Confidential 7

Aruba Networks Confidential 8

Aruba Networks Confidential 9

Enforcement Profile: Finally a Session Notification Enforcement profile must be

1. Server-­‐Type [Generic HTTP]

Aruba Networks Confidential 10

Aruba Networks Confidential 11

Aruba Networks Confidential 12

Check Point Configuration – Where the UserID is verifiable

Aruba Networks Confidential 13

Aruba Networks Confidential 14

Aruba Networks Confidential 15

Aruba Networks Confidential 16

Aruba Networks Confidential 17

Aruba Networks Confidential 18

Check Point Configuration – Where the UserID is a Guest account

Aruba Networks Confidential 19

Aruba Networks Confidential 20

Aruba Networks Confidential 21

Aruba Networks Confidential 22

Configuring Radius Accounting Proxy

Configuring RADIUS Accounting on ClearPass

Aruba Networks Confidential 23

Aruba Networks Confidential 24

Configuring RADIUS Accounting on a Checkpoint Firewall

Aruba Networks Confidential 25

Aruba Networks Confidential 26

Aruba Networks Confidential 27

Configure CheckPoint RADIUS Accounting to expose a fourth attribute

tar –xzvf fw1_wrapper_HOTFIX_GYPSY_RADIUS_286.tgz

Now to installed the contents from the file…

Aruba Networks Confidential 28

Configuration of CheckPoint Hotfix

Enabling the RADIUS Accounting Group Hotfix

Add to a new line inside the parenthesis :user_groups_index (<index>)

[Expert@gw-fcac73:0]# cat conf/pdp_overriding_attrs.C

Monitoring this function on the Firewall

[Expert@gw-fcac73:0]# pdp m user danny

Packet Tagging Status: Not Active

Aruba Networks Confidential 29

Aruba Networks Confidential 30

Aruba Networks Confidential 31

Aruba Networks Confidential 32

You might also like

Figure 1 -‐ ClearPass Attributes sent to Firewalls ..................................................................... 4

Figure 31 -‐ Enabling Accounting Proxy Configuration ............................................................. 24

Figure 1 -‐ ClearPass Attributes sent to Firewalls

Figure 3 -‐ Adding a Generic HTTP Context Server

1. Server-‐Type [Generic HTTP]