Accept all Auth requests while replying individual parameters
foto at uhlik.net
Sat Feb 20 20:25:16 CET 2016
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
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
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
(I have the list), and put the Framed-IP-Address and Framed-Routes
instead of radreply.
On Sat, Feb 20, 2016 at 7:33 PM Alan DeKok <aland at deployingradius.com>
> 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
> > 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
> > with group parameters from radgroupreply table (all MySQL). Users are
> > paired to groups by individual entries in usergroup table
> > 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
> 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
> > 2) I add "DEFAULT Auth-Type := Accept" and "Fall-Through=Yes" in
> > /etc/raddb/users file
> > 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
> > 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
> > 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
> > 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
More information about the Freeradius-Users