Accept all Auth requests while replying individual parameters

[Alan DeKok]

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