You probably know that the the local EAP profile you can configure on a controller is a backup... it will be used only if no external RADIUS is defined for user authentication on the controller, or if the defined RADIUS cannot be reached. In other words, when you define a Local EAP profile on a controller that also has RADIUS servers, the order is as follows:
1. Try to use the RADIUS server defined in the WLAN
2. Try to use any RADIUS server defined in Security > AAA > RADIUS > Authentication.
3. If all this fails, try to use the local EAP profile.
Let's play with this idea:
With this WLAN configuration, am I going to use the 10.100.1.30 RADIUS server or the local EAP profile?
Did you answer the 10.100.1.30 RADIUS server? Well, almost right... but I first need to check that server:
Oops, Network User is NOT checked for 10.100.1.30. This supposedly means that I cannot use this RADIUS server for wireless client authentication (only for management users authentication)... but I called that server from the WLAN, so this global "Network User unchecked" parameter does not matter (thanks Stoef and Anonymous for this comment): because the RADIUS is called directly from the WLAN, the WLAN is going to try to use it anyway. But because Network User is unchecked globally, any other WLAN trying to use the global RADIUS server list (i.e. not having the RADIUS called directly from the WLAN) is going to skip that one RADIUS.
Things would be different if the RADIUS was disabled:
Okay, so my controller is going to revert to plan 2, try to use any RADIUS server configured for Network User authentication in Security > AAA > RADIUS > Authentication.
Cool, there is one there (172.29.129.156), matching my criteria (Network User is checked, and the RADIUS server is enabled).
So, my controller is going to use it... or is it? If I look into Management > SNMP > Trap Logs:
Ooh, this is not my lucky day, 172.29.129.156 is not responding, so the controller removed it from the active server list (172.29.129.156 still has the "enabled" status in the RADIUS > Authentication page, this "enabled" status just means that you, the admin, intended to use this RADIUS, not that the controller can actually talk to it successfully).
Ok, then the controller is going to use the local EAP profile. I can see that by running the debug aaa local-auth db enable command:
*aaaQueueReader: Dec 02 16:21:49.385: LOCAL_AUTH: EAP: Received an auth request
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Creating new context
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Created new context eap session handle 94000011
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP:18) Sending the Rxd EAP packet (id 1) to EAP subsys
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: Found matching context for id - 18
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP) Sending user credential request username 'cisco' to FILE
*aaaQueueReader: Dec 02 16:21:49.386: User cisco information retrieved
*aaaQueueReader: Dec 02 16:21:49.386: AuthorizationResponse: 0x2c190b9c
A lot of "LOCAL_AUTH" stuff is happening here, I am definitely using the controller local EAP.
Would have this happened anyway, even with a RADIUS server?
Nope, as soon as I re-enable my RADIUS server:
The authentication occurs on the RADIUS server, and I can see the result on my ACS server (if authentication was local to the controller, I would not see any hit on the ACS... you can try at home, the best way to try is to create one user on the controller, and another on the ACS, and see which one works depending on your configuration changes):
So, in summary, do not get caught by the appearences. Your controller will always ("always", that is on code 7.0.x) prefer an external RADIUS server to the internal local EAP profile, whatever your WLAN configuration looks like.
The WLC will revert to the local EAP profile ONLY if no external RADIUS can be used (external RADIUSes are not configured for network user authentication, or no external RADIUS answers). Always verify "the rest" (RADIUS servers configuration and reachability) before trusting the WLAN configuration nicely displayed before your candid eyes... :-D