Dear Alan!
See the FAQ about pointless statements like "it doesn't work".
Alan, please, you asked me to try := instead of == . I did and it does not work. Somehow I needed to inform you it did not.
Maybe you could try reading the debug output. Or failing that, posting it here. I did in my first post. Would you please explain me, why freeradius only process one record, when it does process both while using users file?
Is it possible perhaps to make the PAP module understand both CRYPT and plaintext passwords (perhaps by defining two instances of module)? I can in this case keep one record per user, and it will be cleartext for PAP and MS-CHAPv2 when the user is granted services requiring MS-CHAPv2 and CRYPT for all existing users otherwise.
Then those users can't do MS-CHAP. C'mon. This is not an answer... I can't just ignore all of my existing users and I can't make all of them to change their passwords and, as far as I know, I can't extract their passwords from the crypt hash. I really do not want to start hacking freeradius code, but on the other side I really do need to make the new services available to these users.
Stop trying to get both clear & crypted passwords to work for the same user.
Why does it work perfectly as expected when I am doing it in users file? Should not the SQL module perform the same? I am reposting the debug output here, just in case.... rad_recv: Access-Request packet from host 192.168.0.8:1061, id=7, length=45 User-Name = "atest" User-Password = "Master1" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "atest", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry DEFAULT at line 171 users: Matched entry DEFAULT at line 173 modcall[authorize]: module "files" returns ok for request 0 radius_xlat: 'atest' rlm_sql (sql): sql_set_user escaped user --> 'atest' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'atest' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 4 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'atest' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = 'atest' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'atest' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 4 modcall[authorize]: module "sql" returns ok for request 0 modcall[authorize]: module "domainmschap" returns noop for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type PAP auth: type "PAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_pap: login attempt by "atest" with password Master1 rlm_pap: Using password "Master1" for user atest authentication. rlm_pap: Using CRYPT encryption. rlm_pap: Passwords don't match modcall[authenticate]: module "pap" returns reject for request 0 modcall: group Auth-Type returns reject for request 0 auth: Failed to validate the user. Login incorrect (rlm_pap: CRYPT password check failed): [atest/Master1] (from client rasdata port 0) 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 7 to 192.168.0.8:1061 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 7 with timestamp 4400b816 Nothing to do. Sleeping until we see a request.
"Alex Savguira" <savguira@gmail.com> wrote:
Alan, please, you asked me to try := instead of == . I did and it does not work. Somehow I needed to inform you it did not.
You need to post the debug log of it using the "users" file entry after you changed == to :=/
I did in my first post. Would you please explain me, why freeradius only process one record, when it does process both while using users file?
I have no idea. And the debug log you posted was BEFORE you made the change, so it's not that helpful.
Is it possible perhaps to make the PAP module understand both CRYPT and plaintext passwords (perhaps by defining two instances of module)?
The server already handles crypt'd passwords. You shouldn't have to do anything.
I can in this case keep one record per user, and it will be cleartext for PAP and MS-CHAPv2 when the user is granted services requiring MS-CHAPv2 and CRYPT for all existing users otherwise.
That's what I've been trying to say. A number of times. DO THAT.
Then those users can't do MS-CHAP. C'mon. This is not an answer... I can't just ignore all of my existing users and I can't make all of them to change their passwords and, as far as I know, I can't extract their passwords from the crypt hash.
Yes, I understand. However, it's IMPOSSIBLE to use crypted passwords with MS-CHAP. If you have a crypt'd password, then the user can't do MS-CHAP. For pete's sake, what do I have to do to convince people that it's impossible? Stop arguing and accept it. Yes, it's unfriendly to your users. Tough. You shouldn't have stored the passwords in crypt'd form in the first place. That choice made MS-CHAP impossible for those users. Don't complain to me about it. I didn't create your local config, the crypt algorithm or the MS-CHAP algorithm.
I really do not want to start hacking freeradius code, but on the other side I really do need to make the new services available to these users.
Great. I'll give you a million dollars if you can make FreeRADIUS authenticate MS-CHAP when it has nothing more than the crypt'd password. Did I mention it was impossible?
Why does it work perfectly as expected when I am doing it in users file? Should not the SQL module perform the same?
No. The "users" file is processed to bottom. The SQL module grabs the first matching entry. Didn't you read the previous response that explained this? Alan DeKok.
participants (2)
-
Alan DeKok -
Alex Savguira