Setting up centralized authentication for Linux SSH users

[Daniel Bray]

I'm starting to wonder if I've selected the wrong tool for the job here.
Hoping to gather some guidance, and help. The environment is 99% Linux
servers with various Cisco equipment.

I was thinking that a Freeradius solution would be a simple approach to get
all the SSH devices (Linux and Cisco) pointing to a single server for
authentication purposes. I would also like to setup groups, so that our
Vendors that also require SSH access can be setup and assigned to specific
groups that then can only SSH into specific servers. Am I heading in the
right direction by selecting Freeradius to do this job?

Here comes the issues I face. I got everything setup on a Linux server,
and using MySQL as the backend. I'm also using daloRADIUS as the web
frontend for management. I was able to get the test Linux servers PAM
configured to point to the Freeradius server, and I can authenticate
myself, and the other admins. However, it appears that, by default, all
users can SSH into any of the NAS devices I've configured. This is the
main issues I'm trying to solve. How, exactly, do I configure Freeradius
to only allow certain vendor accounts SSH access into specific NAS devices?

Thank you
-
List info/subscribe/unsubscribe? See http://www.freera

[Alan DeKok]

Post by Daniel Bray
I was thinking that a Freeradius solution would be a simple approach to get
all the SSH devices (Linux and Cisco) pointing to a single server for
authentication purposes.

RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.

Post by Daniel Bray
Here comes the issues I face. I got everything setup on a Linux server,
and using MySQL as the backend. I'm also using daloRADIUS as the web
frontend for management. I was able to get the test Linux servers PAM
configured to point to the Freeradius server, and I can authenticate
myself, and the other admins. However, it appears that, by default, all
users can SSH into any of the NAS devices I've configured.

The default configuration of the server is to authenticate users. Which means all known users are allowed in.

Post by Daniel Bray
This is the
main issues I'm trying to solve. How, exactly, do I configure Freeradius
to only allow certain vendor accounts SSH access into specific NAS devices?

You have to set up explicit lists of who's allowed to log in where. Put the data into an SQL table, and write a SELECT statement. Then, put that SELECT statement into the FreeRADIUS configuration.

e.g. if you have a table of "user, NAS", you can do something like this:

if (!"%{SELECT %{User-Name} from nas_control_table WHERE NAS = '%{NAS-IP-Address}' AND USER = '%{User-Name}'}) {
reject
}

Which looks up the user by name and NAS IP. If the SQL statement returns nothing, reject.

You'll have to create a correct schema, table, and query, of course. The above is just an example.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org

[Daniel Bray]

Post by Alan DeKok
RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.

I can take care of that with either Spacewalk, or other scripted
methods. I was mainly looking for a centralized user "database",
focusing on AAA. I've seen comparisons to OpenLDAP and other
directory services, but I'm just not needing the level of Identity
Management that LDAP-based services provide. My main focus is just
(security) authorization.

Post by Alan DeKok
The default configuration of the server is to authenticate users. Which means all known users are allowed in.

Is there any sort of common "trick" to deny users by default? Or, am
I just looking at this wrong....which I'm beginning to think I am. If
the user does not need access, but needs to be created in the
Freeradius database, then I should probably either 1.) reevaluate the
real reason they "need" to be created or 2.) explicitly deny/disable
that user, leaving all the other admins alone with default access.
I'm leaning towards option 2, so that I can just re-enable the vendor
when they need to do work, and then disable (or set some sort of timed
based authentication) when they are done.

Post by Alan DeKok
You have to set up explicit lists of who's allowed to log in where. Put the data into an SQL table, and write a SELECT statement. Then, put that SELECT statement into the FreeRADIUS configuration.

And just to be clear. I should configure all of that with the
/etc/raddb/sites-enabled/default file right after the authorize -> sql
section. Meaning, I should place all my sql if/else statements in
that section. Right?


Thank you so much for your help and guidance.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/li

[Alan DeKok]

Post by Daniel Bray
I can take care of that with either Spacewalk, or other scripted
methods. I was mainly looking for a centralized user "database",
focusing on AAA.

People typically use LDAP for Linux logins. It's a better fit.

Post by Daniel Bray
Is there any sort of common "trick" to deny users by default?

No. Unknown users are denied. Known users are authenticated.

There's no trick. If you want known users to be rejected, you have to tell the server when to do that. There is no default configuration of "do everything I want"

Post by Daniel Bray
Or, am
I just looking at this wrong....which I'm beginning to think I am. If
the user does not need access, but needs to be created in the
Freeradius database, then I should probably either 1.) reevaluate the
real reason they "need" to be created or 2.) explicitly deny/disable
that user, leaving all the other admins alone with default access.

