Re: [WIRELESS-LAN] more fun with RADIUS

[Jeff Wolfe]

Julian Y. Koh wrote:


We're only seeing these unknown records from a little over 10% of our APs,
and some of them are generating thousands of the records, so longer-term, of
course, we need to exercise some better RF management so that users don't
roam as often.But that's another exercise for another day.  For now, I
just need to see if my reasoning is sound.



Hey Julian,

We don't run the WLSM, but we do run IOS APs and use WDS, which operates 
in the same manner as you describe. (Auth requests are aggregated by the 
WDS master AP, while accounting is sent by individual APs.)


We also use EAP-TTLS instead of LEAP.

I had a couple tickets open with the TAC a couple summers ago about 
this. The end result was that if our RADIUS server sent the User-Name 
attribute back in the Access-Accept packet, the APs wold use it to log 
the proper username when they sent accounting packets.


In addition, because we have other .1x platforms that aren't reliable at 
reporting the username in accounting packets, I wrote a hook for our 
Radius server that logs sufficient accounting information from the 
access-request/access-accept packets. With the time and calling/called 
station ids it's not clean, but it does work.


Oh, We use OSC's RADIATOR as our radius server.

-JEff

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

more fun with RADIUS

[Julian Y. Koh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So those of you who have been following our RADIUS saga will be happy to know
that with the latest 5.41 build of Steel Belted RADIUS from Funk/Juniper, all
of our outstanding issues have gone away.  Well, mostly, but the remaining
one does not appear to be an SBR problem.  Hopefully someone can tell us if
we're on the right track.

We have 650+ Cisco IOS APs that all tunnel back to a WLSM.  Now, due to a
deficiency in the IOS and/or WLSM code, all 802.1X/WPA2 authentication
requests are tunneled up from the APs through the WLSM to the RADIUS server,
so as far as SBR is concerned, all authentication requests come from the
WLSM, but the APs don't send accounting records up through the WLSM, so they
send accounting records directly to SBR themselves.

The last issue that we were trying to resolve with SBR was that accounting
records only logged the outer identity for EAP-PEAP (and probably EAP-TTLS as
well, but we're running PEAP), not the inner identity.  SBR 5.41 includes a
FullName attribute in accounting records, though, that has the inner
identity.

The problem manifests itself in that we are getting a ton of accounting
records that have Unknown in the FullName field.  I haven't done a
conclusive correlation, but those records appear to be generated when a
client roams from one AP to another.  I am not exhaustively familiar with the
802.11 spec, but based on my knowledge of how things work, it seems to me
that under the WLSM arrangement that we have, the inner identity will only be
known on first authentication.  When I roam to another AP, I don't have to go
through a full reauthentication because again as far as SBR is concerned, my
authentication came from the WLSM, not the AP.  So the AP that I roam to is
only going to send an accounting packet that SBR isn't going to know to
associate with my inner identity, and thus Unknown gets logged in the
accounting packet for the inner identity.  The outer identity gets properly
logged because the AP can see that just fine.

Does it sound like I'm on the right track here?

What we're planning on doing is starting to log both the FullName (inner) and
User-Name (outer) attributes.  At least in this case we have a chance of
tracing a MAC address back to an accounting record that has an actual valid
username associated with it.

We're only seeing these unknown records from a little over 10% of our APs,
and some of them are generating thousands of the records, so longer-term, of
course, we need to exercise some better RF management so that users don't
roam as often.But that's another exercise for another day.  For now, I
just need to see if my reasoning is sound.

Thanks!!!


-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.0.6 (Build 6060)
Comment: http://bt.ittns.northwestern.edu/julian/pgppubkey.html

iQA/AwUBRQ9Mdg5UB5zJHgFjEQKybgCg6wFLCHWjmsco1RnHjJ0BMLPZqtAAn0fe
JMB1v61lQ4KbfLP135Mp9TlG
=EjiY
-END PGP SIGNATURE-

-- 
Julian Y. Koh mailto:[EMAIL PROTECTED]
Network Engineer   phone:847-467-5780
Telecommunications and Network Services Northwestern University
PGP Public Key:http://bt.ittns.northwestern.edu/julian/pgppubkey.html

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.