I have a tac case open, they're just being slow to respond, so I'm digging into other resources.
The gist of the issue is: I've noticed a lose correlation between older 1142 APs and clients not being able to authenticate to an SSID using 802.1x/RADIUS (talking back to ISE) where a flex connect ACL is being assigned.
When we upgraded this controller from 7.6.x code to 8.0 it broke the ISE auth'd SSIDs because of the flex connect specific ACL feature added in 8.0. Once I figured that out, I recreated the global ACLs as flex connect ACLs and most of the clients started connecting again (we were seeing error logs saying ACL not found, etc...)
The behavior of the SSID was as follows:
Windows client connects to the SSID pushed down via a GPO, we'll say it's called OMG_Private.
OMG_Private uses 802.1x and RADIUS to talk to an ISE server (v 1.4) and ISE essentially looks at the various AD Machine account info. If it sees just a Machine account, the client gets ACL_A assigned to it. That ACL allows access to the internal AD resources (AD, DNS, etc...). Once the user on that machine logs into Windows, RADIUS now sees both a Machine and User AD account, and tells the client to have a new ACL, ACL_B. That ACL allows internet access in addition to internal resources.
This behavior works fine in the buildings with AIR-AP3802i (Reg domain A) APs. In buildings with 1142i APs, clients just never seem to connect (don't see them hit ISE or in the WLC logs), or they might initially auth and get ACL_A, but once they login they lose connectivity and don't even show as associated with the AP, then on reboot they show up when they try to connect.
This feels like an issue with older Cisco APs. Has anyone else ran through this? Everything worked fine on 7.6 code (but they need to get to 8.x code because they support for Reg. Domain B APs)
Am I barking up the wrong tree?
