Acct-Authentic & changing usernames

[Arran Cudbard-Bell]

Phil Mayers wrote:
> We're bringing a Cisco (formerly Airespace) lightweight wireless system 
> online, and I'm seeing some odd things in the accounting.
> 
> Specifically, the usernames can change in the accounting packets. This 
> causes the default SQL queries (at least, the ones for Postgres under 
> 1.1.7) to generate duplicate entries for the session, because the 
> "where" clause includes the username.
> 
> For example, I might see this:
> 
> User-Name = "unknown"
> NAS-Port = 29
> NAS-IP-Address = 172.16.x.x
> Framed-IP-Address = 192.168.x.x
> NAS-Identifier = "wlan-wism-1-1"
> Airespace-Wlan-Id = 2
> Acct-Session-Id = "47b3193c/00:aa:bb:cc:dd:ee/5746"
> Acct-Authentic = Remote
> Tunnel-Type:0 = VLAN
> Tunnel-Medium-Type:0 = IEEE-802
> Tunnel-Private-Group-Id:0 = "3602"
> Acct-Status-Type = Start
> Calling-Station-Id = "00:aa:bb:cc:dd:ee"
> Called-Station-Id = "00:1b:d5:08:01:00"
> 
> ...then a few seconds later
> 
> User-Name = "THEUSER"
> NAS-Port = 29
> NAS-IP-Address = 172.16.x.x
> Framed-IP-Address = 192.168.x.x
> NAS-Identifier = "wlan-wism-1-1"
> Airespace-Wlan-Id = 2
> Acct-Session-Id = "47b3193c/00:aa:bb:cc:dd:ee/5746"
> Acct-Authentic = RADIUS
> Tunnel-Type:0 = VLAN
> Tunnel-Medium-Type:0 = IEEE-802
> Tunnel-Private-Group-Id:0 = "3602"
> Acct-Status-Type = Interim-Update
> Acct-Input-Octets = 105078
> Acct-Output-Octets = 72551
> Acct-Input-Packets = 754
> Acct-Output-Packets = 300
> Acct-Session-Time = 74
> Acct-Delay-Time = 0
> Calling-Station-Id = "00:aa:bb:cc:dd:ee"
> Called-Station-Id = "00:1b:d5:08:01:00"
> 
> If the user is on e.g. a windows XP laptop and logs out, I might finally 
> see:
> 
> User-Name = "host/thelaptop.domain.com"
> NAS-Port = 29
> NAS-IP-Address = 172.16.x.x
> Framed-IP-Address = 192.168.x.x
> NAS-Identifier = "wlan-wism-1-1"
> Airespace-Wlan-Id = 2
> Acct-Session-Id = "47b3193c/00:aa:bb:cc:dd:ee/5746"
> Acct-Authentic = Remote
> Tunnel-Type:0 = VLAN
> Tunnel-Medium-Type:0 = IEEE-802
> Tunnel-Private-Group-Id:0 = "3602"
> Acct-Status-Type = Stop
> Acct-Input-Octets = 1852445
> Acct-Output-Octets = 5401691
> Acct-Input-Packets = 17608
> Acct-Output-Packets = 8630
> Acct-Terminate-Cause = User-Request
> Acct-Session-Time = 30517
> Acct-Delay-Time = 0
> Calling-Station-Id = "00:aa:bb:cc:dd:ee"
> Called-Station-Id = "00:1b:d5:08:01:00"
> 
> It seems the NAS is having a changing view of the authentication 
> username as various events take place, presumably at the EAPOL layer.
> 
> However it seems to consistently set Acct-Authentic to RADIUS for "real" 
> usernames, and "Remote" for unknown or non-authenticated usernames, so 
> it sort of "knows" this is happening.

Have you tried specifying a User-Name in your Access-Accept packets? 
According the original RFC specs, the AP should use that User-Name in 
all subsequent accounting packets.

If your doing that already, try just returning a canned User-Name string 
and see where in turns up in the accounting packets.

If I were to guess,   I'd say the Acct-Start was sent prior to the 
supplicant responding to the EAP Identity Request, at the point of 
wireless association.

The interim packet was using a returned User-Name, and the stop packet 
was using the outer identity in the EAP Ident Response.

Weird ...
> 
> Now the Cisco WLC (nee Airespace) is a weird bit of kit anyway; it sort 
> of "holds onto" client sessions in case they come back shortly (not 
> unusual for wireless) but I'm wondering if this behaviour is legal, sane 
> or what?
> 
> I can probably fix our SQL queries, but I thought people might be 
> interested; for interest, what was the original rationale behind the 
> where clause in the default SQL queries:
> 
>  where username='%{SQL-User-Name}'
> 
> ??
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html