Wireless Access

I'm hoping that this is an easy one and my eyes are just crossed...

In both lab and production testing, I'm finding that no RADIUS accounting is taking place for MAC auth clients. Associate the client to 802.1X and there's accounting. Back to MAC auth = no accounting. Doing a "show aaa state user <ip>" shows:

...

RadAcct sessionID:n/a

...

Looking at the auth-tracebuf, I can confirm no rad-acct-start/stop messages are seen.

In the aaa-profile, I have an accounting server group defined as well as enabled interim accounting.

What am I missing??

Just a quick one.

You do have "Mac Auth Server Group" set to your Radius server group right? :) If you're doing local mac-auth then now Radius traffic is going on.

Sure do. Here's the aaa profile applied to the virtual-ap:

AAA Profile "wifi-at-osu-kcwx"
------------------------------
Parameter                           Value
---------                           -----
Initial role                        osu-cp-unauthenticated
MAC Authentication Profile          osu-mac-auth
MAC Authentication Default Role     osu-cp-unauthenticated
MAC Authentication Server Group     osu-radius-west-kcwx
802.1X Authentication Profile       N/A
802.1X Authentication Default Role  guest
802.1X Authentication Server Group  N/A
L2 Authentication Fail Through      Disabled
User idle timeout                   N/A
RADIUS Accounting Server Group      osu-accounting-west-kcwx
RADIUS Interim Accounting           Enabled
XML API server                      N/A
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
RFC 3576 server                     #.#.#.#
User derivation rules               N/A
Wired to Wireless Roaming           Enabled
SIP authentication role             N/A
Device Type Classification          Enabled
Enforce DHCP                        Disabled

The names of the MAC auth server group and radius accounting server group are different, but the servers defined within are identical.

Any other ideas?

That should work, so I'm afraid I don't have anything concrete to add.

Some wild thoughts..

* you could try to use the same server group on both places, but - weird if that has anything to do with things.. I've just done small things wrong enough times to get all paranoid when it comes to those things :)

* You're using a psk protected SSID and for some reason the mac-auth aaa doesn't kick in.

* Some server or user-rule overrides the aaa-profile you want the device to trigger.

Tho I'm sure you've checked the role the device lands in and it's all as it should be..

Thanks for the suggestions. Unfortunately, I do not believe those will help.

- The server groups are identical for all intents and purposes. I believe one is the clone of the other, in fact.

- There is no PSK on this network; nevertheless, I do see mac-auth kicking in, as the request comes into ClearPass successfully as MAC auth

- This is just an open network with MAC auth enabled. The aaa-profile applied is based on the one defined in the virtual-ap, which I posted above. As you can see, there are no user derivation rules, and I can tell you we aren't using any server derivation rules

Any other ideas from you or anyone else?

Can someone at least let me know this is incorrect behavior by looking at one of their own MAC auth clients and seeing if there is a radius accounting session ID?

I don't have a MAC-AUTH only SSID, but I do have guest w/ MAC caching.  I can confirm that accounting is working for MAC cache'd authentications.  Session ID is present along with all of the accounting data you'd expect.

Silly question, but do you have interim updates enabled on your CP server?

Administration > Server Manager > Server Configuration > SERVER_NAME > Service Parameters (tab) > Radius Server (drop-down).

Log Accounting Interim-Update Packets = TRUE

Ryan, here's a MAC-AUTH with an active accounting session.

I verified that publisher and 6 subscribers all have interim accounting set to "True".

Tim, with your MAC-auth service that is accurately performing accounting, do you mind putting a device in debug on the controller and sharing the auth-tracebuf of it getting online? I want to see if you actually see the rad-acct-start/stop messages. Also, can you do a "show aaa state user <ip> | include RadAcct" and share that? I'm looking to verify the sessionID is there as well.

Thank you!

Thanks, Tim. I'll dig into this some more.

HI Ryan,

I am having exactly the same issue on two different systems at two locations.

Neither of them is producing any accounting information.

If you as an MVP Expert can't solve it what chance do I have :-)

Cheers

Andrew

To be honest, I haven't gone back to troubleshooting this issue. :-/

FWIW I'm seeing this as well.  Accounting works fine for dot1x but not mac auth.

ArubaOS 6.3.1.8 on 7220 + AP-225s here.

Hi Everyone,

I'm seen exact the same behaviour. There is no accounting when I'm using server-derived roles. Take a look "Radact N/A" and "role-how" below:

