Re: pam_auth_radius
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.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
Marc Phillips rm...@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? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
...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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
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 ` - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius - fallback with localifdown?
Martin Richard wrote: Time permitting I might submit a patch to add some logging to pam_private_session, if there would be interest from the dev team ? Yes, thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius - fallback with localifdown?
Martin Richard wrote: First off - if you think this doesnt belong here, just don't reply instead of being caustic. There is no need to start a message off with that. Thing is, it doesn't work... If I mess up /etc/raddb/server to change the key, the host entry or whatever to make sure I can't reach the radius server, I don't seem to be going down the stack.. I just get denied access and have no trace at all in the logs. I do not think pam_radius_auth is behaving wrongly - looking at the code is simple enough, I do get All RADIUS servers failed to respond in the SYSLOG, so it should clearly be returning PAM_IGNORE as documented. Double-check that it's returning PAM_IGNORE. Maybe source code mods to syslog RETURNING PAM_IGNORE. If it is returning PAM_IGNORE, then it's a PAM problem. Ask the question again on the PAM list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius - fallback with localifdown?
On Wed, Jun 23, 2010 at 4:13 AM, Alan DeKok al...@deployingradius.comwrote:
I do not think pam_radius_auth is behaving wrongly - looking at the
code is simple enough, I do get All RADIUS servers failed to respond
in the SYSLOG, so it should clearly be returning PAM_IGNORE as
documented.
Double-check that it's returning PAM_IGNORE. Maybe source code mods
to syslog RETURNING PAM_IGNORE.
If it is returning PAM_IGNORE, then it's a PAM problem. Ask the
question again on the PAM list.
I've added logging at the end of talk_radius() to confirm that it was
returning PAM_IGNORE, and it was indeed the case. I posted to the pam list,
where someone suggested I used pam_debug to see how the stack reacted to
PAM_IGNORE:
--8---
authrequired pam_debug.so auth=ignore
authrequired /lib/security/$ISA/pam_env.so
authsufficient/lib/security/$ISA/pam_unix.so debug audit
likeauth nullok
authrequired /lib/security/$ISA/pam_deny.so
auth required pam_nologin.so
--8---
I can indeed login with the local auth via pam_unix in this case, so I'm
back at looking at the module's code.. I know talk_radius() is returning
PAM_IGNORE, here's the very last part of the function with my mod:
--8---
if (!server) {
_pam_log(LOG_ERR, All RADIUS servers failed to respond.);
if (conf-localifdown) {
_pam_log(LOG_ERR, Retval = PAM_IGNORE);
retval = PAM_IGNORE;
} else
retval = PAM_AUTHINFO_UNAVAIL;
} else {
retval = PAM_SUCCESS;
}
return retval;
}
--8---
I'll have a look at the rest of the flow, see if it could have been
overriden elsewhere after that call.. I've never coded a pam module, am I
correct to guess that since I'm calling the module with an auth call from
the stack I should be looking at pam_sm_authenticate() ?
Martin
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius - fallback with localifdown?
On Wed, Jun 23, 2010 at 4:13 AM, Alan DeKok al...@deployingradius.comwrote: Double-check that it's returning PAM_IGNORE. Maybe source code mods to syslog RETURNING PAM_IGNORE. If it is returning PAM_IGNORE, then it's a PAM problem. Ask the question again on the PAM list. Found my problem. The pam_sm_authenticate() does return PAM_IGNORE with localifdown, as expected. Added a lot of logging including the final return value (PAM_IGNORE / 25). I had also tested that the stack was dealing with the ignore properly by using pam_debug.so. So my stack for 'auth' as originally posted works as expected, so I'm quite happy with the fallback setup. What was failing pseudo silently was the call to pam_sm_open_session() (or rather pam_private_session()). I only had this single module listed in the pam conf file, and since nothing was logged, I didn't catch on the fact that my login failures were coming from the 'session' part. Since no success was returned and it was my only line for PAM, it failed and I couldn't logon if the radius servers were unreachable. Time permitting I might submit a patch to add some logging to pam_private_session, if there would be interest from the dev team ? Thanks a lot for the infos and replies. Martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius is not sending the correct Acct-Session-Time.
Hi Alan.
I've been trying to understand some things on the code and the problem
is on the function pam_private_session on the block:
if (status == PW_STATUS_START) {
session_time = time(NULL);
} else {
add_int_attribute(request, PW_ACCT_SESSION_TIME, time(NULL) - session_time);
}
The problem is that session_time loses its inicial value (from the
start packet).
Do you have any suggestion to correct this?
Kindly Bruno Sousa
On Apr 5, 2005 6:27 PM, Alan DeKok [EMAIL PROTECTED] wrote:
Bruno Sousa [EMAIL PROTECTED] wrote:
My problem is that on a accounting packet the Stop hasn't the correct
Acct-Session-Time. The value that is passed from the pam module is the
difference between a date like 1970-01-01 and the date 2005-04-04.
That shouldn't be happening. It should be the *interval* between
the login, and current time.
I'm not sure why that's happening. I suggest reading the source code.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius is not sending the correct Acct-Session-Time.
Bruno Sousa [EMAIL PROTECTED] wrote: The problem is that session_time loses its inicial value (from the start packet). Do you have any suggestion to correct this? I have no idea, sorry. It's *supposed* to work. If it's not, it means that something in PAM has gone wrong. My only suggestion is to delete the code which creates PW_ACCT_SESSION_TIME. The module has NO WAY to determine what the correct value is, so it can't send anything. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius is not sending the correct Start Time.
Thanks Alan for the rapid answer. My problem is that on a accounting packet the Stop hasn't the correct Acct-Session-Time. The value that is passed from the pam module is the difference between a date like 1970-01-01 and the date 2005-04-04. So when I'm seeing the account time of an user the value of the Acct-Session-Time is very big, and is not real. My question is how can I activate the correct accounting using the pam_auth_radius? Kindly Bruno On Apr 5, 2005 2:12 AM, Alan DeKok [EMAIL PROTECTED] wrote: Bruno Sousa [EMAIL PROTECTED] wrote: What happens is that the client machine does not send the correct ConnectTime, for instance the start Time is sent with values like: 1970-01-01 00:59:57. The Reason to disconnect sent on the Stop packet is [7]Not Local. There is no accounting start time RADIUS attribute. There *is* an Acct-Session-Time, but it's a time *interval*, not a date. What can I do, to enable accounting correctly? Perhaps you could explain what you mean by correct ConnectTime, and the start Time. There are no such attributes sent by the PAM module, and no such RADIUS attributes defined anywhere. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius is not sending the correct Acct-Session-Time.
Bruno Sousa [EMAIL PROTECTED] wrote: My problem is that on a accounting packet the Stop hasn't the correct Acct-Session-Time. The value that is passed from the pam module is the difference between a date like 1970-01-01 and the date 2005-04-04. That shouldn't be happening. It should be the *interval* between the login, and current time. I'm not sure why that's happening. I suggest reading the source code. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: pam_auth_radius is not sending the correct Start Time.
Bruno Sousa [EMAIL PROTECTED] wrote: What happens is that the client machine does not send the correct ConnectTime, for instance the start Time is sent with values like: 1970-01-01 00:59:57. The Reason to disconnect sent on the Stop packet is [7]Not Local. There is no accounting start time RADIUS attribute. There *is* an Acct-Session-Time, but it's a time *interval*, not a date. What can I do, to enable accounting correctly? Perhaps you could explain what you mean by correct ConnectTime, and the start Time. There are no such attributes sent by the PAM module, and no such RADIUS attributes defined anywhere. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
