Hi, I'm trying to get the the pam radius module to work. I've built a test radius server (FreeRADIUS Version 2.1.9) and I've setup a linux box with the pam radius module (1.3.17) The server seems to be setup properly to authenticate users: # radtest testing password 127.0.0.1 0 testing123 Sending Access-Request of id 87 to 127.0.0.1 port 1812 User-Name = "testing" User-Password = "password" NAS-IP-Address = 127.0.1.1 NAS-Port = 0 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=87, length=20 I have the following config on the server to correspond to my pam radius client: clients.conf: client testclient1 { ipaddr = CLIENTIP secret = testing123 require_message_authenticator = no shortname = testc1 nastype = other # localhost isn't usually a NAS... } And on the client (using pam_radius_auth) I have the following in /etc/raddb/server: # server[:port] shared_secret timeout (s) SERVERIP testing123 4 Now, when I try to authenticate my pam radius client, I get this in the client logs: Jul 22 10:22:45 (none) pamtest: pam_radius_auth: Got user name testing Jul 22 10:22:54 (none) pamtest: pam_radius_auth: Sending RADIUS request code 1 Jul 22 10:22:54 (none) pamtest: pam_radius_auth: DEBUG: getservbyname(radius, udp) returned 267885588. Jul 22 10:22:55 (none) pamtest: pam_radius_auth: packet from RADIUS server SERVERIP fails verification: The shared secret is probably incorrect. Jul 22 10:22:55 (none) pamtest: pam_radius_auth: All RADIUS servers failed to respond. Jul 22 10:22:55 (none) pamtest: pam_radius_auth: authentication failed And I get this on the radius server (running in debug mode, i.e. radiusd -X) rad_recv: Access-Request packet from host CLIENTIP port 18580, id=32, length=72 User-Name = "testing" User-Password = "\237TqI\3335Q\231\025O\020bw\021;\362" NAS-Identifier = "other" NAS-Port = 17555 NAS-Port-Type = Virtual Service-Type = Authenticate-Only +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "testing", 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 testing at line 1 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "?TqI�5Q??O?bw?; [pap] Using clear text password "password" [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS! Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> testing 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 32 to CLIENTIP port 18580 Waking up in 4.9 seconds. Cleaning up request 0 ID 32 with timestamp +24 Ready to process requests. Now obviously is says there's a problem with the secret, but I believe I've setup the secret correctly in the configs I've shown above. Does anybody have any ideas what I'm doing wrong? Thanks.
Mike J wrote:
Now obviously is says there's a problem with the secret, but I believe I've setup the secret correctly in the configs I've shown above. Does anybody have any ideas what I'm doing wrong?
Either the password is incorrect, or the MD5 calculations on the PAM or server side are broken. If this is a PPC system, the PAM module might not have been built correctly. You could also try install radclient on the same system as the PAM module. If radclient works and PAM doesn't, then the PAM module wasn't built correctly. See the pam_radius_auth.c file for how to build it. Alan DeKok.
On Fri, Jul 23, 2010 at 4:54 AM, Alan DeKok <aland@deployingradius.com>wrote:
Mike J wrote:
Now obviously is says there's a problem with the secret, but I believe I've setup the secret correctly in the configs I've shown above. Does anybody have any ideas what I'm doing wrong?
Either the password is incorrect, or the MD5 calculations on the PAM or server side are broken.
If this is a PPC system, the PAM module might not have been built correctly.
You could also try install radclient on the same system as the PAM module. If radclient works and PAM doesn't, then the PAM module wasn't built correctly.
See the pam_radius_auth.c file for how to build it.
Alan DeKok.
Thanks Alan. It is a PPC module. However, since I was having problems with it I decided to install the PAM module for my x86 workstation (from the Ubuntu Hardy repository). I'm getting the same results. The client/server talk to each other but the password doesn't seem to be decrypted when the auth request gets to the server. This is why I was thinking maybe I've mis-configured my test server. I've also double checked how I was building the PPC PAM module. I'm using the provided makefile and setting up the compiler and linker to use the proper ppc build tools. Any ideas of where I could be going wrong when compiling it? By the way, this is the entry in the top of my "users" file on my RADIUS server: testing Cleartext-Password := password Is the "Cleartext-Password" option okay with for authenticating PAM clients? Thanks.
Mike J wrote:
It is a PPC module. However, since I was having problems with it I decided to install the PAM module for my x86 workstation (from the Ubuntu Hardy repository). I'm getting the same results. The client/server talk to each other but the password doesn't seem to be decrypted when the auth request gets to the server.
Then the shared secret is wrong. The debug log shows this. Go fix the shared secret.
I've also double checked how I was building the PPC PAM module. I'm using the provided makefile and setting up the compiler and linker to use the proper ppc build tools. Any ideas of where I could be going wrong when compiling it?
Endian issues. It's buried in the source...
By the way, this is the entry in the top of my "users" file on my RADIUS server: testing Cleartext-Password := password
Is the "Cleartext-Password" option okay with for authenticating PAM clients?
Yes. The RADIUS server looks at the contents of the packet, *not* the source code of the client. Alan DeKok.
On Tue, Jul 27, 2010 at 1:22 AM, Alan DeKok <aland@deployingradius.com>wrote:
Mike J wrote:
It is a PPC module. However, since I was having problems with it I decided to install the PAM module for my x86 workstation (from the Ubuntu Hardy repository). I'm getting the same results. The client/server talk to each other but the password doesn't seem to be decrypted when the auth request gets to the server.
Then the shared secret is wrong. The debug log shows this.
Go fix the shared secret.
I've already checked the shared secret. Even though the log message says the shared secret is probably wrong, it isn't. I've fixed the x86 module (was using a wrong client config file). So I have x86 working but don't have the ppc module working.
I've also double checked how I was building the PPC PAM module. I'm using the provided makefile and setting up the compiler and linker to use the proper ppc build tools. Any ideas of where I could be going wrong when compiling it?
Endian issues. It's buried in the source...
Is this likely the cause of my issue?
By the way, this is the entry in the top of my "users" file on my RADIUS server: testing Cleartext-Password := password
Is the "Cleartext-Password" option okay with for authenticating PAM clients?
Yes. The RADIUS server looks at the contents of the packet, *not* the source code of the client.
Thanks for clarifying that.
Mike J wrote:
I've fixed the x86 module (was using a wrong client config file). So I have x86 working but don't have the ppc module working. .. Is this likely the cause of my issue?
Yes. Figure out how to build the MD5 code with the correct endian definitions. Don't be afraid to hard-code the definition in the source. Alan DeKok.
On Fri, Aug 6, 2010 at 12:39 AM, Alan DeKok <aland@deployingradius.com>wrote:
Mike J wrote:
I've fixed the x86 module (was using a wrong client config file). So I have x86 working but don't have the ppc module working. .. Is this likely the cause of my issue?
Yes. Figure out how to build the MD5 code with the correct endian definitions. Don't be afraid to hard-code the definition in the source.
That seemed to work. In case others are interested: in 1.3.17 you have to define "HIGHFIRST" if you are compiling for a big endian arch (ppc in my case). I added "-DHIGHFIRST" to CFLAGS in the makefile, rather than hard-code it in md5.c. Alan, thanks for your help.
participants (2)
-
Alan DeKok -
Mike J