distinction between users on different AP (talking to the same radius server)

[liran tal]

Thank you both, Phil and Hoercher,
what I did is what you suggested, using FreeRADIUS attributes to distinguish
each access point and I used
the CalledStationId in particular, which is the MAC address of each AP -
this is as unique as it gets.

Thanks alot.


On 11/19/06, K. Hoercher <wbhoer at gmail.com> wrote:
>
> On 11/19/06, liran tal <liransgarage at gmail.com> wrote:
> > I'll try to elaborate on this...
> > There are two access points deployed in two different locations, they
> both
> > speak to a central radius sever,
> > it looks like this:
> >
> > AP1 - DHCP Address Pool 172.19.1.0/24
> > AP2 - DHCP Address Pool 172.19.2.0/24
>
> ah ok. (nitpick: so the subnet mask /24 is not different, the subnets are
> *g*)
>
> > Now, say user foo got connected to AP1, in the logs I will see he
> received
> > FramedIPAddress 172.19.1.250
> > so I will know for a fact that the user is conneccting from AP1 rather
> than
> > AP2.
>
> Which log? Again, as the issueing of dhcp leases would happen after
> the associating/authenticating of the user's machine I would not
> expect Framed-IP-Address  to be tranmitted in an Access-Request from
> an ap to be acted on by freeradius. Actually the other way round would
> be more common, freeradius sending that attribute to the ap. Maybe it
> could be part of an accounting message sent by the ap, but that would
> also be to late to base authentication decisions on in any sane way.
>
> If you happen to have such setup nevertheless, could you show the
> freeradius debug output?
>
> > So I'm asking if there's a better way to do this rather than by
> configuring
> > different subnets on the dhcp server of the APs.
> > A NASIPAddress is actually a good solution but I'm not going with that
> cause
> > I can't be sure that it's a static one (some APs
> > receive their "wan" interface address by DHCP which may vary all the
> time).
>
> Not freeradius related: Does every AP use/have its own dhcpd for the
> users? If so, they should ensure that no confliciting leases get out
> by means of relaying to a central server, coordinating between
> themselves, assigning different ranges of ips or just keeping the
> leases on different subnets (the last beeing not the best approach, I
> think, and would also not be needed for freeradius as I tried to
> explain already and will do, hopefully more completely, below).
>
> Ok, so the mentioned combinations would include NAS-IP-Address to be
> not part of them. I was talking in general about possible already
> existing choices you could watch out for.
>
> To do that even more: As to your wish to "distinct", what are your
> needs related to that distinction:
> authentication/authorization/accounting? As long as your aps send
> anything as part of the radius protocol, which is specific to them
> (which is quite probable) and known a priori (which might rule out
> NAS-IP-Address, (but why not dhcping fixed addresses, or at least
> different ranges to them? etc. as completely dynamic ips for aps look
> a bit awkward to me, not only for the problem at hand))  in the
> different messages to freeradius, that entitiy can be used (where/how
> depends on the purpose) to decide between different alternatives.
>
> > So any other ideas...
>
> Not really, I would still uphold my statement previously made. To
> perhaps clarify it a bit: Yes, of course you can configure freeradius
> to act differently on different inputs. Any more specific suggestions
> could only arise from you telling what the aps do (other than putting
> users on different subnets, which is possible too, but not desireable
> I think) ; more to the point: what (which attributes) do they send in
> which situations, and what reaction you want in those situations.
>
> regards
> K. Hoercher
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20061121/a1a2264f/attachment.html>