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@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