Authentication against the Unix password database?
Hello, I am running freeradius-3.0.14 (stable Gentoo, USE="pam python readline ssl -debug (-firebird) -iodbc -kerberos -ldap -mysql -odbc -oracle -pcap -postgres -sqlite"). I would like my radius server to authenticate users against the Unix password database. Direct authentication is preferred but PAM authentication will do just as well. With the 2.x version I succeeded in doing this by forcing Auth-Type = System in the users file and using the "unix" module, but this no longer works (apparently justifiably so) in the 3.x version. Now I have the following for my default site: authorize { ... unix # files ... } authenticate { ... pam ... } I then get the following somehow puzzling result (with a certified valid Unix user name and password): (2) # Executing section authorize from file /etc/raddb/sites-enabled/default (2) authorize { ... (2) [chap] = noop (2) [mschap] = noop (2) [digest] = noop (2) suffix: Checking for suffix after "@" (2) suffix: No '@' in User-Name = "<del>", looking up realm NULL (2) suffix: No such realm "NULL" (2) [suffix] = noop (2) eap: No EAP-Message, not doing EAP (2) [eap] = noop (2) [unix] = notfound (2) [expiration] = noop (2) [logintime] = noop (2) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (2) pap: WARNING: Authentication will fail unless a "known good" password is available (2) [pap] = noop (2) } # authorize = ok (2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject What I am puzzled about is the "notfound" result provided by the unix module. Next I tried to do PAM authentication by uncommenting the "files" line in the authorize section and forcing "Auth-Type = Pam" in the users file. This one at least communicates with the PAM system: (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { ... (0) [unix] = notfound (0) files: users: Matched entry DEFAULT at line 7 (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = pam (0) # Executing group from file /etc/raddb/sites-enabled/default (0) authenticate { (0) pam: Using pamauth string "radiusd" for pam.conf lookup (0) pam: ERROR: pam_authenticate failed: Authentication failure (0) [pam] = reject (0) } # authenticate = reject (0) Failed to authenticate the user I get the following in the logs (login name redacted): Oct 18 10:23:40 localhost unix_chkpwd[26318]: check pass; user unknown Oct 18 10:23:40 localhost unix_chkpwd[26319]: check pass; user unknown Oct 18 10:23:40 localhost unix_chkpwd[26319]: password check failed for user (<del>) Oct 18 10:23:40 localhost radiusd: pam_unix(radiusd:auth): authentication failure; logname=<del> uid=107 euid=107 tty= ruser= rhost= user=<del> The file /etc/pam.d/radius looks fine to me: auth include system-auth account include system-auth password include system-auth session include system-auth PAM authentication works well with my other subsystems (e.g., sshd). Should more information be needed just ask. If anybody have any idea about what I am doing wrong I would very much appreciate to hear about it. Many thanks in advance! Best regards, Stefan
On Oct 18, 2017, at 11:34 AM, Stefan Bruda <stefan@bruda.ca> wrote:
I would like my radius server to authenticate users against the Unix password database. Direct authentication is preferred but PAM authentication will do just as well.
I wouldn't recommend PAM. It's just terrible.
With the 2.x version I succeeded in doing this by forcing Auth-Type = System in the users file and using the "unix" module, but this no longer works (apparently justifiably so) in the 3.x version.
The "unix" module should be able to call getpwent() or getspwent() to get the password.
I then get the following somehow puzzling result (with a certified valid Unix user name and password):
(2) # Executing section authorize from file /etc/raddb/sites-enabled/default (2) authorize { ...... (2) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (2) pap: WARNING: Authentication will fail unless a "known good" password is available (2) [pap] = noop (2) } # authorize = ok (2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
What I am puzzled about is the "notfound" result provided by the unix module.
Well, it means that either the user doesn't exist, or FreeRADIUS doesn't have permission to get the password. i.e. it can't read /etc/shadow.
Next I tried to do PAM authentication by uncommenting the "files" line in the authorize section and forcing "Auth-Type = Pam" in the users file. This one at least communicates with the PAM system:
(0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { ... (0) [unix] = notfound (0) files: users: Matched entry DEFAULT at line 7 (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = pam (0) # Executing group from file /etc/raddb/sites-enabled/default (0) authenticate { (0) pam: Using pamauth string "radiusd" for pam.conf lookup (0) pam: ERROR: pam_authenticate failed: Authentication failure (0) [pam] = reject (0) } # authenticate = reject (0) Failed to authenticate the user
I get the following in the logs (login name redacted):
Oct 18 10:23:40 localhost unix_chkpwd[26318]: check pass; user unknown Oct 18 10:23:40 localhost unix_chkpwd[26319]: check pass; user unknown
That's a PAM issue. Either the user really is unknown, or FreeRADIUS doesn't have permission to get the users password.
The file /etc/pam.d/radius looks fine to me:
Yup.
auth include system-auth account include system-auth password include system-auth session include system-auth
PAM authentication works well with my other subsystems (e.g., sshd).
Should more information be needed just ask.
If anybody have any idea about what I am doing wrong I would very much appreciate to hear about it. Many thanks in advance!
Run it in debugging mode as root, which should get rid of any file permissions issues. Or, upgrade to 3.0.15. It has lots of fixes over 3.0.4. Or, use "strace" to see what it's doing, and which OS call returns "no such user" to FreeRADIUS. As always, FreeRADIUS is at the mercy of the OS. If the OS decides to tell FreeRADIUS "no such user", then the problem is in the OS. Alan DeKok.
Hello, At 12:25 -0400 on 2017-10-18 Alan DeKok wrote:
Run it in debugging mode as root, which should get rid of any file permissions issues.
Good point. It was a permission issue after all. In the end it looks like I will have to run radius as root to do what I want it to do... I am wondering why this all worked in the 2.x series, but that has nothing to do with the current discussion; I will just have to investigate some more. Thank you for pointing me in the right direction! Best regards, Stefan
participants (2)
-
Alan DeKok -
Stefan Bruda