On Feb 20, 2016, at 2:25 PM, Pavel Uhliar <foto@uhlik.net> 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.