On Sat, 12 Mar 2011, John Dennis wrote:
Date: Sat, 12 Mar 2011 09:28:10
From: John Dennis <[email protected]>
To: FreeRadius users mailing list <[email protected]>
Cc: [email protected]
Subject: Re: Trying to get my sql configuration right.
On 03/11/2011 06:33 PM, [email protected] wrote:
Hi Radius People,
I am getting the message from sql authentication:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Please update your configuration so that the "known good"
!!!
!!! clear text password is in Cleartext-Password, and not in User-Password.
!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
From other posts the solution is to update the configuration to replace
the attribute "User-Password" to be "Cleartext-Password" in the radcheck
table.
In the radcheck table I actually have "Password" which probably get mapped
to User-Password and then the warning occurs.
If I change an entry in radcheck table to actually have Cleartext-Password
in the radcheck table I get:
====
[pap] WARNING! No "known good" password found for the user. Authentication
may fail because of this.
====
and it fails to authenticate (but does not produce the warning message ;-)
What might be causing the attribute "Password" from the table to get
mapped to "User-Password" and what is suggested that I change to have
radius be happy?
johnh...
To make radius happy follow the very clear instructions from the warning
message ;-)
There is no mapping of Password to User-Password. The correct attribute is
Cleartext-Password in the radcheck table, assure that is the value in the
table and that is the value being returned from the SQL query.
Actually there is equivalent mapping of both Password and User-Password
In the /usr/share/freeradius/dictionary.compat there is:
ATTRIBUTE Password 2 string
encrypt=1
In dictionary.rfc2865 there is:
ATTRIBUTE User-Password 2 string encrypt=1
So when either User-Password or Password are attributes they get set up
the same. While the directions are clear they did not address the
situation that a person has an old style Password attribute in their
database - maybe the message could be changed.
Something else is going on, but we can't tell what because you didn't include
the full output of radiusd -X, but before you post it
you should carefully *read* the output of radiusd -X, it will show you what
values are being returned and how the processing proceeds. If after you've
very carefully read the output *yourself* and and you're still stuck then
post it here.
This was discovered by reading the output myself, then adding additional
debugging, then looking at the code to discover the dictionary
translation. I don't think this could have been divined by the reading of
the log itself (at least I was not able to do so).
Alan DeKok pointed out one needs to also change the operator - that was my
mistake.
What seems to be true is:
1) using Password or User-Password in the attribute along with operator ==
: warning and authenticated
2) using User-Cleartext with the == operator
: no warning - not authenticated (pap does not see Auth-Type
3) using User-Cleartext with the :- operator
: no warning and authenticated
4) (guess) using Password or User-Password along with := operator
: warning and authenticated
Obviously 3 is where we want to be.
johnh...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
