Accept all Auth requests while replying individual parameters

[Pavel Uhliar]

Alan, thank you, for pointing me to Cleartext-Password .


I do not yet fully understand why, I will get some sleep and have another
look into it. But it works now, without any need to use policy to rewrite
username/passwords.

Actually the solution does not seem to be in using Cleartext-Password by
itself, but in operator used in radcheck, From old setup, I was
using Password == xxx . While creating a testbed for Cleartext I used :=
and it all worked. Now even the original setup does work, just changing the
== to := . Not that I would no want to keep using Cleartext-Password, I was
just curious what the actual reason was.

One new info is that only PAP auth in combination with incorrect
credentials did not evaluate the radreply, CHAP/MSCHAP were working fine. I
just did the first test with PAP and assumed the problem is in credentials
and all others will do the same.


Thanks for pointing me to viable solution, Pavel.



On Sat, Feb 20, 2016 at 8:43 PM Alan DeKok <aland at deployingradius.com>
wrote:

> On Feb 20, 2016, at 2:25 PM, Pavel Uhliar wrote:
> > If I understand your response correctly:
> >
> > 1) radreply not working without match in radcheck is by design, there is
> no
> > sense to try to find a way to circumvent it
>
>   Yes.  See the wiki for documentation on how the SQL module works.
>
> > 2) when I switch to Cleartext-Password, I should be able to rewrite
> > logins/passwords
> > in CHAP and MSCHAP requests?
>
>   I have no idea what that means.
>
>   Use Cleartext-Password in the database as the "known good" password.
> Don't use User-Password.
>
>   It's that simple.
>
> > I was ignoring the hint as for me the final
> > solution was to get rid of passwords (both User-Password and
> > Cleartext-Password)
> > from the database completely (I do not need them when I ignore them), so
> it
> > seemed to me as a useless to try to move to Cleartext-Password.
>
>   If you're not going to check passwords, you can get rid of all passwords
> in the DB.
>
>   But... this likely won't work for MS-CHAPv2.
>
> > Your recommendation is to solve CHAP rewrites
>
>   What is a "CHAP rewrite" ?
>
>   Please explain.
>
> > by using Cleartext-Password,
> > use rewrite policy to match radcheck, which will enable me to use
> radreply
> > again. Did I get it right?
>
>   No.
>
>   By using Cleartext-Password, you're not *checking* User-Password in the
> packet against User-Password in the SQL database.
>
>   Instead, you're telling the server to just remember Cleartext-Password
> for the user.
>
>   Again, all of this is documented.  Read "man rlm_pap", and the wiki
> documentation for the SQL module.
>
> > Is your hint "use Calling-Station-Id, then use it for *both* radcheck and
> > radgroupcheck" an important part in the solution, i.e. for some internal
> > RADIUS binding of radreply-radgroupreply?
>
>   I have no idea what you mean by "internal RADIUS binding".  There is no
> magic here.  See the wiki for how the SQL module works.  This is all
> documented.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html