Not sure if this is the appropriate forum for this, but I'll type it anyway. I have a need to add centralized auth and accounting to unix boxes (specifically a linux based "appliance." It's not really an actual appliance, just a standard linux box that a vendor provides). For my normal unix* boxes I have an identity management system. For appliances and network devices I use Radius, mostly. For this new appliance, I'd like to use Radius, but I don't want to manage users or what groups they belong to on the device itself. I'd like to have the users auth against Radius and then apply a group based on an attribute recieved. I've done a little looking and I see no group support for pam_auth_radius. One thought I had was to add some sort of auto provision function to the pam module to add the user and associate that user with a group via the supplied attribute from radius, then remove the user on logout. Any thoughts on this? Is there some other method that would be more appropriate? I have use for this for other psuedo-appliances. I've tried using LDAP for those, but the chatter with vendor supplied ldap modules was unmanagable. R. Marc
Marc Phillips wrote:
For this new appliance, I'd like to use Radius, but I don't want to manage users or what groups they belong to on the device itself. I'd like to have the users auth against Radius and then apply a group based on an attribute recieved.
I'd like that, too.
I've done a little looking and I see no group support for pam_auth_radius. One thought I had was to add some sort of auto provision function to the pam module to add the user and associate that user with a group via the supplied attribute from radius, then remove the user on logout.
That might work, but I have no idea how to do that. You will likely need a "nss_radius" module (e.g. /etc/nsswitch.conf) However... it's been 10+ years that people have been talking about it, and no one has done anything. Part of the reason is that NSS is incredibly strange, and I've never been able to figure it out. Alan DeKok.
Marc Phillips <rmarc@copacetic.net> wrote:
I've done a little looking and I see no group support for pam_auth_radius. One thought I had was to add some sort of auto provision function to the pam module to add the user and associate that user with a group via the supplied attribute from radius, then remove the user on logout.
...you are quite right. You should be able to use pam_skel (or whatever it is called) to create accounts on the fly, but the groups you will have to sync via other means. Of course, if you are sync'ing groups, you might aswell sync user ids...
Any thoughts on this? Is there some other method that would be more appropriate? I have use for this for other psuedo-appliances. I've tried using LDAP for those, but the chatter with vendor supplied ldap modules was unmanagable.
LDAP is the only way I know, other than a number of shell scripts to push out and keep up to date the passwd/group files by hand. Not impossible and something that many people do. Cheers -- Alexander Clouter .sigmonster says: If ignorance is bliss, why aren't there more happy people?
...you are quite right. You should be able to use pam_skel (or whatever it is called) to create accounts on the fly, but the groups you will have to sync via other means.
Of course, if you are sync'ing groups, you might aswell sync user ids...
Groups are easier. For an appliance, and really most unix boxes, at least in my environments, the number of groups necessary is pretty small and easily configured and managed (a setup once type of thing) whereas the number of users is very large and quite variable. There's no need to sync groups, is my point; just to map an AD group to a unix group (radius authorizes to AD and Authenticates via SecureID). R. Marc
Made a lot of progress on this today. I decided to use pam_sessionrun for a POC rather than worry 'bout writing c code for user add/deletes. It's working somewhat. pam_auth_radius (and perhaps pam in general, not sure yet) seems to want the user to exist or it sends crap for the passwd to radius. Specifically: Feb 17 19:21:22 mypocbox sshd[13804]: pam_radius_auth: Sending RADIUS request password ^M^?INCORRECT So what happens is I created a prelogin event to run a useradd script before it goes to the radius plugin. This works fine, but then sends crap to radius for the passwd. If I kill that ssh session and try again, works fine since the user has been added by the previous session. Hopefully tomorrow I'll solve that mystery, but if somebody has a clue as to why pam_radius_auth sends crap to radius if the user doesn't exist on the machine that would be useful information to have for my work tomorrow. R. Marc `
Marc Phillips wrote:
Specifically:
Feb 17 19:21:22 mypocbox sshd[13804]: pam_radius_auth: Sending RADIUS request password ^M^?INCORRECT
<sigh> *Another* PAM module has decided that the password is wrong, and has over-written it. This prevents any other PAM module from letting the user in. Or maybe it's SSH doing it.
Hopefully tomorrow I'll solve that mystery, but if somebody has a clue as to why pam_radius_auth sends crap to radius if the user doesn't exist on the machine that would be useful information to have for my work tomorrow.
It doesn't. Look in the source, there's nothing about "INCORRECT". As a suggestion, if there are 5-6 pieces of software involved in authentication, don't immediately jump to blaming the PAM radius module. Alan DeKok.
<sigh> *Another* PAM module has decided that the password is wrong, and has over-written it. This prevents any other PAM module from letting the user in. Or maybe it's SSH doing it.
Yeah, figured that; just trying to figure out why. and yes, it's sshd: # strings /usr/sbin/sshd | grep INC INCORRECT
As a suggestion, if there are 5-6 pieces of software involved in authentication, don't immediately jump to blaming the PAM radius module.
Not blaming, just trying to solve a problem. R. Marc
To help others (like us) who hit this issue... R. Marc posted:
Yeah, figured that; just trying to figure out why. and yes, it's sshd:
# strings /usr/sbin/sshd | grep INC INCORRECT
As a suggestion, if there are 5-6 pieces of software involved in authentication, don't immediately jump to blaming the PAM radius module.
Not blaming, just trying to solve a problem.
In our case, sshd_config had an "AllowUsers <blah>" directive to allow only one specific user to login via SSH. For a different username, that directive causes the otherwise correct password to be changed to the value "INCORRECT". That is then passed on to the PAM module and pam_auth_radius sends that INCORRECT password to the RADIUS server, which appropriately denies access. Removing the AllowUsers line allowed ssh logins to succeed in the appropriate cases. If you make the same change, but wish to block some users (e.g., root) from ssh login, be sure to verify that behavior. In our case no further changes were needed. Alan Carwile -- View this message in context: http://freeradius.1045715.n5.nabble.com/pam-auth-radius-tp3388722p4400923.ht... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (4)
-
acarwile -
Alan DeKok -
Alexander Clouter -
Marc Phillips