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@deployingradius.com> wrote:
On Feb 20, 2016, at 9:19 AM, Pavel Uhliar <pavel.uhliar@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