RADDB 2.1.7 and /etc/shadow

[sbchem]

>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 at 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.