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.

// 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

When completed add "fwadmins" to "Authentication Server 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:
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
- Pro psaní komentářů se přihlašte




