Re: Freeradius with Caller-station-id
This can be done for plain auth...one way would be to put a check in the auth section, if the normal auth has failed then fail through to eg perl and have some perl script that checks what you want to check and send back the accept alan
On 15/02/2012 11:52 PM, Alan Buxey wrote:
This can be done for plain auth...one way would be to put a check in the auth section, if the normal auth has failed then fail through to eg perl and have some perl script that checks what you want to check and send back the accept
Not 100% sure what you mean by plain auth ? ADSL L2TP is chap and works OK What I want is for the non ADSL tails (the Data SIMS) the username and password are not any use - I want to auth on the caller ID and no password - the auth is easy - I can set the query to return if the username matches or the caller ID matches BUT I then need to ignore the password, etc. I made some changes in rlm_chap to handle this if I put a flag in the password BUT there must be a way to do this without editing the code (IMO)
I have if you are interested solved this .... I used http://wiki.freeradius.org/Mac-Auth as a guide.... In policy.conf I have added.... rewrite_data_sim_users { if (Calling-Station-Id =~ /(894420000[0-9]{10})/i) { update request { User-Name := "%{Calling-Station-Id}" User-Password :="SIMUSER" } } else { noop } } In sites-available/default I have changed: authorize { preprocess rewrite_data_sim_users Which means IF you get a Calling station in a particular format it changes the username to thie calling station ID and in my case also changes the password... I then have users setup as normal with the username as the SIM ID and a password of SIMUSER They may be a better way... but this seems to work :-) Richard
On 16/02/2012 01:56, Richard J Palmer wrote:
I have if you are interested solved this ....
I used http://wiki.freeradius.org/Mac-Auth as a guide....
In policy.conf I have added....
rewrite_data_sim_users { if (Calling-Station-Id =~ /(894420000[0-9]{10})/i) { update request { User-Name := "%{Calling-Station-Id}" User-Password :="SIMUSER" } } else { noop } }
In sites-available/default I have changed:
authorize { preprocess
rewrite_data_sim_users
Which means IF you get a Calling station in a particular format it changes the username to thie calling station ID and in my case also changes the password... I then have users setup as normal with the username as the SIM ID and a password of SIMUSER
They may be a better way... but this seems to work :-)
Richard That's pretty much what I came up with when writing my last post, just wasn't sure on the specific config
Looks reasonable enough Thanks, J
On Thu, Feb 16, 2012 at 8:56 AM, Richard J Palmer <richard@merula.net> wrote:
update request { User-Name := "%{Calling-Station-Id}" User-Password :="SIMUSER" }
Are you SURE your clients use CHAP?
They may be a better way... but this seems to work :-)
It would work for PAP, in which case you can also just use this: http://wiki.freeradius.org/FAQ#How+do+I+permit+access+to+any+user+regardless... It should not work on (MS)CHAP since both client and server needs to know the password, otherwise the challenge/response process will fail. It's entirely possible though that your clients are configured to use any available authentication method, in which case when chap fails they fallback to PAP. -- Fajar
On 16/02/2012 03:36, Fajar A. Nugraha wrote:
On Thu, Feb 16, 2012 at 8:56 AM, Richard J Palmer<richard@merula.net> wrote:
update request { User-Name := "%{Calling-Station-Id}" User-Password :="SIMUSER" }
Are you SURE your clients use CHAP?
They may be a better way... but this seems to work :-) It would work for PAP, in which case you can also just use this: http://wiki.freeradius.org/FAQ#How+do+I+permit+access+to+any+user+regardless...
It should not work on (MS)CHAP since both client and server needs to know the password, otherwise the challenge/response process will fail.
It's entirely possible though that your clients are configured to use any available authentication method, in which case when chap fails they fallback to PAP.
Due to the design of the mobile network, the actual session is originated from the network rather than the device, which iirc presents only CHAP, but may or may not include a username/password pair and thusly the calling station id can include identifying info such as sim id or phone number Using the Auth-Type method does work, but as the username is the lookup key, it doesn't provide the ability to deliver attributes to the NAS (from what I can see), I ran into this exact issue when first looking at implementing it Thanks, J
On Thu, Feb 16, 2012 at 11:37 AM, Joe Holden <lists@rewt.org.uk> wrote:
Using the Auth-Type method does work, but as the username is the lookup key, it doesn't provide the ability to deliver attributes to the NAS (from what I can see),
Sure it does. update reply { your-attribute-name := your-attribute-value ... } -- Fajar
On 16/02/2012 04:39, Fajar A. Nugraha wrote:
On Thu, Feb 16, 2012 at 11:37 AM, Joe Holden<lists@rewt.org.uk> wrote:
Using the Auth-Type method does work, but as the username is the lookup key, it doesn't provide the ability to deliver attributes to the NAS (from what I can see), Sure it does.
update reply { your-attribute-name := your-attribute-value ... }
How will that work if for example all my attributes are in a database and are per user? There is essentially *no* username for these sessions, so how does FR lookup the correct records without replacing the username before?
On Thu, Feb 16, 2012 at 11:42 AM, Joe Holden <lists@rewt.org.uk> wrote:
On 16/02/2012 04:39, Fajar A. Nugraha wrote:
On Thu, Feb 16, 2012 at 11:37 AM, Joe Holden<lists@rewt.org.uk> wrote:
Using the Auth-Type method does work, but as the username is the lookup key, it doesn't provide the ability to deliver attributes to the NAS (from what I can see),
Sure it does.
update reply { your-attribute-name := your-attribute-value ... }
How will that work if for example all my attributes are in a database and are per user? There is essentially *no* username for these sessions, so how does FR lookup the correct records without replacing the username before?
That depends on your needs, obviously. If you need per-user attributes, then yes, the easiest way is probably to just change the value of username. However, if you give out the SAME attribute to all users, then unlang is cleaner. Or if you have only several (e.g. one) unique attribute per user, you can also just get that attribute using unlang, e.g. update reply { your-attribute-name := "%{sql: SELECT value FROM radreply WHERE username='%{Calling-Station-Id}' AND attribute='your-attribute-name'" ... } -- Fajar
On 16/02/2012 04:46, Fajar A. Nugraha wrote:
On Thu, Feb 16, 2012 at 11:42 AM, Joe Holden<lists@rewt.org.uk> wrote:
On 16/02/2012 04:39, Fajar A. Nugraha wrote:
On Thu, Feb 16, 2012 at 11:37 AM, Joe Holden<lists@rewt.org.uk> wrote:
Using the Auth-Type method does work, but as the username is the lookup key, it doesn't provide the ability to deliver attributes to the NAS (from what I can see), Sure it does.
update reply { your-attribute-name := your-attribute-value ... }
How will that work if for example all my attributes are in a database and are per user? There is essentially *no* username for these sessions, so how does FR lookup the correct records without replacing the username before? That depends on your needs, obviously.
If you need per-user attributes, then yes, the easiest way is probably to just change the value of username.
However, if you give out the SAME attribute to all users, then unlang is cleaner. Or if you have only several (e.g. one) unique attribute per user, you can also just get that attribute using unlang, e.g.
update reply { your-attribute-name := "%{sql: SELECT value FROM radreply WHERE username='%{Calling-Station-Id}' AND attribute='your-attribute-name'" ... }
That is rather cute, although being able to treat the incoming session calling station id as the username scales better, as then the phone numbers can be treated as users just like any other typical user@domain scenario Thanks for the pointers though, will definitely come in handy Thanks, J
Joe Holden wrote:
How will that work if for example all my attributes are in a database and are per user?
I thought you said there was no user name... how can the attributes be per user if there is no user name?
There is essentially *no* username for these sessions, so how does FR lookup the correct records without replacing the username before?
The SQL queries are editable for precisely this reason. You edit them. This is NOT a commercial product, where the SQL qeuries && other configuration is hidden inside of a binary blob. If you don't like what FreeRADIUS does, change it. It's YOUR responsibility to figure out how. Alan DeKok.
There are two reasons for my approach: 1) The radius server is also serving other requests that DO have a username password it is only certain logins I need to process differently - those where the caller ID matches a pattern. 2) On those that do match I do want per session settings - ie to return a IP address. This way seems to achieve that mix easily and seems to work. I'm happy for suggestions as ever ... On 16/02/2012 7:57 AM, Alan DeKok wrote:
Joe Holden wrote:
How will that work if for example all my attributes are in a database and are per user? I thought you said there was no user name... how can the attributes be per user if there is no user name?
There is essentially *no* username for these sessions, so how does FR lookup the correct records without replacing the username before? The SQL queries are editable for precisely this reason. You edit them.
This is NOT a commercial product, where the SQL qeuries&& other configuration is hidden inside of a binary blob. If you don't like what FreeRADIUS does, change it.
It's YOUR responsibility to figure out how.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
There are two reasons for my approach:
1) The radius server is also serving other requests that DO have a username password it is only certain logins I need to process differently - those where the caller ID matches a pattern. 2) On those that do match I do want per session settings - ie to return a IP address.
I already gave the answer. if you want the User-Name as your DB index key then simply copy the Calling-Station-ID to the User-Name value in your PERL or in unlang before using SQL auth (if not using PERL) alan
Richard J Palmer wrote:
There are two reasons for my approach:
1) The radius server is also serving other requests that DO have a username password it is only certain logins I need to process differently - those where the caller ID matches a pattern.
So... write code to match that pattern, and treat those requests differently.
2) On those that do match I do want per session settings - ie to return a IP address.
So... figure that out.
This way seems to achieve that mix easily and seems to work.
I'm happy for suggestions as ever ...
Write down what you want to do. Use English. Refer to packets, attributes, and values of those attributes. Refer to contents of databases. Use the contents of the attributes to look up information in a database. That should be 4-5 paragraphs of text at most. Then... convert it to unlang. The majority of problems people have is in defining what they want to do. They ask for help with messages like "I want to do stuff!". OK... WHAT do you want to do? They don't know... but they know want want to do stuff, and they know we're not being helpful! Help yourself. Understand the problem *independent* of FreeRADIUS. Then, configure FreeRADIUS to solve your problem. Alan DeKok.
On 16/02/2012 9:00 AM, Alan DeKok wrote:
Write down what you want to do. Use English. Refer to packets, attributes, and values of those attributes. Refer to contents of databases. Use the contents of the attributes to look up information in a database.
That should be 4-5 paragraphs of text at most.
I have - I provided a solution to the list - and it works ....
On 16/02/2012 00:15, Richard J Palmer wrote:
On 15/02/2012 11:52 PM, Alan Buxey wrote:
This can be done for plain auth...one way would be to put a check in the auth section, if the normal auth has failed then fail through to eg perl and have some perl script that checks what you want to check and send back the accept
Not 100% sure what you mean by plain auth ?
ADSL L2TP is chap and works OK
What I want is for the non ADSL tails (the Data SIMS) the username and password are not any use - I want to auth on the caller ID and no password - the auth is easy - I can set the query to return if the username matches or the caller ID matches BUT I then need to ignore the password, etc.
I made some changes in rlm_chap to handle this if I put a flag in the password BUT there must be a way to do this without editing the code (IMO) Could you perhaps do a check for callerid pattern and use that as the lookup key by rewriting the attribute in the request? Not sure if it's possible to rewrite the username, but changing the password to a defined value such as "password" should work I think? Would satisfy the CHAP request anyway... Unless it's possible to have radius ignore the password with an Auth-Type response
Not got a spare sim to test with at the mo, can't see why it isn't doable though Thanks, J
participants (5)
-
Alan Buxey -
Alan DeKok -
Fajar A. Nugraha -
Joe Holden -
Richard J Palmer