Freeradius with Caller-station-id

[Richard J Palmer]

Hi we have several FreeRadius servers talking in our case to SM SQL and
these work fine for all our users logging in using Username & passwords.

We are just getting a new L2TP link in and with sessions on this link I
want to auhenticate *just* on the calling station ID - there will be a
username/password BUT these are not what we need. I therefore want to be
able to keep username/password for the current sessions, BUT if these
fail authenticate on callingtation ID and return IP address details, etc.

is there a way to do this ? I worked round it previously by hacking the
code BUT I'm sure there is a better way here...

Richard
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Joe Holden]

Post by Richard J Palmer
Hi we have several FreeRadius servers talking in our case to SM SQL
and these work fine for all our users logging in using Username &
passwords.
We are just getting a new L2TP link in and with sessions on this link
I want to auhenticate *just* on the calling station ID - there will be
a username/password BUT these are not what we need. I therefore want
to be able to keep username/password for the current sessions, BUT if
these fail authenticate on callingtation ID and return IP address
details, etc.
is there a way to do this ? I worked round it previously by hacking
the code BUT I'm sure there is a better way here...
Richard
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

Hi Richard,

Is this for 3? I have been trying to workout how to do the same as you
want - not sure how to go about it though.

Not much help I know :)

Thanks,
J
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Richard J Palmer]

Post by Joe Holden
Hi Richard,
Is this for 3? I have been trying to workout how to do the same as
you want - not sure how to go about it though.
Not much help I know :)

It is indirectly for 3 yep :-)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan Buxey]

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

[Richard J Palmer]

Post by Alan Buxey
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)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Richard J Palmer]

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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Joe Holden]

Post by Richard J Palmer
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
}
}
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

               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+of+password%3F

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.

[Joe Holden]

Post by Fajar A. Nugraha

Post by Richard J Palmer
update request {
User-Name := "%{Calling-Station-Id}"
User-Password :="SIMUSER"
}

Are you SURE your clients use CHAP?

Post by Richard J Palmer
They may be a better way... but this seems to work :-)

http://wiki.freeradius.org/FAQ#How+do+I+permit+access+to+any+user+regardless+of+password%3F
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

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
...
}

[Joe Holden]

Post by Fajar A. Nugraha

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?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Fajar A. Nugraha]

Post by Fajar A. Nugraha

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'"
   ...
}

[Joe Holden]

Post by Fajar A. Nugraha

Post by Fajar A. Nugraha

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 ***@domain
scenario

Thanks for the pointers though, will definitely come in handy

Thanks,
J
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Joe Holden
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?

Post by Joe Holden
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

[Richard J Palmer]

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 ...

Post by Alan DeKok

Post by Joe Holden
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?

Post by Joe Holden
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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan Buxey]

Hi,

Post by Richard J Palmer
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Richard J Palmer
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.

Post by Richard J Palmer
2) On those that do match I do want per session settings - ie to return
a IP address.

So... figure that out.

Post by Richard J Palmer
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Richard J Palmer]

Post by Alan DeKok
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 ....


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Joe Holden]

Post by Richard J Palmer

Post by Alan Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html