May 25, 2016 Leave a comment
I’ve been meaning to post this one for a while but got there in the end! Recently we changed our content filtering provider and one of the aims of the new system was to ensure tighter integration between the Wi-Fi controller and filter for authentication \ identification of users.
We particuarly needed the framed-ip-address attribute as that’s used to tie a device to a user on our particular filtering product. In theory the setup sounds fairly straightforward:
- set up Windows Network Policy Server to handle RADIUS authentication
- set up RADIUS authentication profile against a new Wi-Fi SSID
- set up RADIUS accounting on the wireless controller
- set up RADIUS accounting on the filtering server
Initially all went well and we were able to authenticate users smoothly onto the Wi-Fi network via the existing captive portal… but (and isn’t there always a but!) we saw nothing on the filtering server, just an empty void of white space where user account activity should’ve been 😦
Initial troubleshooting steps
So I checked the simple things first…
- Check RADIUS Interim Accounting option is enabled on the AAA profile
- Check if shared secret is too complex \ typo when entering it into various config pages
- Ensure accounting server options in Windows NPS are configured correctly
- Confirm configuration of accounting server details on Wi-Fi controller
- Ensure ports for accounting information are set as they should be
Everything checked out correctly and authentication still worked fine despite me trying to break it, which made accounting failing even more strange. With that in mind it was time to move onto some more in-depth troubleshooting.
Next step was to try and see if any accounting traffic was actually being sent so trusty Wireshark was spooled up to watch traffic for anything on port 1813. We saw plenty on 1812 for authentication but consistently nothing on 1813. At one stage I was beginning to wonder if the NPS server had something to do with it but replies to my posts to TechNet forums suggested otherwise.
A case was then opened with Aruba support which involved upgrading the controller to latest firmware 188.8.131.52 before further troubleshooting could be performed. A few useful commands came out of this process, which should be ran before upgrading to ensure the controller has enough resources to run the upgrade:
show memory show storage
As an aside the upgrade did give us a nice new(er) feature called AppRF that basically brings application-level monitoring to the Aruba UI. It saves going through the firewall to find the same information and allows us to see at-a-glance where the bandwidth is going on the wireless network and to which user(s):
The update also made packet captures on the controller a bit simpler, which further proved our theory that no accounting traffic was being sent as the controller itself didn’t log anything on 1813 in its direct captures. However despite the upgrade we were still no closer to resolving the accounting issue.
After escalating through various levels of Aruba support and product management one of the technical team finally found our issue, which turned out to be a deceptively simple fix. It’s a sneaky little setting squirrelled away named Captive Portal Check for Accounting
The setting in question lives within the Misc. Configuration section of Security > User Roles.
You need to edit the settings of the role that is assigned as the 802.1X User Default Role for the the AAA Profile associated with your RADIUS-enabled VAP (what a sentence that is!)
Basically untick that box and everything starts working…
By default the Captive Portal Check for Accounting box is ticked and therefore accounting won’t work if the user has authenticated via a captive portal. The Aruba documentation has this to say about it:
The check-for-accounting parameter is introduced in ArubaOS 184.108.40.206. 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.
As soon as the box was cleared accounting information came flooding in and I was pleasantly surprised to see how quick the interim updates were also processed, as some vendors’ interpretations of the RADIUS accounting standards aren’t quite so amiable from what I read during my research.
Was certainly a voyage of discovery to get to the solution but we have gained a few new features along the way and I’ve also become well acquainted with the ArubaOS CLI for troubleshooting purposes, so the process has added some valuable knowledge too 🙂