It all depends on:1. Your Wireless AP / Wireless Controller Implementation
2. Your Radius Server's ability to use policies.
Each Radius server returns different information in a RADIUS packet. The
Cisco Controllers return the attributes of:
CalledStationID 00-00-00-00-00-00:SSID(Where
I've got to proofread better.
On Fri, May 22, 2009 at 7:52 AM, Mike King m...@mpking.com wrote:
Each Radius server returns different information in a RADIUS packet.
This should read:
Each Radius CLIENT returns different information in a RADIUS packet.
**
Participation and
It may be stating the obvious, but if you use AD, you can leverage attributes
there to allow/restrict a range of network/WLAN functions...
Lee
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:wireless-...@listserv.educause.edu] On Behalf Of
Thanks Mike and Lee,
If I could somehow leverage the NASID and SSID as a name-couplet, this would
provide the differentiation I need while making provisioning relatively simple
(I don't want to have to resort to MAC addresses). The packet data pretty much
reflects what I see in the RADIUS
We are a Brocade (OEM Meru) wireless shop and use MS IAS for radius. You
can use the nas-ip-address attribute which is the IP of the controller
and the called-station-id which in Meru/IAS land is the Mac of the
controller:SSID (unlike Cisco per the posting below where it is the AP
mac:SSID - I
Meru is not consistent about what RADIUS attributes they send when using
different authentication methods. This burned us when we tried to restrict
users to particular controller and SSID. It worked okay for 1X authentication,
but when using Web authentication the called-station-id attribute
