Re: freeradius and ADSL-Agent-Circuit-Id
Johan Meiring wrote:
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize {
...
if (ADSL-Agent-Circuit-Id \
(%{sql: select ...})) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
I disagree with the logic slightly.
In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does
not exist.
As fas as I understand, the desireable result is:
If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication
must happen.
If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize {
...
if (ADSL-Agent-Circuit-Id) {
if (%{sql: select ...}) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
}
I have been attempting to implement this advice. I can use a 'select
count(*)' sql query and based on wether the value is 1, I can then set
Auth-Type := Accept just like it's written above. But, there's
additional processing that is desireable that I just can't figure out
how to do here. Instead of just blindly setting Accept, I might want to
proceed with having the sql module do group processing and so forth to
finally accumulate all of the reply attributes that apply to this
request. Maybe that reply is 'Auth-Type := Reject but then others
contain 'Accept' along with framed-ip-address and so forth. This would
involve using a modified sql query in the event that
ADSL-Agent-Circuit-Id is present, and there doesn't appear to be any way
at run time to make that selection.
I am getting the impression that perhaps I need to run maybe a second
server that has it's sql configured with queries tailored for the
presence of this attribute, and then proxy requests from the primary
server to this one in this case. I could probably run it on lookback on
another port so that the radius clients don't have to know anything
about it. Still it's a bit of work but that seems to be the only way
possible to make sql query one database if the attribute is present, and
query another if it's not (or, use different queries).
Would love more insight if anyone cares to share.
Thank you.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: freeradius and ADSL-Agent-Circuit-Id
Try the following:
Add this to the top of the Authorize section:
authorize {
if ADSL-Agent-Circuit-Id {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
User-Password := %{ADSL-Agent-Circuit-Id}
}
}
Then, add the Circuit-IDs to radcheck:
mysql select * from radcheck where username = circuit-123;
++-+---++-+
| id | username| attribute | op | value |
++-+---++-+
| 226536 | circuit-123 | ADSL-Agent-Circuit-Id | == | circuit-123 |
| 226537 | circuit-123 | Cleartext-Password| := | circuit-123 |
++-+---++-+
2 rows in set (0.00 sec)
Then run a test to make sure that when using the Circuit-Id to authenticate
the device, the ADSL-Agent-Circuit-Id must be in the request.
[r...@sparky performance]# cat circuit-id.rad
User-Name = test
User-Password = FreeRADIUS
User-Name = circuit-123
User-Password = circuit-123
User-Name =
ADSL-Agent-Circuit-Id =circuit-123
User-Name = void
ADSL-Agent-Circuit-Id =circuit-123
[r...@sparky performance]#
[r...@sparky performance]# radclient -f circuit-id.rad localhost auth
FreeRADIUS
Received response ID 81, code 2, length = 20
Received response ID 165, code 3, length = 20
Received response ID 157, code 2, length = 20
Received response ID 119, code 2, length = 20
[r...@sparky performance]#
Tim
-Original Message-
From: freeradius-users-
bounces+tim.sylvester=networkradius@lists.freeradius.org
[mailto:freeradius-users-
bounces+tim.sylvester=networkradius@lists.freeradius.org] On Behalf
Of Mike
Sent: Wednesday, July 28, 2010 3:37 PM
To: FreeRadius users mailing list
Subject: Re: freeradius and ADSL-Agent-Circuit-Id
Johan Meiring wrote:
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize {
...
if (ADSL-Agent-Circuit-Id \
(%{sql: select ...})) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
I disagree with the logic slightly.
In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does
not exist.
As fas as I understand, the desireable result is:
If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication
must happen.
If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize {
...
if (ADSL-Agent-Circuit-Id) {
if (%{sql: select ...}) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
}
I have been attempting to implement this advice. I can use a 'select
count(*)' sql query and based on wether the value is 1, I can then set
Auth-Type := Accept just like it's written above. But, there's
additional processing that is desireable that I just can't figure out
how to do here. Instead of just blindly setting Accept, I might want to
proceed with having the sql module do group processing and so forth to
finally accumulate all of the reply attributes that apply to this
request. Maybe that reply is 'Auth-Type := Reject but then others
contain 'Accept' along with framed-ip-address and so forth. This would
involve using a modified sql query in the event that
ADSL-Agent-Circuit-Id is present, and there doesn't appear to be any
way
at run time to make that selection.
I am getting the impression that perhaps I need to run maybe a second
server that has it's sql configured with queries tailored for the
presence of this attribute, and then proxy requests from the primary
server to this one in this case. I could probably run it on lookback on
another port so that the radius clients don't have to know anything
about it. Still it's a bit of work but that seems to be the only way
possible to make sql query one database if the attribute is present,
and
query another if it's not (or, use different queries).
Would love more insight if anyone cares to share.
Thank you.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
Tim Sylvester wrote:
Try the following:
Add this to the top of the Authorize section:
if ADSL-Agent-Circuit-Id {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
User-Password := %{ADSL-Agent-Circuit-Id}
}
}
Thank you for taking the time to provide this detailed example. I
should have included the previous thread where this was suggested and
that it 'works', but also that it creates a security hole in that an end
user could simply set their user name and password to be the same as a
Circuit-Id, thereby taking advantage of a 'known passwords' if anyone
knows what my circuit id's look like.
The task is to set things up so that _only_ in the event that the
request contains an actual ADSL-Agent-Circuit-Id attribute, that I don't
bother trying to do chap/pap, but instead I pull everything (Including
Access-Accept) from the database indexed by ADSL-Agent-Circuit-Id. If
there is no such attribute, then just proceed as normal. I can use sql
to get a truth value wether the circuit-id is present in a non-default
table, and I can use unlang to update the control with Auth-Type :=
Accept. This works and results in 'access accept' to the client. But,
it does not get me anyway to pull attributes specific to this id and
return them to the client.
What I was talking about was perhaps using the presence of
ADSL-Agent-Circuit-Id to decide whether to proxy the request to another
virtual server. I could configure this virtual server to listen on
loopback so the only way to consult it is thru the proxy, and I could
configure the sql query used on THIS server to peform the authorization
query. This seperation would give me the abillity to either engage
chap/pap or not based on presence of the attribute, instead of simply
overwriting the attribute values which doesn't address my security
concerns. I'm still looking for a good method to accomplish this.
Mike-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: freeradius and ADSL-Agent-Circuit-Id
Tim Sylvester wrote:
Try the following:
Add this to the top of the Authorize section:
if ADSL-Agent-Circuit-Id {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
User-Password := %{ADSL-Agent-Circuit-Id}
}
}
Thank you for taking the time to provide this detailed example. I
should have included the previous thread where this was suggested and
that it 'works', but also that it creates a security hole in that an
end user could simply set their user name and password to be the same as a
Circuit-Id, thereby taking advantage of a 'known passwords' if anyone
knows what my circuit id's look like.
No. You should have read my message in more detail. If you look at the
example below, you will see that if someone tries to use a Username/Password
with the Circuit-Id, the authentication will fail. The second entry for in
the radcheck table requires that both the username/password and the
username/ADSL-Agent-Circuit-Id are required.
The task is to set things up so that _only_ in the event that the
request contains an actual ADSL-Agent-Circuit-Id attribute, that I
don't bother trying to do chap/pap, but instead I pull everything
(Including
Access-Accept) from the database indexed by ADSL-Agent-Circuit-Id. If
there is no such attribute, then just proceed as normal. I can use sql
to get a truth value wether the circuit-id is present in a non-default
table, and I can use unlang to update the control with Auth-Type :=
Accept. This works and results in 'access accept' to the client. But,
it does not get me anyway to pull attributes specific to this id and
return them to the client.
My configuration will allow you to do what you want. Try it before
dismissing it.
What I was talking about was perhaps using the presence of
ADSL-Agent-Circuit-Id to decide whether to proxy the request to another
virtual server. I could configure this virtual server to listen on
loopback so the only way to consult it is thru the proxy, and I could
configure the sql query used on THIS server to peform the authorization
query. This seperation would give me the abillity to either engage
chap/pap or not based on presence of the attribute, instead of simply
overwriting the attribute values which doesn't address my security
concerns. I'm still looking for a good method to accomplish this.
You are welcome to try your much more complicated method. Or you could
re-read my message and perform some actual tests before responding in
e-mail.
Tim
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
On 2010/07/20 10:50 PM, Mike wrote:
authorize {
if %{ADSL-Agent-Circuit-Id} {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
Password := %{ADSL-Agent-Circuit-Id}
}
}
Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to
radcheck and
set the password to the value of ADSL-Agent-Circuit-Id.
++---+++---+
| id | username | attribute | op | value |
++---+++---+
| 226529 | adslagent | Cleartext-Password | := | adslagent |
++---+++---+
This opens up a security hole I wish to avoid - if someone knows what my
circuit Id's look like, and that database is used in any context where a
user can send an id/password to authenticate that does NOT have
ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user
id's for the bad guys to use. I am happy having a non-default sql
database schema but I think I really need the sql lookup to be being
based on ADSL-Agent-Circuit-Id and not User-Name.
Mike-
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
How about this:
I'm 100% sure my syntax is wrong today (I'm not an unlang master yet), but
the idea should work.
Opinions?
authorize {
if %{ADSL-Agent-Circuit-Id} {
if (%{sql: select count(*) from CircuitIdList where
CircuitId='%{ADSL-Agent-Circuit-Id}'} 1)
{
Auth-Type = Accept
}
else
{
Auth-Type = Reject
}
}
--
Johan Meiring
Cape PC Services CC
Tel: (021) 883-8271
Fax: (021) 886-7782
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
Johan Meiring wrote:
I'm 100% sure my syntax is wrong today (I'm not an unlang master yet), but
the idea should work.
Opinions?
Close.
- You need to update a specific list.
- you need double quotes around string values
- the parser is *very* specific.
Follow the examples in man unlang closely.
authorize {
...
if (ADSL-Agent-Circuit-Id \
(%{sql: select ...})) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize {
...
if (ADSL-Agent-Circuit-Id \
(%{sql: select ...})) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
I disagree with the logic slightly.
In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not exist.
As fas as I understand, the desireable result is:
If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication must
happen.
If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize {
...
if (ADSL-Agent-Circuit-Id) {
if (%{sql: select ...}) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
}
--
Johan Meiring
Cape PC Services CC
Tel: (021) 883-8271
Fax: (021) 886-7782
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
Johan Meiring wrote:
I disagree with the logic slightly.
In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not
exist.
Yes. It all depends on what you want.
As fas as I understand, the desireable result is:
If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication
must happen.
If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize {
...
if (ADSL-Agent-Circuit-Id) {
if (%{sql: select ...}) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
}
Yes, that will do what you want.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freeradius and ADSL-Agent-Circuit-Id
Greetings, I would like to be able to incorporate processing of ADSL-Agent-Circuit-Id into my freeradius / mysql environment. I have a stock debian / freeradius2 server with a local mysql database, and my bras is correctly getting this attribute to me and I see it under freeradius -X. I would like to implement a policy of 'ignore username/password' and instead authenticate based on the presence of this attribute and the database entry corresponding to it. I do not want to simply overwrite User-Name with the attribute, I really want to only peform this step if the attribute is actualy present otherwise proceed normally for chap/pap. So I guess the question is, how can I conditionally authenticate based on presence of this attribute (and a corresponding db entry saying Auth-type = Accept or Reject)? Previous posters suggesting overwriting User-Name open up a hole where if anyone just makes their username the same as a valid circuit ID, they'd be allowed and really I want to enforce it based on the presence of the acutal attribute itself. Mike- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: freeradius and ADSL-Agent-Circuit-Id
Ad this into the authorize section:
authorize {
if %{ADSL-Agent-Circuit-Id} {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
Password := %{ADSL-Agent-Circuit-Id}
}
}
Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to radcheck and
set the password to the value of ADSL-Agent-Circuit-Id.
++---+++---+
| id | username | attribute | op | value |
++---+++---+
| 226529 | adslagent | Cleartext-Password | := | adslagent |
++---+++---+
1 row in set (0.00 sec)
Tim
-Original Message-
From: freeradius-users-
bounces+tim.sylvester=networkradius@lists.freeradius.org
[mailto:freeradius-users-
bounces+tim.sylvester=networkradius@lists.freeradius.org] On Behalf
Of Mike
Sent: Tuesday, July 20, 2010 12:37 PM
To: FreeRadius users mailing list
Subject: freeradius and ADSL-Agent-Circuit-Id
Greetings,
I would like to be able to incorporate processing of
ADSL-Agent-Circuit-Id into my freeradius / mysql environment. I have a
stock debian / freeradius2 server with a local mysql database, and my
bras is correctly getting this attribute to me and I see it under
freeradius -X. I would like to implement a policy of 'ignore
username/password' and instead authenticate based on the presence of
this attribute and the database entry corresponding to it. I do not
want
to simply overwrite User-Name with the attribute, I really want to only
peform this step if the attribute is actualy present otherwise proceed
normally for chap/pap. So I guess the question is, how can I
conditionally authenticate based on presence of this attribute (and a
corresponding db entry saying Auth-type = Accept or Reject)?
Previous posters suggesting overwriting User-Name open up a hole where
if anyone just makes their username the same as a valid circuit ID,
they'd be allowed and really I want to enforce it based on the presence
of the acutal attribute itself.
Mike-
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius and ADSL-Agent-Circuit-Id
Tim Sylvester wrote:
Ad this into the authorize section:
authorize {
if %{ADSL-Agent-Circuit-Id} {
update request {
User-Name := %{ADSL-Agent-Circuit-Id}
Password := %{ADSL-Agent-Circuit-Id}
}
}
Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to radcheck and
set the password to the value of ADSL-Agent-Circuit-Id.
++---+++---+
| id | username | attribute | op | value |
++---+++---+
| 226529 | adslagent | Cleartext-Password | := | adslagent |
++---+++---+
This opens up a security hole I wish to avoid - if someone knows what my
circuit Id's look like, and that database is used in any context where a
user can send an id/password to authenticate that does NOT have
ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user
id's for the bad guys to use. I am happy having a non-default sql
database schema but I think I really need the sql lookup to be being
based on ADSL-Agent-Circuit-Id and not User-Name.
Mike-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: freeradius and ADSL-Agent-Circuit-Id
This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name. OK. Read the docs on modifying the SQL schema and the SQL queries. Tim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: freeradius and ADSL-Agent-Circuit-Id
This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name. OK. You could try a few other things: Change the radcheck entry to: ++---+---++---+ | id | username | attribute | op | value | ++---+---++---+ | 226529 | adslagent | ADSL-Agent-Circuit-Id | := | adslagent | ++---+---++---+ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
