TACACS+: Is that a WLC, or are you just happy to see me?

In an earlier post, we got started with a pretty basic TACACS+ configuration on an Ubuntu server. That config works pretty well for most, if not all, IOS devices.

So, what about Cisco WLAN controllers? They’re definitely not IOS, but they do speak TACACS+ for administrative access, as well as RADIUS.

This one was a little more difficult to get working, but not because of the config on the Ubuntu server. The difficulty was in putting (3) very important configurations together:

  1. You must configure authentication and authorization on the WLC for your login to work. Authentication configured without authorization will appear to log your user in, but will send you quickly back to the login prompt.
  2. You must configure the order for authentication–with TACACS+ at the top of the list. If you don’t, local accounts will be used first.
  3. It doesn’t appear that the service configuration in the TACACS+ user WLC group can exist with the service configuration for an existing group, so nested groups may be required.


#1 should be pretty simple to understand: in your WLC, under Security > TACACS+, configure Authentication, Accounting, and Authorization each with the same servers and keys. I figured this out the easy way–asking Google if he knows of anyone else who got it working. Luckily for me, he knew of someone.

#2 is also pretty easy, but easy to miss. It stumped me for quite awhile, because though I had TACACS+ servers configured properly in my WLC, packet captures on my Ubuntu server showed no packets from the WLC when I tried to login. That’s a pretty good clue that the WLC isn’t even trying to TACACS+ with the server.
Cisco WLC security

A quick shout-out to Linux: thank you for making it easy for me to troubleshoot with tcpdump, on-board by default. I love you!

#3, if you already know the answer, seems like a simple bit of code, but more that one concept is at work. The first that I can see, is from the required code itself: roles, not just permitted commands:

#
# WLC admins: the group 'l3_tacacs_users' is also a member of this group.
# Unfortunately, it has to be nested this way as users can only be
# members of ONE group.
#
group = wlc_admins {
        service = ciscowlc {
        role1 = ALL
        }
}

There are other roles available, but in my case, only the highest level engineer will have access to the WLC, so I saw no need to configure otherwise.

The second concept is nesting groups, because users cannot be a member of more than one group just by listing them, like member = group1, group2. In my case, I wanted WLC administrators to come from the members of the l3_tacacs_users group, so I made that group a member of the wlc_admins group:

group = l3_tacacs_users {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
                priv-lvl = 15
                }
        member = wlc_admins
}

The last concept is one we’ve seen before: order matters. At least in my testing, my configuration would not work if the wlc_admins groups didn’t come before the l3_tacacs_users group. It makes sense: how can you refer to a group that you don’t know about yet?

Once I had all of those things in place, AAA logins to my WLC worked as desired. I just wish more was in the accounting log…

2 Comments

  1. Flavio Miranda August 13, 2015 8:00 pm 

    Hello man!

    Thanks for share! still working, just tested!

    congrats!

  2. Ross Eison August 14, 2015 8:40 am 

    Thanks for the kind words, Flavio.

Leave a Reply