It's not a good idea to change the ownership of /etc/shadow from a security and system perspective. Rather than using rlm_unix use rlm_pam instead
Understood and agreed. This is not a production environment. I was just trying to understand how the modules worked. That being said, I am now looking at PAM per your suggestion. Installed the pam-radius client per http://freeradius.org/pam_radius_auth/ and made the changes to /etc/pam.d/. Created the file /etc/raddb/server and uncommented pam from the sites-enabled/default and inner-tunnel files. Added Default Auth-Type = PAM to the users file. Now I get this output after running radtest Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 41569, id=33, length=59 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 = "support", 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 203 ++[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 <support>. 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} -> support 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 33 to 127.0.0.1 port 41569 Waking up in 4.9 seconds. Cleaning up request 0 ID 33 with timestamp +14 Ready to process requests. Not sure why it sez "pam_pass: using pamauth string <radiusd> for pam.conf lookup" whne it is set to look at /etc/pam.d/radiusd Thoughts? many thanks in advance John Dennis wrote:
On 05/21/2010 07:31 PM, sbchem wrote:
Greetings,
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it.
It's not a good idea to change the ownership of /etc/shadow from a security and system perspective. Rather than using rlm_unix use rlm_pam instead. PAM is a much cleaner way to authenticate system users, not just for FreeRADIUS but for all applications authenticating system users. It is the preferred methodology for a variety of reasons.
-- 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-tp28640012p28644421.html Sent from the FreeRadius - User mailing list archive at Nabble.com.