Please HELP!!! Any ideas??? MySQL and users file... Difference???

[Alex Savguira]

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.