Showing results for 
Search instead for 
Did you mean: 

WLC allows ANYONE to login to management http page, readonly albeit

Michael Berry
Level 1
Level 1

Okay, to start, this is ridiculous.  I have several controllers and use radius to auth management and network users.  Network user auth works beautifully.  Management user auth works beautifully too, well, too beautifully.  It turns out that apparently I can login with a user in radius which does not have the service-type attr set (which any network user will not have set:) and get readonly access to the management http page.  Why is WLC not denying access to the managment pages unless a specific service-type is set???  BTW, it's not prompting me to auth a subsequent time - it just lets me in to roam around the mangement pages which is highly dangerous, for obvious reasons.  Gives me an authorization error if I try to make a change, hence RO access....

My WLC version is  I don't want to upgrade the code on my controllers unless this is a very specific bug (with documented bugid).  My WLCs are very stable

11 Replies 11

Amjad Abdullah
VIP Alumni
VIP Alumni

Hi Mike,

Very beautifully WLCs indeed.

well, I think we shouldn't ask why the WLC allows the user because the WLC takes the orders from the AAA server to allow or denly. You should configure the radius server to deny access with usernames except that you want. I think it is all AAA server configuration. The question should be "Why the radius server allows the user".

So far I understand that you have radius for authentication and TACACS+ for authorization, correct?

Plz describe more about your infrastructure (what radius you use? which version?) also let us know your AAA server configuratoin.. elaborate as much as you can.



Rating useful replies is more useful than saying "Thank you"

Level 4
Level 4

Hi Michael

When a user account is created, it's mapped to a group. The default for all user accounts is default-group. If all your users are in this group, then any acct will access the WLC. Secondly if different user groups exist, then you just need to create a permit or deny based on user group and IP.

I think you assume that he is using ACS 4.x. If yes then that could probably be the case.

If not, however, (if ACS 5.x is used) then there is no default group and this can not be applied.

Rating useful replies is more useful than saying "Thank you"

Michael Berry
Level 1
Level 1

Forgive me for the late response, I posted while on vacation...still on vacation:D

Group level control doesn't work since the users that need to manage the WLC are mixed with the users that are "users" of the WLC, as in, dot1x auth users.  Here is the problem, TACACs is not used for author, radius is used for Authen and Author (well, at least it should be used for author as well but I can't get the controller to not let someone in if they are authen'd first but not properly author'd).

I am using ACS4.2... can't do IP restrictions cuz the same radius is used for authen of management AND dot1x.  Does anyone here see the real dilemma???  WLC apparently doesn't require a specific authorization string in the authentication mechanism to allow access - even something like requiring privilege level of SOME value would help. 

Radius is doing EXACTLY what it should be, it is authenticating the user as requested by the WLC - the WLC should be looking for a little somethin' extra when it is auth'ing MANAGEMENT users vs Network users...get my point?  It seems like an egregious error on Cisco's part not to require that.  They already require Radius Service-Type to be something specific for R/W and Lobby....  What about requiring it for even R/O access - they say they do, but it isn't so....  Unless like I said, its a bug...

From the link Saravanan put I can read:

If users are not authorized for a particular role (such as WLAN), they can still access that menu option in read-only mode (or the associated CLI


commands). If the TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller.

So I think this is pretty normal. what you are authorized to you get full access and can change. what you are not you can still have read-only access but you can not change anything.

It seems the normal behavior of the WLC.



Rating useful replies is more useful than saying "Thank you"

We aren't using TACACS+....This has nothing to do with TACACS, it is a matter of the WLC not looking for something coming back from RADIUS to determine whether someone should have any access at all to the controller.  Additionally, the idea that Saravanan was linking to was that if you weren't authorized for a particular role, you would have R/O access.  This is very different than what I am talking about.  In my case, the user has NOTHING identifying them in the RADIUS attributes as being authorized for anything whatsoever.  It simply is conveying to WLC that the guy new the right username and password, not that the username has some level (such as r/o) of access to the system.  Get what I'm saying?

So, what I'm gathering is that no one knows why the controller is letting anyone who can authenticate to RADIUS, have read-only access to the system?  This sounds like a major bug in WLC access methodology and I can't see a major player using WLC and being okay with having R/O access to the system if they are also a Network user and can authenticate properly. 

WLC should be looking for an additional data string or field coming from RADIUS, such as a different service-type, in order to grant R/O access.  Does anyone disagree with that assessment?  If so, please explain exactly why...

Configure Users and Their Appropriate RADIUS IETF Attributes

In order to authenticate a user via a RADIUS server, for controller  login and management, you must add the user to the RADIUS database with  the IETF RADIUS attribute Service-Type set to the appropriate value according to the user's privileges.

  • In order to set read-write privileges for the user, set the Service-Type Attribute to Administrative.

  • In order to set read-only privileges for the user, set the Service-Type Attribute to NAS-Prompt.

In this first example debug aaa events enable command output, you see that Access-Accept is successfully received  from the RADIUS server but the Service-Type attribute is not passed onto  the WLC. This is because the particular user is not configured with  this attribute on the ACS.

Cisco Secure ACS needs to be configured to return the Service-Type  attribute after user authentication. The Service-Type attribute value  must be set to either Administrative or NAS-Prompt according to the user privileges.


Even with the explanation provided by Saravanan, there will be either admin or RO access. If the radius server sends access-accept then the user will be authorized. The type of service he receives depends on the attributes but either way you can not reject the access to the user.

Same way with TACACS+ authorization, if the provided credentials are correct the user is granted to some level of access (depending on the authorization configuraiton) but the user can not be fully rejected from accessing the resource.

Rating useful replies is more useful than saying "Thank you"

Amjad, that is exactly what I am seeing.  Saravanan's post implies that you don't get R/O access without having the NAS-Prompt service-type coming back - that may be the intent, but it is not occurring as documented.  No service-type=R/O access on the WLC.

What Amjad is suggesting implies that the only way to prevent a user in ACS from gaining access to WLC via RADIUS (or tacacs for that matter) is to place a CLI/DNIS restriction on every single group that is in ACS so that you are restricting based on something that uniquely is sent only for Network users.

What I have come up with as a kludge is to take each of my user groups except for a management group and place a CLI/DNIS restriction on them that requires a semicolon at the very least in the DNIS field... *:* works for the management user connection because WLC does not send a semicolon for management user auth in the DNIS...whereas for network users, the DNIS will contain the WLCIPADDRESS:SSID...  Again, this is a gross workaround because it requires that every ACS group has a CLI/DNIS restriction AND it limits your ability to use a management user as a network user (for a specific WLAN) as well (since you can't both require a certain SSID in the DNIS AND not have a semicolon).

Is this something that anyone here thinks that Cisco will respond to as a bug if I report it to TAC, or do we think they will treat this as a design issue.  It seems like they should treat it as a bug since they specify that you need to use nas-prompt if you want R/O, but you don't really have to if you don't want just don't specify any service-type.

Hi Michael,

I encountered this exact same problem. I found that giving the non WLC management users a service-type of "Authenticate Only" effectively denies them any access to the WLC. Hope that helps.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card