Name: 60672073db4c, IP: 172.17.35.161, MAC: 60:67:20:73:db:4c, Role: TestGuest-CP, ACL: 62/0, Age: 00:00:04
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: FreeRadius
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: Matched server rule
VLAN Derivation: MBA Server Rule Role Contained
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=1, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: g-HT-20, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 1
Vlan default: 35, Assigned: 35, Current: 35 vlan-how: 8 DP assigned vlan:0 
Mobility Messages: L2=0, Move=0, Inter=0, Intra=0, Flags=0x0
SlotPort=0x2100, Port=0x10025 (tunnel 37)
Role assigment - L3 assigned role: n/a, VPN role: n/a, Dot1x cached role: n/a
    Current Role name: TestGuest-CP, role-how: 2, L2-role: TestGuest-CP, L3-role: TestGuest-CP
Essid: SOLIDEX-Guest, Bssid: 24:de:c6:cf:22:c1 AP name/group: Engines/SOLIDEX Phy-type: g-HT-20
RadAcct sessionID:n/a
RadAcct Traffic In 72/10723 Out 58/39111 (0:72/0:0:0:10723,0:58/0:0:0:39111)
Timers: L3 reauth 0, mac reauth 0 (Reason: ), dot1x reauth 0 (Reason: )

If I remove role derivation rule accounting starts as appropriate. Note "Radact xxxxx" and "role-how":

(Aruba3200) #show aaa state user 172.17.35.161


Name: 60672073db4c, IP: 172.17.35.161, MAC: 60:67:20:73:db:4c, Role: logon, ACL: 1/0, Age: 00:00:00
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: FreeRadius
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: default for authentication type MAC
VLAN Derivation: Default VLAN
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=1, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: g-HT-20, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 1
Vlan default: 35, Assigned: 35, Current: 35 vlan-how: 1 DP assigned vlan:0 
Mobility Messages: L2=0, Move=0, Inter=0, Intra=0, Flags=0x0
SlotPort=0x2100, Port=0x10016 (tunnel 22)
Role assigment - L3 assigned role: n/a, VPN role: n/a, Dot1x cached role: n/a
    Current Role name: logon, role-how: 1, L2-role: logon, L3-role: logon
Essid: SOLIDEX-Guest, Bssid: 24:de:c6:cf:22:d1 AP name/group: Studiks/SOLIDEX Phy-type: g-HT-20
RadAcct sessionID:6067207360672073DB4C-02
RadAcct Traffic In 60/7056 Out 47/11287 (0:60/0:0:0:7056,0:47/0:0:0:11287)
Timers: L3 reauth 0, mac reauth 0 (Reason: ), dot1x reauth 0 (Reason: )
Profiles AAA:Test-Guest-AAA, dot1x:, mac:default CP: def-role:'logon' sip-role:'' via-auth-profile:''
ncfg flags udr 0, mac 1, dot1x 0, RADIUS interim accounting 1
IP Born: 1418317896 (Thu Dec 11 20:11:36 2014)
Core User Born: 1418317888 (Thu Dec 11 20:11:28 2014)
Upstream AP ID: 0, Downstream AP ID: 0
Device Type: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
L3-Auth Session Timeout from Radius: 0
Mac-Auth Session Timeout Value from Radius: 0
Dot1x Session Timeout Value from Radius: 0
CoA Session Timeout Value from Radius: 0
Dot1x Session Term-Action Value from Radius: Default
Reauth-interval from role: 0
Number of reauthentication attempts: mac reauth 0, dot1x reauth 0
Address is from DHCP: yes

 Is it expected or this is bug? We are using SW 6.3.1.2.

Thanks!

/ Ruske

Hello again,

I would like to share my experience for those who has the same question.

We have updated to ArubaOS 6.3.1.14 and it seems that now behaviour is correct: as soon as user is authenticated RADIUS accounting is working. Mind the fact that if "check-for-accounting" is enabled (and it is enabled by default) there will be NO accounting if a user has user-role with captive-portal.

Here is "check-for-accounting" reference from Release Notes:

user-role <name>
  captive-portal {<STRING>|check-for-accounting}

The check-for-accounting parameter is introduced in ArubaOS 6.3.1.7. If disabled, RADIUS accounting is done for an authenticated users irrespective of the captive-portal profile in the role of an authenticated user. If enabled, accounting is not done as long as the user's role has a captive portal profile on it. Accounting will start when Auth/XML-Add/CoA changes the role of an authenticated user to a role which doesn't have captive portal profile. This parameter is enabled by default.

We have tested following scenario:

1) A user is authenticated using MAC address and gets a default user-role with captive portal - RADIUS accounting doesn't start here.

2)  User authenticates using captive portal and captive portal (using inbuilt CoA-agent) issues CoA to change user-role to authenticated (role has no link to captive portal) - RADIUS accounting starts here.

/ Ruske

Thanks, Ruske! I just put in a change of "no captive-portal check-for-accounting" on all our applicable roles, and I've confirmed we're now getting accounting data.

Thanks for following up on this thread and closing the loop. :-)