Accept all Auth requests while replying individual parameters

[Pavel Uhliar]

Hi, Alan.

Thanks for quick reply.

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

2) when I switch to Cleartext-Password, I should be able to rewrite
logins/passwords
in CHAP and MSCHAP requests? 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.


Your recommendation is to solve CHAP rewrites by using Cleartext-Password,
use rewrite policy to match radcheck, which will enable me to use radreply
again. Did I get it right?


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 do not use radgroupcheck at the
moment. Of course once I do not get unique/reliable User-Name in Auth
request, I need to switch to unique Calling-Station-Id to assign user to
correct group. In fact over the years the all the groups but one
diminished, so I am free to move parameters from the remaining group to
DEFAULT and leave the group design completely.

Now when I think about groups, one quite weird but probably workable
solution of my problem could be to create an individual group for
every Calling-Station-Id
(I have the list), and put the Framed-IP-Address and Framed-Routes
into radgroupreply
instead of radreply.

Thanks, Pavel


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

> On Feb 20, 2016, at 9:19 AM, Pavel Uhliar <pavel.uhliar at gmail.com> wrote:
> > I am trying to modify existing FreeRADIUS setup (version 2.1.12) to
> accept
> > all Auth requests, while responding to them with individual parameters
> > (Framed-IP-Address and Framed-Route) based on Calling-Station-Id.
>
>   You should really upgrade.
>
> > I am in a running environment, where until now login requests are
> > authorized by User-Name/Password based on radcheck table and individual
> > parameters are sent based on the User-Name from radreply table and
> combined
> > with group parameters from radgroupreply table (all MySQL). Users are
> > paired to groups by individual entries in usergroup table
>
>   OK...
>
> > I would like to keep intact as much of the structure as possible, I just
> > need to stop verifying User-Name/Password (because now whoever is able to
> > access physical infrastructure is authorized to use it) and change the
> > individual responses to be based on Calling-Station-Id instead of
> User-Name.
>
>   So put Calling-Station-Id into the "name" field in SQL, and update the
> SQL queries to use Calling-Station-Id instead of the User-Name
>
> > First I thought the solution will be quite simple:
> > 1) I change the SQL query selecting from radreply table to be based on
> > Calling-Station-Id
>
>   Yes.
>
> > 2) I add "DEFAULT Auth-Type := Accept" and "Fall-Through=Yes" in
> > /etc/raddb/users file
>
>   Yes.
>
> > Step 1 is OK, no problem (change in /etc/raddb/sql/mysql/dialup.conf)
> >
> > Problem is in Step 2. It does authorize all requests as expected (even
> > those not matching User-Name/Password records in radcheck table), but
> when
> > the User-Name/Password in request does not match User-Name/Password in
> > radcheck, RADIUS skips querying the radreply table for additional
> > parameters.
>
>   For one, you should NOT be putting User-Password into the radcheck
> table.  It's been wrong for 10 years.  We've recommended Cleartext-Password.
>
>   Two, if you're going to use Calling-Station-Id, then use it for *both*
> radcheck and radgroupicheck.
>
> > This results in Auth response containing only parameters
> > from radgroupreply table, but none from radreply. Requests containing
> > User-Name/Password matching to those in radcheck get full responses
> > (with radgroupreply and radreply)
>
>   Then use Calling-Station-Id everywhere.
> >
> > WARNING: Found User-Password == "...".
> > WARNING: Are you sure you don't mean Cleartext-Password?
> > WARNING: See "man rlm_pap" for more information.
>
>   That's a big hint.
>
> > I was trying to find some solution, did try "query_on_not_found"
> > configuration directive, did play with "Fall-Through", but nothing seems
> to
> > work. I was not able to force RADIUS to do the radreply query for
> > not-matched credentials.
>
>   You don't.  If the radcheck doesn't match, then radreply isn't used.
> This is how the SQL module works.
>
> > As other ways to solve the problem, I was trying to use policy to
> > rewrite User-Name/Password in request to
> > a Calling-Station-Id/<universal-password> to have all request authorized
> > under my control, but this is not feasible as devices do not use only
> PAP,
> > but also CHAP and MSCHAP, and password rewriting does not work for
> > CHAP/MSCHAP requests.
>
>   Which is why you need to use Cleartext-Password in the database.  So it
> can match for CHAP requests, when the packet doesn't contain User-Password.
>
>   The error message recommends reading "man rlm_pap".  This all is
> explained there.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html