Implementation of RADIUS group authentication on Check Point appliances

As usual manuals, knowledge bases and other sources aren't describing this topic very well, so each of us must debug how Check Point implement it in their own way.
I will show you where and how to setup RADIUS authentication on Check Point appliances as well as on RADIUS server itself (FreeRADIUS) step-by-step. This is also some kind of my own notes for further deployments :]

// Mission

First of all we will point Check Point appliances to RADIUS server, setup shared secret and group relation expected in response from RADIUS server. 
RADIUS group is something what Check Point expecting in successful authentication message from RADIUS in   attribute. For our purposes we use group name “fwadmins”.

» Notice
There is non-sense limitation on current version of Check Point SecurePlatform for length of shared secret (10 chars max), so be sure that you will not exceed it.

Check Point Shared Secret limitation

// Setup on Check Point

First of all allow access from appliances (and cluster object as well) to RADIUS server.

» Via WebUI

Visit appliance WebUI https://appliance-name.company.com, enter credentials and go to Appliance -> Authentication Servers
Click on “New” button in Authentication servers table

Check Point Authentication Servers

When completed add "fwadmins" to "Authentication Server Groups".

Check Point Authentication Servers Groups

Don’t forget to setup the same on both cluster members!

» Via CLI

As usual via CLI is this operation 10x faster. Just run those two commands:

 
To double-check your setup run:   and  
After that login to second node and execute commands as well.

» Summarize Network information

Imagine this scenario of traffic flow:

 

Where CP cluster have 2 interfaces facing RADIUS:
 

and 2 interfaces facing MGMT server:
 

You must distinguish between management IP addresses and addresses from which appliance will contact RADIUS in case of authentication attempt.
Management interface:
Interface for communication with management server. In our example 1.1.1.1

Routing interfaces (find interface facing RADIUS server):

 

BUT source of authentication attempt will be cluster interface of 2.2.2.3
To find which one is it, run:

 

So cluster interface in this case is 2.2.2.2
From this address will be contacted RADIUS, so we have to define it in  .

// Configuration on RADIUS

  • 2.2.2.2 - is cluster VIP making connection to RADIUS (doesn’t matter if you’re authenticating against active or standby node) which has to be defined in RADIUS clients.conf
  • 
1.1.1.2 and 1.1.1.3 - are management IPs which has to be defined in RADIUS huntgroups file because authentication is provided to them and not to cluster VIP making connection

Example in clients.conf:
we will use Check Point cluster IP facing RADIUS server

 


Example in huntgroups:
we will use Check Point cluster management IP
 

“fwadmin” class value is taken from freeradius “/etc/raddb/users” file where we define relation of   attribute to user account.

Example of users:

 

So when I try login to CP firewall, appliance will send my username and password to RADIUS, where will be authenticated against LDAP/PAM/SQL/whatever and when it is OK from "users" file add Class attribute "fwadmins" if authentication client match huntgroup "CHECKPOINT".
In fact "fwadmins" can be attribute in LDAP as well, you just need to correctly filter and translate response from LDAP server on RADIUS. It's up to you.

// Appendix

» Traffic visible on RADIUS

 

» RADIUS log

 

EOF