I'm trying to setup a freeradius server on freebsd7 to authenticate against the local passwd file and seem to be running into some problems. in sites-available/default I setup authorize/authenticate such as: authorize { preprocess chap mschap suffix unix files expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix } and /etc/pam.d/radiusd setup such as: # auth auth required pam_unix.so no_warn try_first_pass # account account required pam_nologin.so account required pam_login_access.so account required pam_unix.so # session session required pam_permit.so # password password required pam_unix.so no_warn try_first_pass And I get this output: rad_recv: Access-Request packet from host 10.10.10.231 port 57714, id=94, length=96 User-Name = "testuser" Service-Type = Login-User NAS-IP-Address = 10.10.10.140 NAS-Port = 4 Calling-Station-Id = "10.10.10.140" NAS-Port-Type = Virtual User-Password = "testpass" NAS-Port-Id = "tty4" +- entering group authorize {...} [preprocess] hints: Matched DEFAULT at 23 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Type} -> Access-Request [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] hints: Matched DEFAULT at 87 [preprocess] hints: Matched DEFAULT at 76 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "testuser", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[unix] returns updated [files] users: Matched entry DEFAULT at line 2 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "testpass" [pap] Using CRYPT encryption. [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. Login incorrect (rlm_pap: CRYPT password check failed): [testuser/testpass] (from client boss1_internal port 4 cli 10.10.10.140) Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> testuser attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 94 to 10.10.10.231 port 57714 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 94 with timestamp +10 Ready to process requests. The password is correct, I'm not sure if the CRYPT encryption method is correct because I believe the passwords are stored as md5 hashes in the passwd file, any idea where I may be going wrong?
Try to define pap { auto_header = yes } Quoting James Devine : I'm trying to setup a freeradius server on freebsd7 to authenticate against the local passwd file and seem to be running into some problems. in sites-available/default I setup authorize/authenticate such as: authorize { preprocess chap mschap suffix unix files expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix } and /etc/pam.d/radiusd setup such as: # auth auth required pam_unix.so no_warn try_first_pass # account account required pam_nologin.so account required pam_login_access.so account required pam_unix.so # session session required pam_permit.so # password password required pam_unix.so no_warn try_first_pass And I get this output: rad_recv: Access-Request packet from host 10.10.10.231 port 57714, id=94, length=96 User-Name = "testuser" Service-Type = Login-User NAS-IP-Address = 10.10.10.140 NAS-Port = 4 Calling-Station-Id = "10.10.10.140" NAS-Port-Type = Virtual User-Password = "testpass" NAS-Port-Id = "tty4" +- entering group authorize {...} [preprocess] hints: Matched DEFAULT at 23 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Type} -> Access-Request [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] hints: Matched DEFAULT at 87 [preprocess] hints: Matched DEFAULT at 76 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 [preprocess] expand: %{Packet-Src-IP-Address} -> 10.10.10.231 ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "testuser", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[unix] returns updated [files] users: Matched entry DEFAULT at line 2 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "testpass" [pap] Using CRYPT encryption. [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. Login incorrect (rlm_pap: CRYPT password check failed): [testuser/testpass] (from client boss1_internal port 4 cli 10.10.10.140) Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> testuser attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 94 to 10.10.10.231 port 57714 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 94 with timestamp +10 Ready to process requests. The password is correct, I'm not sure if the CRYPT encryption method is correct because I believe the passwords are stored as md5 hashes in the passwd file, any idea where I may be going wrong? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Links: ------ [1] mailto:fxmulder@gmail.com
James Devine wrote:
I'm trying to setup a freeradius server on freebsd7 to authenticate against the local passwd file and seem to be running into some problems.
and /etc/pam.d/radiusd setup such as:
Err... why? You don't need to use PAM to authenticate against the password file.
++[unix] returns updated
i.e. it found the user via getpwent(). And you haven't configured it to use PAM at all.
[pap] login attempt with password "testpass" [pap] Using CRYPT encryption. [pap] Passwords don't match
Well... is there a user in /etc/passwd with that name && password?
The password is correct, I'm not sure if the CRYPT encryption method is correct because I believe the passwords are stored as md5 hashes in the passwd file, any idea where I may be going wrong?
The passwords are likely stored as salted MD5 hashes. And the authentication is done by calling the crypt() function on your local system. Since the system supports MD5 passwords, crypt() should support them, too. Alan DeKok.
the problem seems to be that getpwnam in rlm_unix is getting '*' for the encrypted password when not running as root, this works fine if it runs as root. Is there another way of retrieving the password from the passwd file without having to run as root? On Thu, Feb 4, 2010 at 1:10 AM, Alan DeKok <aland@deployingradius.com> wrote:
James Devine wrote:
I'm trying to setup a freeradius server on freebsd7 to authenticate against the local passwd file and seem to be running into some problems.
and /etc/pam.d/radiusd setup such as:
Err... why?
You don't need to use PAM to authenticate against the password file.
++[unix] returns updated
i.e. it found the user via getpwent().
And you haven't configured it to use PAM at all.
[pap] login attempt with password "testpass" [pap] Using CRYPT encryption. [pap] Passwords don't match
Well... is there a user in /etc/passwd with that name && password?
The password is correct, I'm not sure if the CRYPT encryption method is correct because I believe the passwords are stored as md5 hashes in the passwd file, any idea where I may be going wrong?
The passwords are likely stored as salted MD5 hashes.
And the authentication is done by calling the crypt() function on your local system. Since the system supports MD5 passwords, crypt() should support them, too.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
James Devine wrote:
the problem seems to be that getpwnam in rlm_unix is getting '*' for the encrypted password when not running as root, this works fine if it runs as root. Is there another way of retrieving the password from the passwd file without having to run as root?
Read radiusd.conf. Look for "shadow". Alan DeKok.
I'm assuming you're referring to the shadow group? That wouldn't work on freebsd though, I tried setting group to wheel with no success. On Thu, Feb 4, 2010 at 8:52 AM, Alan DeKok <aland@deployingradius.com> wrote:
James Devine wrote:
the problem seems to be that getpwnam in rlm_unix is getting '*' for the encrypted password when not running as root, this works fine if it runs as root. Is there another way of retrieving the password from the passwd file without having to run as root?
Read radiusd.conf. Look for "shadow".
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
on freebsd there is no /etc/shadow, it is /etc/master.passwd A man on getpwnam shows: These routines have been written to ``shadow'' the password file, e.g. allow only certain programs to have access to the encrypted password. If the process which calls them has an effective uid of 0, the encrypted password will be returned, otherwise, the password field of the returned structure will point to the string `*'. On Thu, Feb 4, 2010 at 9:23 AM, Alan DeKok <aland@deployingradius.com> wrote:
James Devine wrote:
I'm assuming you're referring to the shadow group? That wouldn't work on freebsd though,
Why not?
I tried setting group to wheel with no success.
So... add a group "shadow". chgrp shadow /etc/shadow. I don't see why that wouldn't work.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
James Devine -
Konstantin Chekushin