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 188.8.131.52. 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
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.
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.
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.
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...
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.