No, that's for authenticating against radius, different beast entirely
Okay, understood and removed all traces of it and changes to files I made except left Auth-Type = pam in the users file
If you're using the Red Hat RPM's that shouldn't be necessary, we already include the pam configuration >file matched to our systems.
Notes in pam module says that the module points to /etc/pam.d/radiusd. I made sure that a file named radiusd lives in /etc/pam.d and that it has proper ownership (root) and permissions (644) My dostro is CentOS so based on your cmment I assume theres is no need to do any config of that file as it comes prepackaged with the raddb rpm So no further along as this radtest output shows: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 41299, id=112, length=56 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 205 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = PAM +- entering group authenticate {...} pam_pass: using pamauth string <radiusd> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown ++[pam] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 112 to 127.0.0.1 port 41299 Waking up in 4.9 seconds. Cleaning up request 0 ID 112 with timestamp +3 Ready to process requests. So the entry: pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown is obviously supposed to give me the clue I need but I have no idea what it means. The pam module in /etc/raddb/modules is pointing to a file named radiusd in /etc/pam.d That file exists withthe correct ownership and privileges and is suposed to contain whatever it needs straight out of the box. If I omit the Auth-Type = pam from the users files, the pam module error goes away but it also is not checking pam so it looks like I ined to tell the server the auth-type. Stumped. Googling the error message returns a post Alan made several years ago <Markus.Wintruff@data...> wrote:
pam_pass: function pam_authenticate FAILED for <wolfmar>. Reason: Module is unknown
And it doesn't tell you which module. Wonderful. People actually use this stuff? And get it to work? Wow...
Is ist possible to debug PAM?
Not really. Now you know why I'm so insistent on adding debugging messages to FreeRADIUS, and on asking people to look at them. Alan DeKok. Which I find slighlty amusing because the debug output is exactly that message -"Module unknown" A more terse reply of Alan's is less amusing: Alex Wang <[EMAIL PROTECTED]> wrote:
pam_pass: using pamauth string <radiusd-fcums1.dat> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <guest28>. Reason: Module is unknown
That should be fairly clear. Read the PAM docs.
Is anybody kindly can help me figure out where the problem is?
You haven't configured PAM properly. Alan DeKok. So no further along on pam -- illumination anyone or more fog please? Cheers! John Dennis wrote:
On 05/22/2010 05:37 PM, sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per http://freeradius.org/pam_radius_auth/
No, that's for authenticating against radius, different beast entirely.
and made the changes to /etc/pam.d/.
If you're using the Red Hat RPM's that shouldn't be necessary, we already include the pam configuration file matched to our systems.
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28650164.html Sent from the FreeRadius - User mailing list archive at Nabble.com.