-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi folks,
We're running SQL accounting for the FR servers authenticating our 802.1X
users, now. I'm seeing some annoying duplicate entries, and am wondering if
anyone else has had this experience:
mysql> SELECT acctsessionid, username, nasipaddress, acctstarttime,
callingstationid FROM radacct WHERE acctstoptime IS NULL ORDER BY acctstarttime;
+-----------------------------------+------------+-----------------+---------------------+------------------+
| acctsessionid | username | nasipaddress |
acctstarttime | callingstationid |
+-----------------------------------+------------+-----------------+---------------------+------------------+
...
| 4a15bfef/00:23:12:07:e9:c4/74507 | [redacted] | 10.246.207.234 | 2009-05-21
16:56:15 | 192.168.2.17 |
| 4a15bfef/00:23:12:07:e9:c4/74505 | [redacted] | 10.246.207.234 | 2009-05-21
16:56:15 | w.x.38.213 |
| 4a15bfef/00:23:12:07:e9:c4/74514 | [redacted] | 10.246.207.234 | 2009-05-21
16:56:15 | 10.250.61.133 |
| 4a15bfef/00:23:12:07:e9:c4/74516 | [redacted] | 10.246.207.234 | 2009-05-21
16:56:15 | 192.168.1.25 |
| 4a15bfef/00:23:12:07:e9:c4/74513 | [redacted] | 10.246.207.234 | 2009-05-21
16:56:15 | w.x.38.213 |
...
I would think this to be pretty normal-looking, except:
1) in this particular group, all the usernames and MAC components of the
acctsessionid are the same (i.e., this is one node causing multiple accounting
starts to be sent); and
2) our 802.1X wireless clients would not have IP addresses in RFC1918 space.
Ever. Most of the time, a group like this will include an address in our real
wireless address range (that's what I've replaced with "w.x.38.213"), but
sometimes not.
If the callingstationid weren't different for each entry, I'd think "retries"
or "EAP-FAST". (I think I see EAP-FAST activity going on elsewhere; or, at
least, that's what I assume it is.)
As far as I can tell, this occurs pretty infrequently, given the number of
users we have, but it does occur consistently for a given set of users in a
given day, which makes me think it's something about their location on the
network.
Reducing all the accounting detail to a spreadsheet, I see that this is a
flurry of start and stop messages (and one Interim-Update!), and will comb
through that closely tomorrow morning. Seems odd, though, that there would be a
stop logged to the detail, but not to SQL, in this case.
I have little- to no visibility into the networking configuration (our systems
and network groups bristle at each other; a situation I'm trying to remedy),
but I do know this: One department is located across the street from our main
campus. It connects to the Internet by way of a commodity ISP. It is, however,
close enough to pick up one of our APs, and the enterprising IT guy for that
department has set up a Windows box as a wireless client, and bridged that into
their LAN for access to institutional resources. (He has been duly chastised
for this.)
In at least that case, I've seen their LAN IPs (in a reasonably-unusual RFC1918
subnet) as the callingstationid. (Oddly, though, this is sometimes the LAN IP
of their print server, or default gateway -- some artifact of bridging?) This
makes me think that there are more clients out there that can see more than one
subnet at a time, and just report in with whatever IP they feel like.
I suppose my real question is this: Is there anything I can do, from the FR
server end, to winnow out one reliable accounting entry per event? Sure, I can
make my reports (like 'radwho') filter WHERE callingstationid LIKE 'w.x.%', but
that runs the risk of missing entries where the group fails to include one of
our "legit" addresses.
Alternatively, has anyone else faced this and addressed it on the client side?
("Tell the rogue departments to comply with your network policies," is a valid
answer and, frankly, my favorite.)
As ever, pointers to pre-existing threads answering this are welcome; I
couldn't come up with the right combination of search terms to find them
myself...
Cheers,
- -sth
sam hooker|[email protected]|http://www.noiseplant.com
Are you satisfied? ([y]/n):
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)
iEYEARECAAYFAkoVzbIACgkQX8KByLv3aQ3tVQCdEOfZCztHLnmvCvfiuax1Y6Qu
pA0AoLhQLZCIP/0DwXWje1PY41suMq8o
=JDqP
-----END PGP SIGNATURE-----
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
