A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Friday, December 2, 2011

WLAN controller Local EAP profile vs external RADIUS server

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 RADIUS server or the local EAP profile?
Did you answer the RADIUS server? Well, almost right... but I first need to check that server:

Oops, Network User is NOT checked for 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:

In this case (regardless of Network User being checked or not), I may be calling from the WLAN, but the RADIUS is disabled, and cannot be used, and will be ignored.
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 (, 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, is not responding, so the controller removed it from the active server list ( 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


  1. "Oops, Network User is NOT checked for This means that I cannot use this RADIUS server for wireless client authentication"

    This is wrong, I think... and I'm pretty sure about it. If you define the radius-server in the WLAN-config to override the default-servers (like you did in your example), "Network User" checkbox is not necessary. Otherwise my 1500 concurrent-user WLAN would not work, because it is configured that way.

    It makes sense also, because that way the servers are not "default" and cannot be used on every WLAN, but only on the ones I set them to.

    This is based on 7.0 code, but also worked that way back to 5.2. (and probably even sooner, but I started EAP with 5.2)

  2. only unselect "network user" was not force auth use local EAP, must config radius status to disable could force local EAP.

  3. Thanks a lot Stoef and Anonymous, you are perfectly right!
    Calling the RADIUS from the WLAN overrides the unchecked Network User and global level, but of course disabling the RADIUS globally makes that the WLAN cannot use it anymore.
    Post was updated to reflec this point. Thanks again!

  4. Awesome blog! Now In anticipation of a follow-up ….
    unlimited broadband wireless

  5. I am truly inspired by this online journal! Extremely clear clarification of issues is given and it is open to every living soul. I have perused your post, truly you have given this extraordinary informative data about it.
    Windows Server Datacenter