Trying to get my sql configuration right.

[John.Hayward at wheaton.edu]

On Sat, 12 Mar 2011, John Dennis wrote:

> Date: Sat, 12 Mar 2011 09:28:10
> From: John Dennis <jdennis at redhat.com>
> To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
> Cc: John.Hayward at wheaton.edu
> Subject: Re: Trying to get my sql configuration right.
> 
> On 03/11/2011 06:33 PM, John.Hayward at wheaton.edu 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...