Hi there ! Could someone please assisst me in configuring FreeRADIUS? I'm quite new to FR and migrated a server from 0.6 on Solaris 8/SPARC to 1.1.7 on Solaris 10/x64. On the old server, the users were authenticated by regular /etc/passwd means. I got this working on the new server. As there are some new features in the later versions, I'd prefer to move the RADIUS users to a separate smbpasswd-like file but I can't get the authentication to work. Some questions: The old server querying itself for a /etc/passwd user: root@old # ./radtest frank XXX localhost 10 test123 Sending Access-Request of id 161 to 127.0.0.1:1812 User-Name = "frank" User-Password = "D[\326<\255h\016A\275\357"%\367\027_y" NAS-IP-Address = XXX NAS-Port-Id = "10" rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=161, length=20 root@old # The old server querying the new one for a /etc/passwd user: root@old # ./radtest frank XXX new 10 test123 Sending Access-Request of id 216 to 10.1.1.12:1812 User-Name = "frank" User-Password = "T)n\244Lec\226\246)U@\366\217&%" NAS-IP-Address = XXX NAS-Port-Id = "10" rad_recv: Access-Accept packet from host 10.1.1.12:1812, id=216, length=20 root@old # The new server querying itself for the exact same user as above: root@new# ./radtest frank XXX localhost 10 test123 Sending Access-Request of id 177 to 127.0.0.1 port 1812 User-Name = "frank" User-Password = "XXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 10 rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=177, length=20 root@new# Why is the password displayed in plain text instead of hashed as on the old server? And how do I configure a separate user file? Currently, I have passwd radpasswd { filename = /opt/freeradius/etc/radpasswd #format = "*User-Name::LM-Password:NT-Password:SMB-Account-CTRL-TEXT::" format = "*User-Name:LM-Password:NT-Password:" delimiter = ":" # authtype = MS-CHAP authtype = PAP hashsize = 0 ignorenislike = yes allowmultiplekeys = no } with radpasswd looking like frank:A:B:Frank Winkler with A and B created by "smbencrypt". I'm pretty unsure about the "authtype". I can post debug outout of radiusd but it looks like it finds the user in the file but cannot authenticate the password. TIA fw
Frank Winkler wrote:
On the old server, the users were authenticated by regular /etc/passwd means. I got this working on the new server. As there are some new features in the later versions, I'd prefer to move the RADIUS users to a separate smbpasswd-like file but I can't get the authentication to work.
<sigh> See the FAQ about "it doesn't work".
Some questions:
The old server querying itself for a /etc/passwd user: root@old # ./radtest frank XXX localhost 10 test123 Sending Access-Request of id 161 to 127.0.0.1:1812 User-Name = "frank" User-Password = "D[\326<\255h\016A\275\357"%\367\027_y" NAS-IP-Address = XXX NAS-Port-Id = "10" rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=161, length=20 root@old #
Why are you looking at the client side? The README, INSTALL, FAQ, and daily messages on this list say that you should run in debug mode. What do we have to add to the documentation to convince you that this is a good idea?
Why is the password displayed in plain text instead of hashed as on the old server?
Because it helps with debugging.
I'm pretty unsure about the "authtype".
Don't set it. I can post debug outout of radiusd
but it looks like it finds the user in the file but cannot authenticate the password.
So... the passwords don't match? If you're unsure as to how the server works, it would be reasonable to assume that you don't know enough to correctly interpret the debug output. Post it here. Alan DeKok.
Alan DeKok wrote:
Why are you looking at the client side? The README, INSTALL, FAQ, and daily messages on this list say that you should run in debug mode. What do we have to add to the documentation to convince you that this is a good idea?
Why is the password displayed in plain text instead of hashed as on the old server?
Because it helps with debugging.
I think you didn't get the point of my question. I was wondering about the difference on two clients querying the same server for the same data.
So... the passwords don't match?
They do but the lookup seems to be incorrect. What I have in the file is the outout of "smbencrypt" but maybe that's not what the server is expecting.
Post it here.
Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1:65271, id=108, length=57 User-Name = "fwvpn" User-Password = "XXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 10 try to find in file rlm_passwd: Added LM-Password: '624AAC413795CDC1AAD3B435B51404EE' to config_items rlm_passwd: Added NT-Password: 'C5A237B7E9D8E708D8436B6148A25FA1' to config_items try to find in file Login incorrect: [fwvpn/cu@34t] (from client localhost port 10) Sending Access-Reject of id 108 to 127.0.0.1 port 65271 The password is displayed in plain text. Regards fw
Frank Winkler wrote:
Why is the password displayed in plain text instead of hashed as on the old server?
Because it helps with debugging.
I think you didn't get the point of my question. I was wondering about the difference on two clients querying the same server for the same data.
Huh? You asked about the difference between a new server and an old server. How does that translate into two clients querying the same server?
So... the passwords don't match?
They do but the lookup seems to be incorrect. What I have in the file is the outout of "smbencrypt" but maybe that's not what the server is expecting.
The server can use NT hashed passwords to perform MS-CHAP authentication.
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1:65271, id=108, length=57 User-Name = "fwvpn" User-Password = "XXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 10 try to find in file rlm_passwd: Added LM-Password: '624AAC413795CDC1AAD3B435B51404EE' to config_items rlm_passwd: Added NT-Password: 'C5A237B7E9D8E708D8436B6148A25FA1' to config_items try to find in file
Why have you massively edited the debug output?
Login incorrect: [fwvpn/cu@34t] (from client localhost port 10) Sending Access-Reject of id 108 to 127.0.0.1 port 65271
The password is displayed in plain text.
Which password? Could you explain which part of the edited output you refer to? In any case, what little you've posted shows that the client is sending a PAP authentication request. Are you sure that you have configured the server to do PAP authentication using NT-hashed passwords? The debug output you've posted conveniently deletes EVERY REFERENCE TO THE AUTHENTICATION PROCESS. i.e. You're asking for help, and making it as hard as possible for anyone to help you. Why? Alan DeKok.
Alan DeKok wrote:
Why have you massively edited the debug output?
I haven't - I just censored the password, that's all! But in fact, it seems that I forgot one occurance :( ...
The password is displayed in plain text.
Which password? Could you explain which part of the edited output you refer to?
The "XXX" above.
In any case, what little you've posted shows that the client is sending a PAP authentication request. Are you sure that you have configured the server to do PAP authentication using NT-hashed
I have tried PAP and CHAP - how do I tell him about NT-hashes? I think that's exactly where it fails.
passwords? The debug output you've posted conveniently deletes EVERY REFERENCE TO THE AUTHENTICATION PROCESS.
That's ll I get! But you're right ... I remember that there was much more output when I tried it the last time. Oops, I accidentally typed "-x" instead of "-X". Here we go again: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1:63689, id=86, length=57 User-Name = "fwvpn" User-Password = "XXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 10 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/opt/freeradius/var/log/radius/radacct/127.0.0.1/auth-detail-20071105' rlm_detail: /opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /opt/freeradius/var/log/radius/radacct/127.0.0.1/auth-detail-20071105 modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 100 modcall[authorize]: module "files" returns ok for request 0 try to find in file rlm_passwd: Added LM-Password: '624AAC413795CDC1AAD3B435B51404EE' to config_items rlm_passwd: Added NT-Password: 'C5A237B7E9D8E708D8436B6148A25FA1' to config_items try to find in file modcall[authorize]: module "radpasswd" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 modcall[authenticate]: module "unix" returns notfound for request 0 modcall: leaving group authenticate (returns notfound) for request 0 auth: Failed to validate the user. Login incorrect: [fwvpn/XXX] (from client localhost port 10) Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 86 to 127.0.0.1 port 63689 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 86 with timestamp 472ee8ce Nothing to do. Sleeping until we see a request. "Auth-Type System" sounds like the culprit ... but I can't find that in radiusd.conf. TIA fw
Frank Winkler wrote:
"Auth-Type System" sounds like the culprit ... but I can't find that in radiusd.conf.
It's in the "users" file. I've deleted it in CVS (what will be 1.1.8, and what will be 2.0). Delete it, AND add "pap" as the last module in the "authorize" section. Also add "pap" in the "authenticate" section. Alan DeKok.
Alan DeKok wrote:
It's in the "users" file. I've deleted it in CVS (what will be 1.1.8, and what will be 2.0).
Indeed: DEFAULT Auth-Type = System Fall-Through = 1
Delete it, AND add "pap" as the last module in the "authorize" section. Also add "pap" in the "authenticate" section.
That did the trick - many thanks! Just out of curiousity: would it also be possible to have both "system" and PAP? Does the order of the config entries influence the search order? TIA fw
Frank Winkler wrote:
Just out of curiousity: would it also be possible to have both "system" and PAP?
Yes.
Does the order of the config entries influence the search order?
The order in the "authenticate" section doesn't matter. The order in the "authorize" section does, because (for example) the PAP module doesn't change pre-existing configuration. Alan DeKok.
participants (2)
-
Alan DeKok -
Frank Winkler