Hi Colin,
We expect that the called-station-id is populated as per RFC 3580 by any of our APs - new or old, so that we can correctly associate the designated network policy with it's associated requests by SSID.
This is important as if we cannot achieve this match then we cannot align the correct authentication choice to the specific wireless network.
For example, we have SSID1 that uses EAP-TLS for trusted domain-joined clients. This wireless network has full network access.
We have a second network identified by SSID2 with access only to the Internet which is not using RADIUS but we'd like it to. What's stopping us is the inability to use called-station-id in the conditions so we can discern between wireless networks, which in this example would require us to use MS-CHAP or MS-CHAP-v2.
In not being able to discern the difference using called-station-id, every wireless request will simply match the first network policy which in turn will allow the lesser MS-CHAP-based authentication to work, which in turn will allow these untrusted devices access to the full corporate network.
From a literal usage perspective, called-station-id is matched with the following regular expression using SSID1 as the example of this part of the condition:
\:SSID1$
We have five wireless networks in total but there's no value in going through each scenario. The fundamental issue is that without being able to conveniently leverage the RFC definition for called-station-id, we'd have to be willing to take on board the management of the additional RADIUS servers on a per local controller basis, which is a length to which we are not willing to go - particularly as our environment grows, when we know there is a more appropriate route.
Cheers,
Lain