UPDATE: 5/13/2014
I found a feature/design flaw/bug/workaround in how the firewall identifies itself to the RADIUS server.
RADIUS server receives 3 IP addresses from the RADIUS client
- RAS IP: IP of the firewall interface that is making the request to the RADIUS server
- NAS IP: Alias IP of the firewall generally used for RADIUS accounting
- CLIENT IP: of the remote desktop client trying to SSH or WEBUI to the firewall
Problem: Seems that some RADIUS servers use the NAS-IP to do their database lookup for AV pairs, instead of the RAS IP. More specifically RADIUS uses the RAS IP for secret key lookup and NAS IP for AV pairs. Go figure.
The NAS IP is set in your /etc/hosts file for the localhost and the local host DNS name. You can also set this in your WEBUI
Its fixed in R77.10 a bit:
UPDATE: 2/18/2014
I spoke with the developers on this and got more info:
- R77 (I am at R75.47) you can specify a default shell of /bin/bash instead of /bin/clish and then EVERYONE who is RADIUS authenticated will go into /bin/bash and not clish. So this is what SPLAT had which is nice we are finally back to where we started.
- I asked the developer to consider adding another Radius Attribute GAIA-user-shell, where in RADIUS you can set the shell to /bin/bash or /bin/clish for that user. He thought it was a good idea and would consider it.
- gaia-superuser-access attribute RADIUS attribute is used to assign a Unix UID of 0 for superuser or 96 for regular user. I haven’t seen this documented anywhere and haven’t tried it to verify.
- Note: The role ‘radius-group-any’ gets assigned to EVERY user by default. So if a user has a role ‘guionlyRole’, the user will get the guidonlyRole features as well as the features from ‘radius-group-any’. I haven’t see this documented anywhere.
- Make sure you have
hotfix HOTFIX_FOXX_HF_HA46_074as well as these. They are for the super user setting UID to 0:For pam rpm, command is a little different. Do:
rpm -Uvh –force –noscripts pam-0.99.6.2-3.26.cp986008001.i386.rpm
For CPshell, normal command:
rpm -Uvh –force CPshell-1-986008001.i386.rpm
UPDATE: 02/5/2014
I got some of it to work on R75.46 with hotfix HOTFIX_FOXX_HF_HA46_074
I setup my own FreeRadius server (it was easy) and customized it according to sk72940 and it looks like it works.
Scenario:
- All users defined on RADIUS server. (Trying to get this to proxy to AD will be next step).
- Here is the RADIUS dictionary and the user definition for user ‘radius1’.
- No users defined locally on GAIA
- So now I SSH onto system and you can see the attributes being passed back to GAIA
- Now I log into expert mode and check out my security context. SuperUser!
- Here is the /var/log/messages file should look like:
- Network sniff should look like this
- FYI: I can’t seem to get CP_Gaia-SuperUser-Access=0 to do anything. I can’t log in with it.
I can modify the CP-Gaia-user-Role and it will change the role for the user. For example,
I can change CP-Gaia-user-Role=monitorRole and user will have read-only access and
cannot! execute the expert command.
I just wish we could go directly into Unix mode and not have to use the expert password. Why? If someone quits we still have to change the expert password on 1000000000 of firewalls. SO how about this?
If you add a the user to GAIA as UID 0:
and set the shell to bash
result
and then make ‘radiusroot’ to exist in your AD/RADIUS server, …abra cadabra…. you are notw AD authenticated into /bin/bash! Unfortunately this means you have to add bash users to all 1000000 firewalls you own.
Oh well, beggers can’t be choosers I guess.
I’ll let you know if I can get AD proxy going. Stay tuned!
Get your RADIUS on!
dreez
UPDATE: 10/23/2013
Last I heard is there is a fix to give RADIUS users either bash or clish, but not both. Haven’t tried it.
The Fix.
UPDATE: 4/21/2013
So spoke with someone in the know and got same info:
There is no way they know of to RADIUS authenticate into expert mode. They claim R&D is going to fix it, but our person rolled their eyes.
So the status is RADIUS users can now execute tcpdump. So you can build a ‘netdebug’ group in GAIA and give them limited access.
But for the superadmins, you still either have to:
1) Create each person individually on the firewall UID 0 and then RADIUS auth them into /bin/bash
2) Create a generic account UID 0 on each firewall and then RADIUS auth them into /bin/bash
Hope this saves you some work,
dreez
UPDATE:
3/29/2013: Word from R&D is that Radius authenticated users cannot be assigned UID 0, so they will not be able to execute commands like tcpdump. This is a design decision. My opinion is this is a bad bad bad decision. It goes backwards from SPLAT. You can’t globally manage a disparate set of administrators.
They have updated the RADIUS groups to allow RADIUS attributes so you can have more than 1 security group, but in the end you still have to hand out the expert password to get UID 0 access. How lame is that? Obviously R&D never tried changing expert passwords on 500 firewalls when an admin leaves.
UPDATE:: 1/21/2013: Ask and you shall receive:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk91640
BUT: still have to specify virtual systems assigned to role.
=========
In large environments were many administrators have CLI access, GAIA was designed to provide a fine grain level of control over those users with ‘roles’. GAIA was like the uber-cpshell. You could have 1 group be superusers, 1 group be run-backups admins, 1 group be tcpdump type admins, 1 group be, etc.
Unless you use RADIUS.
If non-local users are RADIUS authenticated, then they are put into one GAIA role ‘radius-group-any’. Now you can custom design what this group does. For example:
add rba role radius-group-any domain-type System readonly-features arp, ext_ping ,ext_traceroute
So this group only does arp, ping, traceroute
BUT, now there is only ONE RADIUS group that can only do ONE set of things.
Hopefully! this will be fixed soon. I’m trying to figure out how to get around this.
Unfortunately it only gets better under VSX.
When you create a role, you can assign the VSs that it can operate in (which is undocumented)
add rba role ROLENAME virtual-system-access 0,1,2,3,4,5,………………
Well, seems OK unless you have 250 VSs on several clusters and have several different roles. Can you say exponential problem?
You cannot say
add rba role ROLENAME virtual-system-access all
which is what the adminrole is:
Role
adminRole
domain-type applies to all domains
virtual-system access: all
No, you have to go through and add each VS to each role one at a time……UGH. Another RFE.
add rba role ROLENAME virtual-system-access 0,1,2,3,4,5,6,7,8,9…………
Peace Out
dreez