Accept all Auth requests while replying individual parameters
Hi guys. 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. 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 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. I don't care about group, I do not need to distinguish between groups anymore, so I can move group parameters to default response once I solve the major issue with sending the individual parameters. 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 when the User-Name/Password in request does not match User-Name/Password in radcheck, RADIUS skips querying the radreply table for additional parameters. 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) Here is comparison of debug output between authorization with valid credentials and invalid ones: Valid: [files] users: Matched entry DEFAULT at line 46 ++[files] returns ok [sql] expand: %{User-Name} -> XXXX [sql] sql_set_user escaped user --> 'XXXX' rlm_sql (sql): Reserving sql socket id: 7 [sql] expand: SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE ... ASC LIMIT 1 -> SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE ... ASC LIMIT 1 WARNING: Found User-Password == "...". WARNING: Are you sure you don't mean Cleartext-Password? WARNING: See "man rlm_pap" for more information. [sql] User found in radcheck table [sql] expand: SELECT id,UserName,Attribute,Value,op FROM radreply WHERE ... ORDER BY id -> SELECT id,UserName,Attribute,Value,op FROM radreply WHERE ... ORDER BY id [sql] expand: SELECT GroupName FROM usergroup WHERE UserName='%{SQL-User-Name}' -> SELECT GroupName FROM usergroup WHERE UserName='XXXX' [sql] expand: SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = '%{SQL-User-Name}' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id -> SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'XXXX' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id [sql] User found in group YYYY [sql] expand: SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = '%{SQL-User-Name}' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id -> SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'XXXX' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id rlm_sql (sql): Released sql socket id: 7 ++[sql] returns ok Found Auth-Type = Accept Auth-Type = Accept, accepting the user expand: Auth-Type: %{control:Auth-Type} -> Auth-Type: Accept Login OK: [XXXX] (from client xxx port xxx cli xxx) Auth-Type: Accept Invalid credentials (output is the same, just the radreply query is missing). [files] users: Matched entry DEFAULT at line 46 ++[files] returns ok [sql] expand: %{User-Name} -> XXXX [sql] sql_set_user escaped user --> 'XXXX' rlm_sql (sql): Reserving sql socket id: 9 [sql] expand: SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE ... ASC LIMIT 1 -> SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE ... ASC LIMIT 1 WARNING: Found User-Password == "...". WARNING: Are you sure you don't mean Cleartext-Password? WARNING: See "man rlm_pap" for more information. [sql] expand: SELECT GroupName FROM usergroup WHERE UserName='%{SQL-User-Name}' -> SELECT GroupName FROM usergroup WHERE UserName='XXXX' [sql] expand: SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = '%{SQL-User-Name}' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id -> SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'XXXX' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id [sql] User found in group YYYY [sql] expand: SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = '%{SQL-User-Name}' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id -> SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'XXXX' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id rlm_sql (sql): Released sql socket id: 9 ++[sql] returns ok Found Auth-Type = Accept Auth-Type = Accept, accepting the user expand: Auth-Type: %{control:Auth-Type} -> Auth-Type: Accept Login OK: [XXXX] (from client xxx port xxx cli xxx) Auth-Type: Accept 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. 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. Another way I was trying was to setup policy that will add parameters "by hand" based on SQL query to radreply table. This I can do for Framed-IP-Address (which is only one for each user), but I am not able to do it for Framed-Route, as there can be zero or multiple Framed-Route entries for every user. I am dead stuck, I will appreciate any hints to solve the problem. Thanks a lot, Pavel
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.
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
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.
Alan, thank you, for pointing me to Cleartext-Password . I do not yet fully understand why, I will get some sleep and have another look into it. But it works now, without any need to use policy to rewrite username/passwords. Actually the solution does not seem to be in using Cleartext-Password by itself, but in operator used in radcheck, From old setup, I was using Password == xxx . While creating a testbed for Cleartext I used := and it all worked. Now even the original setup does work, just changing the == to := . Not that I would no want to keep using Cleartext-Password, I was just curious what the actual reason was. One new info is that only PAP auth in combination with incorrect credentials did not evaluate the radreply, CHAP/MSCHAP were working fine. I just did the first test with PAP and assumed the problem is in credentials and all others will do the same. Thanks for pointing me to viable solution, Pavel. On Sat, Feb 20, 2016 at 8:43 PM Alan DeKok <aland@deployingradius.com> wrote:
On Feb 20, 2016, at 2:25 PM, Pavel Uhliar 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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Pavel Uhliar -
Pavel Uhliar