|More AAA: Simple Authentication, Authorization, and Accounting|
|Monday, 10 July 2006 19:36|
I'm writing this coming off of Networkers and then some vacation time at the beach. A word about Networkers: it was great meeting or seeing again all of those who came up and said hi this year! And thanks for reminding me of names -- faces and names don't seem to stay together in my brain. Or that's my excuse for not being in sales, anyway.
This month's article continues some fairly basic AAA / TACACS+ tips and tricks. There are some things that most people want, things that are fairly easy to get working, but how to do them isn't exactly clear from the Cisco documentation. The problem: you have to piece together the ACS GUI documentation and the Cisco IOS command line (CLI) configuration commands to make this work. They weren't pulled together in any one reference.
Well, now they are documented together: here! So no more excuses -- get out there and start using some of the real potential of CiscoSecure ACS!
Another reason I wanted to write this: every few months, I seem to find myself trying to remember how the CLI AAA configuration and ACS GUI configuration activities fit together for this sort of thing. It never takes long to get it working as desired. The precise details to get exactly what combination of features you want aren't obvious from the documentation, and never quite stick with me between uses. I hope this helps you "remember how to do it" too!
Topics in the previous article:
Specific topics in this article, below:
Prior Articles about AAA or TACACS+
Here is the configuration we worked through in the previous article. It is our starting point for the configuration commands discussed in this article. See the previous article for the ACS setup we did via its Graphical User Interface (GUI).
aaa authentication login default group tacacs+ line enable
tacacs-server host 10.20.1.20 key pleasetrustme
ip tacacs source-interface Loopback0
aaa accounting exec default start-stop group tacacs+
The first thing I'd like to show you is how to use ACS to control which privilege levels users get. You can do this by Group, and over-ride it per-user. Assuming you like to make things really confusing, that is. (I'd just do things by group).
I recommend starting by going into Interface Configuration, TACACS+ (Cisco IOS), to enable the Advanced Configuration Options. (Which, a bit confusingly, is NOT under Advanced Options in the screen capture below). This is shown in the next screen capture.
Now configure the router or Cisco IOS device with the following command:
aaa authentication enable default group tacacs+ enable line
This says to do TACACS+ verification of enable authentication.
It's now time to test it out. The following screen shows what happens when user "test1" (in group 0: Default) tries to become enabled (which by default is level 15). The ACS response won't allow the user to be authenticated at that level. I also tested this by allowing "test1" to go to privilege level 2. The command "enable 2" and enable password then worked to go to privilege level 2. "Enable 3" failed as before.
We have just seen how we can use the privilege level control to deny selected NOC operators, contractors, and other restricted users the ability to configure the router, but still get in and do (some or most) show commands.
For those we allow to become enabled, it is handy to have ACS track the password(s), rather than having the enable password coded into the router. If you go to the other part of the per-user Enable Control, you can specify enable password behavior. The three choices are:
Check the one you want. Be sure to supply the separate password if that option is checked. The right side of the screen below shows what happens if you do not.
The way to check success or failure is via the Successful login or Failed Login reports in ACS, shown in the previous article. There is no obvious way to tell telnet login apart from enable, other than perhaps paying attention to the time you try it at, and looking at the time stamp. If you see two attempts in close temporal proximity, that's probably your telnet login followed by your enable.
As an example of using groups "wisely", I set up a group I called "Enablers". Of course, I put myself ("pjw") into it as a user. And tested it both ways. With the first radio button in the above screen capture selected, the same password that got me telnet access also got me enable access. With the last button selected, the special password I put in worked (and the telnet one did not).
On to Authorization, the second A in AAA. As a quick demonstration of the sort of powerful things you can do with ACS, I decided to allow most show commands but deny "show version". Not that you'd ever do that in the real world, but just as a test.
To start with, you have to tell Cisco IOS to do AAA authorization of EXEC commands. There is a separate IOS command for authorization of configuration commands. So I entered the following at the router CLI:
aaa authorization commands 1 default group tacacs+ if-authenticated none
You would then go to the Group or User setup, to specify the allowed commands. Once again, I think you want to try to do what you need to do with groups, to keep the management burden as light as possible. So Edit Settings for the group, and scroll down to the part about Group Command Authorization. You can also create Shell Command Authorization sets and then select which one is allowed -- but let's do it the basic way here.
The logic of this dialog box confused me at first. You need to check Permit or Deny to tell ACS what you want for unmatched Cisco IOS commands.
You can then check the box and put in the beginning of an EXEC mode command to allow or deny. You put in the first keyword. Then below it, you put "permit" or "deny" followed by a keyword, as many times as needed. You also click on whether to permit or deny keywords (arguments) that you did NOT specify. Click on Submit or Submit + Restart.
See the screen capture below.
That leaves one more AAA stunt: creating an Audit Trail. Enter the following configuration on the Cisco router or Cisco IOS device:
aaa accounting commands 15 default start-stop group tacacs+
You can then go to the Reports part of ACS. Pull up the TACACS+ Administration report. (TACACS+ Accounting tracks changes you made to ACS itself). The results are shown below. Note that you can clearly see who issued each command, when they did it, and what the command was.
Final Cisco IOS Configuration
Here is our final set of configuration commands. There's not much to type really, the trickier part is how it all fits together with the right ACS GUI configuration steps. And looking for reporting in all the right places.
I hope you enjoyed this article. It's feeling like we've done enough AAA and ACS for a while. My list of article ideas is getting longer. It includes things like High Availability, working with wireless controllers, NAC, defensive IP multicast configuration, and many other topics.
Concerning High Availability and quality time at the beach, let me just say that if heavy rain is predicted, the words "backup sump pump" might be good ones to consider.
Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher Pete's email address.