freeradius and ADSL-Agent-Circuit-Id

[Tim Sylvester]

> 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