Pretty much.

Post by Daniel Bray
And just to be clear. I should configure all of that with the
/etc/raddb/sites-enabled/default file right after the authorize -> sql
section. Meaning, I should place all my sql if/else statements in
that section. Right?

Yes.

Alan DeKok.


-
List info/subscribe/unsubscribe

[Daniel Bray]

Post by Alan DeKok

Post by Daniel Bray
I just looking at this wrong....which I'm beginning to think I am. If
the user does not need access, but needs to be created in the
Freeradius database, then I should probably either 1.) reevaluate the
real reason they "need" to be created or 2.) explicitly deny/disable
that user, leaving all the other admins alone with default access.

Pretty much.

Post by Daniel Bray
And just to be clear. I should configure all of that with the
/etc/raddb/sites-enabled/default file right after the authorize -> sql
section. Meaning, I should place all my sql if/else statements in
that section. Right?

Yes.

Thanks again. In the end, this is the logic I came up with, and
appears to be doing what I need it to do:

# First, start with the "blanks". Meaning, no group, no NAS IP, no
access...get out.
if (("%{sql:SELECT `groupname` FROM `radusergroup` WHERE
`username`='%{User-Name}'}" == '') || ("%{sql:SELECT `groupname` FROM
`radhuntgroup` WHERE `nasipaddress`='%{NAS-IP-Address}'}" == '')) {
update reply {
Reply-Message := "No known GroupName or NAS IP, get out"
}
reject
}

# Check for specific groups and NAS IPs, else default to get out.
if ("%{sql:SELECT `username` FROM `radusergroup` WHERE `groupname` =
'Admins' AND `username` = '%{User-Name}'}" != '') {
update reply {
Reply-Message := "Welcome Admin, you may access any device."
}
}
elsif (("%{sql:SELECT `username` FROM `radusergroup` WHERE
`groupname` = 'VendorA' AND `username` = '%{User-Name}'}" != '') &&
(NAS-IP-Address == "10.0.0.1")) {
update reply {
Reply-Message := "Welcome VendorA, you may access 10.0.0.1"
}
}
else {
update reply {
Reply-Message := "No known authorized access, get out."
}
reject
}


For future vendors, I see the "elsif" part growing, and
changing....and that's about it. So far, all my tests are working,
and not working as expected.
-
List info/subscribe/unsubscribe? See ht

[Alan DeKok]

Post by Daniel Bray
Thanks again. In the end, this is the logic I came up with, and
# First, start with the "blanks". Meaning, no group, no NAS IP, no
access...get out.
if (("%{sql:SELECT `groupname` FROM `radusergroup` WHERE

PLEASE don't change the meaning or contents of the existing tables. That will confuse anyone who expects the standard meaning.

If you're going to use the radusergroup table, please read this page, which describes how it works:

http://wiki.freeradius.org/modules/Rlm_sql

If that functionality matches what you need, then delete your custom queries, and use the standard configuration.

Post by Daniel Bray
For future vendors, I see the "elsif" part growing, and
changing....and that's about it. So far, all my tests are working,
and not working as expected.

Databases should store data. If your rules require 10+ if/then/else statements which are all identical but for "vendor"... that data belongs in a database. Create a custom schema of user name, NAS IP, group, and vendor. Then write ONE select statement which pulls information from SQL.

It will be much, much, easier to maintain and extend in the future.

Alan DeKok.



-
List info/subscribe/unsubscribe? See ht

[Daniel Bray]

Post by Alan DeKok
PLEASE don't change the meaning or contents of the existing tables. That will confuse anyone who expects the standard meaning.

Actually, once I looked at how detailed the below queries could get, I
noticed I really didn't need the pre-blanks so I removed all the
above.

Post by Alan DeKok
Databases should store data. If your rules require 10+ if/then/else statements which are all identical but for "vendor"... that data belongs in a database. Create a custom schema of user name, NAS IP, group, and vendor. Then write ONE select statement which pulls information from SQL.

True, and good idea. Right now, we just have 1 or 2 vendors to worry
about, so I was doing this as a sort of proof of concept, and also as
a means to use what daloRADIUS comes with.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/user

[Michael Ströder]

Post by Daniel Bray

Post by Alan DeKok
RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.

I can take care of that with either Spacewalk, or other scripted
methods. I was mainly looking for a centralized user "database",
focusing on AAA. I've seen comparisons to OpenLDAP and other
directory services, but I'm just not needing the level of Identity
Management that LDAP-based services provide. My main focus is just
(security) authorization.

At least you have to maintain some Identity Management data somewhere.
LDAP solutions are there. Everything else you have to invent yourself.

Ciao, Michael.