Try our training for free.

Gain instant access to our entire IT training library for 1 week. Train anytime on your desktop, tablet, or mobile devices.

This Cisco video training with Keith Barker covers network security, including topics such as securing routers, firewalls, cryptography, and more....
This Cisco video training with Keith Barker covers network security, including topics such as securing routers, firewalls, cryptography, and more.

Related area of expertise:
  • Cisco security

This CCNA security training course, produced by Cisco expert Keith Barker, helps prepare you for the new 640-554 Cisco exam, and also prepares you to address many of the real world vulnerabilities you come across today.
Keith dives into the Cisco Configuration Professional (CCP), the latest GUI (Graphical User Interface) software which will help you manage your Cisco routers. Not only does this training focus on switch security and router security, it also explains and demonstrates how to configure the ASA (Adaptive Security Appliance) firewall. Keith, author of the CCNA Security Cert guide, covers the material in a way that is thorough, fun and engaging.

Whether you're fairly new to the network security world, or you've been in it for a while and simply want to fill in the gaps and see how all the pieces can be integrated together to build a fortress of security using a defense in depth approach, this course is for you.
1. Introduction to CCNA Security (7 min)
2. Network Foundation Protection (38 min)
3. Fortifying the Local Router (42 min)
4. AAA, RADIUS and TACACS+ (47 min)
5. Securing the Switched Data-plane (50 min)
6. Tools to Protect the Management-plane (43 min)
7. Controlling the IPv4 Data-plane with ACLs (34 min)
8. Protecting IPv6 Networks (53 min)
9. IOS Firewall Fundamentals (31 min)
10. Zone Based Firewall Implementation (25 min)
11. ASA Firewall (47 min)
12. Intrusion Prevention Systems (IPS) (45 min)
13. IOS-based IPS (48 min)
14. Cryptography Essentials (42 min)
15. IPsec Site to Site VPNs (53 min)
16. SSL VPNs (51 min)
17. Defense in Depth (24 min)

Introduction to CCNA Security

Network Foundation Protection

Fortifying the Local Router



Using AAA, RADIUS, TACACS, our objective this Nugget is really simple. We want to take the knowledge we gain from the previous Nugget about the basics of how AAA works and transfer it to a central AAA server using one of two languages of love. Either RADIUS or TACACS+.


Let's jump in. So here's the situation. At our company, we have R1. But we've just discovered that it's not the only router or switch that we have to manage. There's actually a couple hundred of them. So previously in a Nugget we used the local database. The running config on a single router because it was a small environment.


We created a user name on the router in the running config. And then we told AAA that we wanted the default login method. Anybody trying to login into the router for administration of that router to go ahead and use a default method of the local database.


And poof. All of a sudden, anybody that tries to login via the VTY lines, the console, the auxiliary port, or any other method they might use to get a command line interface on that router, they would have to use the local database, which means the router would prompt them for a user.


And prompt them for a password. It's wonderful. Now, here's the problem with 200 devices. With 200 devices, we don't want to create the user admin, or Bob, or whatever user names we're going to create, we don't want to create that on 200 different devices. Holy shnikers.


Unless we're being paid by the hour. And then it's great. However, because our lives are already busy enough, we need some way to allow Bob to log into these routers, assuming he's a manager or an administrator. But we don't want to have to create the date user in the actual local database.


So here is the game plan. What we're going to do is we're going to play a game called centralized database. Ooh, it's a great game. Check it out. You'll love it. A centralized database is where you have all the information in one place. When I talk about users, that could mean end users sending traffic through the system.


And it also could refer to administrators. That's always been a pet peeve of mine. It's like, they talk about users and I'm thinking I'm never going to let a user manage my box. So a user could represent an administrator. So I'll be more clear. So let's say we have Bob, who is an administrator, and we have Lois.


And we have Jennifer. And we have some other people. They're all administrators. So what we could do is we could use centralized database, and keep all of their user names and their passwords on a centralized server. This guy's a mail server. So we'll just say, for a moment, he's just going to be centralize server.


So we keep Bob's user name, Lois's username, and Jennifer's user name all there along with their passwords. And here's the play by play. Now, we tell the router dear Mr.Router, you have just lost some responsibility. What we want you to do now is that if somebody tries to connect and login, whether it's on the VTY lines, the console port, or the auxiliary port, instead of using the default method of saying use the local database, we want you to instead use a AAA server.


So this centralized database is an example of a AAA server that has Bob, and Lois, and Jennifer, all the administrators names, in that database and their passwords. So Bob, Lois, or Jennifer tries to login. The router says hold on a nanosecond. It sends that request up to the AAA server and says, hey, AAA server.


I got somebody who wants to login. I'm so excited. They're name is Bob. The password is Cisco. Is it right? Is it good? Is it accurate? And the AAA server is going to send a message back saying pass or fail. That's if it's reachable. Now if the AAA server's not reachable, the router has got to make another decision.


But as ling as the server's reachable, they'll get a pass or fail message. If it's a pass, the router says, Bob, come on in and gives him the exec shell. Now, that's assuming that we're not also doing authorization. So for just the authentication piece, that's how we would do the authentication.


Have a centralized server. And now, check this out. Now if we have 200 other routers out here, we can all have them talking with that AAA server, as well, so that we only have to manage Bob's user name and password in one place on the centralized AAA server.


That's how it works. Now, for fault tolerance, what are we going to do in the real world? For fault tolerance, we're going to have a couple of these servers. And they're going to be replicating so that if any single server fails we're not going to be locked out of our entire network.


But that's the concept of extending our AAA beyond the single router. So let's you and I chat about how this is going to happen. It's, actually, really easy to set up. And it makes a lot of sense. And let me walk you through the piece of doing it. If we want two devices to communicate with each other, here is the laundry list of stuff we would have to do.


Number one, we need to create some user accounts on this AAA server. And I'm calling it a AAA server, and we should pause there for a moment. Now, AAA from a previous Nugget, or this one too, is authentication, authorization, and accounting. So when we create users on this server we could also create their passwords, of course.


But we could also specify what they're authorized to do. So we could specify that they're authorized to get an exec shell. They're authorized to be at privilege level 15. They're authorized to go ahead and issue the command configure space terminal. We can control all of that up here.


And what the router could do is it can, simply, ask every time a customer makes a move-- a user like Bob-- the router could say, oh, he's logged in. And now he wants to type in config T. Is that allowed? And the AAA server says yes or no based on the policy that's all on this centralized AAA server.


Now, this AAA server could have lots of different names. And then explain why that is. The communication. Right here. This communication between this client because this router is acting as a client to this AAA server. Are you with me? So we might think the user is Bob out here trying to log in.


But from a AAA perspective, the client is the router who's making requests to the AAA server. AAA server is responding back to the client, the router, saying yes or no. We're getting passwords and so forth. This language of love, right here, can be done with a couple different protocols.


The language of love. The protocols. The rules in place could be done with a couple different sets of rules. One is called RADIUS. And the other is called TACACS. So whenever you see those terms, I want you to think we're talking about the dialogue and the conversation right here between the AAA server and its' client, which, in this case, is R1. Which one's the best to use? Let's talk about that for a moment.


As far as which one we should implement-- the actual acronyms too, which is what both of these are, we should also possibly talk about that for just a moment. Radius stands for the Remote Authentication Dial in Users Service. Effectively, what is it? It's a protocol to talk between a AAA server and a client.


In this case, a router. The TACACS, what that stands for is the Terminal Access Controller Access Control System. No wonder they just call it TACACS. Now, there's been several flavors of TACACS. There was a X flavor, and there was the normal TACACS. There's TACACS+.


Today, the only current standard is TACACS+, as far as that protocol goes. So we don't, usually, say the plus at the end. We just call it by its acronym. TACACS. So say it like this T-A-C-K-AXE. So that's how it's pronounced. TACACS. And then RADIUS, you pronounce it RADIUS.


I don't have a short was of spelling that. But we call them by the acronyms because it's too painful to spell out the whole process. So which language of love are we going to use between the two devices? Now, before we jump in and say, let's use RADIUS or let's use TACACS.


Let's take a look at the pros and cons and how they operate. I put here for you what I think are the most critical things that you deserve to know about the differences between these two protocols, which can both be used between the AAA server and the router itself.


And let's take a look at RADIUS first. RADIUS is an open standard. I'm going to start with that one. It's open standard meaning that any vendor can use it. Meaning it's open, it's public, and there's lots of vendors who support it. So if we have a non Cisco network and they're using centralized authentication services for remote access users, and users going through the network, and authenticating administrators, it's very likely to be using RADIUS between the network devices and the AAA server.


In that case, it would be RADIUS server. In fact, let's go ahead and write out the names for this server right here. This is fun because this device right here, this server, could be called the AAA server. No problem. It could be called a RADIUS server. Now, why would we call it RADIUS server? It could be called a RADIUS server because the way they have it set up, the customer, is they have their routers communicating with the authentication server using RADIUS.


So they may call it a RADIUS server. They also could call it and authentication server. That's another option. That's quite valid. And that's perfectly OK. So RADIUS uses a open standard. Anybody can use it. Anybody can write to it, program it, et cetera. It encrypts only the passwords, which is a little bit of a bummer.


So let's say that Bob is here, and Bob wants to authenticate. The actual conversation between R1 and the AAA server is going to be in plain text, except for the passwords involved. So Bob's password is protected. The passwords that allow these guys to communicate is protected.


But everything else is in clear text. So it's a little less secure. However, not a huge deal because the passwords are encrypted. And then, finally, RADIUS uses UDP as it's layer for a transport protocol. Now, why is that important? It's important because if you have firewalls or other filtering devices in place, you need to make sure you allow the correct layer four transport protocol and the correct ports.


So originality, a long, long time ago in a galaxy far away, we used those ports. 1645 for the authentication function. And 1646 if R1 was going to send accounting records up to that server. Now, the current standard is 1812 for authentication of import and 1813 for accounting. Which one is yours going to use? It depends on how it was implemented.


So I would just be aware that those are both possibilities for UDP ports used by RADIUS. Now, on the other side of the house, in this column, we have TACACS. And TACACS, first of all, is proprietary to Cisco. They wrote it. And there are some open TACACS services out there.


I've seen them. You can download them, and they're open source and free. But they're using a TACACS proprietary protocol to do it. Most of the time, if people are using TACACS, they've got a AAA server called an ACS server. Wow. Another acronym for it. Now, what does ACS stand for? That's the Cisco secure ACS.


Their Access Control Server. It's a product that Cisco sells. And it comes in several flavors. So this box, this ACS server from Cisco, it could be a physical box. And a long time ago, they used to sell it where you could install it on top of Windows. So you have a Windows server.


You install the ACS software on top of it. They now sell it as an appliance. So you can install it in a virtualized environment, which is what I'm going to be demonstrating today. So you can have, for example, ESXI, VMware, and run it as an appliance virtually, which is fantastic.


And what are the other options? There's also an engine, which is an appliance that you plug-in. It's like a headless horseman. And there's also another guy coming out, and that's ISE. And that's making a lot of headway. ISE stands for the Identity Services Engine.


And it has a lot of similar functionalities to ACS. It does communicate with RADIUS. And the purpose is for authentication. And it could do profiling of the client and it supports 802.1X and a whole bunch of other really cool features. ISE, if you see that, that's how it's pronounced.


I know it says ISE for Identity Services Engine. But if you ever hear about ISE, it's, simply, another product that fits in that area of a centralized server for controlling access into the network. TACACS. If it's a Cisco implementation we might go ahead.


If you're using ACS, we might use TACACS. And TACACS, one of the benefits is it does encrypt the full payload. It doesn't encrypt the headers because packets need to be forwarded on a network. But the actual payload, the conversation of what's really happening between the AAA server and the router, is all being encrypted, which is cool.


And it uses TCP port 49 at layer four. So that's what I would recommend. Maybe even take a moment, right now, and I would have you write out this table just so you know the differences and can see them. A while you're writing that out-- getting a piece of paper or notepad.


And don't just screen shoot it. You can do a screen shot, but that won't help you remember it. I want you to, actually, write it down. You'll be gratefully you did. A couple of observations I also wanted to point out with you is that RADIUS, kind of, groups its' shots.


What o you mean groups its' shots? It's less granular for authorization control. With RADIUS, let's say this is a AAA server and the language of love that we've chosen to use between our AAA client, right here, R1. And the AAA server is RADIUS. So we'll circle that column for a moment.


If we want to do authorization, it's, kind of, bundled into the authentication process. So Bob is here. Bob says I want to authenticate and get access to the network. The authentication request and authorization request, if there is one, are bundled together in the same session, if you will, up to the AAA server.


If the AAA service says, yes, he can login. He's authorized. Access is granted and it's done. As far as continued authorization, it doesn't have a really granular control ability to check. It does have granular accounting. It's amazing at accounting. So how does that compare with TACACS.


Let's clear the screen. And let's give you a example of the same user, Bob, logging in. This time, we'll go ahead and we'll use TACACS as the language of love between our AAA server and the actual client, R1. With TACACS, of course, the entire session is encrypted.


It's using TCP. And it has separate control for authorization. It would go like this. Bob wants to login. He wants to authenticate. The routers been trained to use a AAA server for authentication. So it says, can he authenticate? Does he have the right user name and password? And the AAA server, hopefully, says yes.


So that's the first A of AAA. This is optional but if the router has been configured to check for authorization of commands. What do you mean, Keith, commands? Every time Bob, as an administrator, if he's going into configuration mode, every command he types, if you want the router to check with the AAA server before allowing that to happen you can do that.


And that's where the granular control comes in. So at TACACS we could tell the router. We could do a default authorization method list for all commands at level 15. And any level 15 command, like router, would say, oh, before I let him execute this command, I better check with the AAA server.


And the reply comes back yes or no. So it's this part right here, this blue area, which is the separated authorization, which gives very, very granular control that RADIUS doesn't have built into it. So RADIUS lumps the authentication authorization together.


And TACACS can let them be very, very granular and separate. If we want to do accounting-- let me get a different color there. If you want to do accounting in a different color, we can send accounting records up saying Bob did this. Bob did that. So accounting, they can both do a fine job.


The opinion of the world is that RADIUS, somehow, does a better job with accounting. More detailed so that's fine. We can believe that. And we can also answer that way, if we're asked, in a small room. But for the purpose of actual granular authorization, command by command by command is TACACS.


So what does this all boil down to. Let's take a look at what it boils down. It boils down to the fact that we can use TACACS or RADIUS between the router and the AAA server. In most implementations, it's going to go something like this. For end users, let's say you have an end user on the internet.


So here is Sally. She's at her home in some state, some city, and some location in the world. And she wants to build a VPN tunnel into corporate headquarters. So maybe her firewall is also the VPN head end device for that VPN tunnel. And we'll have a whole Nugget on that coming up.


So that's part of this course. So Sally wants to build a VPN tunnel coming in. And we want to validate, we want to authenticate, Sally. So it's very likely that we might use RADIUS. Make the firewall a RADIUS client, and have him use RADIUS to authenticate Sally.


And that's the normal fair, by the way. RADIUS is, typically, used to authenticate end users before allowing them access in the network. However, let's take another user. And let's take us. So you and I, we're sitting at this PC, right here. And we want to SSH.


We're not like Sally. We don't want network access through the network. We want a command line interface. It's very likely for authenticating SSH. If we have an ACS server, we are, very likely, using TACACS for that purpose. Why? Why TACACS here and RADIUS there? Well, TACACS has that more granular control.


So if you want to lock down your network and make sure that every command that's issued by us, as the administrators, is checked with a AAA server, command by command, before those commands are allowed to be executed on the router, the TACACS has that granular control.


So typically, you'll see TACACS for authenticating and authorizing administrators. And RADIUS used for authenticating and allowing access to end users who are going through the network, like Sally, authenticating the VPN. Now, can you use both? The answer is absolutely yes.


So this router could be a-- I'll put green here-- TACACS client. I said that backwards. So it could be a RADIUS client or a TACACS client at the same time. It could, actually, have two sessions. And it can be trained with a method list saying, I want to authenticate network access for end users using RADIUS.


And I want to authenticate login access using TACACS. And that's perfectly agreeable to the system. And you'll see that all the time, as well, in practical applications. All right, so that's what we've done as far as taking a look at extending our authentication beyond a single local database on a local router.


We've also taken a look at the comparison between TACACS and RADIUS. I don't know why I say TACACS first. Just a Freudian slip there. But RADIUS is open standard. TACACS is proprietary. What is left for us to do? Well, be only thing left for us to do is to implement this.


So here's what we're going to do together. You and I are going to take this router, R1, and we're going to have it work in combination with a AAA server. So what I've done is I've neutered R1. That means I took all the security off of him. Why? Here's what I want to do.


I want to show you the commands, step by step, that I'm going to do on this router as if you're doing it from scratch yourself. And that way, you can take a Greenfield environment,-- basic IP addresses; routing working-- implement these commands, and get the same results.


I also want to point out there's a lot of open RADIUS servers. And there's also some open TACACS servers. So if you want to get those and install them on a Linux box, or a Unix box, or whatever platform they're on, you don't have to have an official ACS server from Cisco.


You can still use RADIUS or TACACS on an open source box and still practice the commands with your local router. Abraham Lincoln said-- I believe it was Abraham Lincoln-- that if we had eight hours to cut down a tree, we should spend, at least, six hours sharpening the axe to be more effective at it.


Well, the same thing is true with network and planning. If we're going to set up AAA services, we want to do a couple of things, planning wise, first before we start clicking on icons and putting commands in the router. So the first thing we're going to do as a safety net is we're going to create a local user on R1. And we're going to give that local user privilege level 15 access. Well, Keith, I thought we were moving away from the whole local database.


We're doing centralized now. Well, as a fail safe, we want to make sure that we have, at least, one account locally so that if a AAA server is not reachable, or something bad happens on the network, we can still login. Like, at the console, it might be really important to do so.


So we're going to create a local user. And we're going to enable AAA, if it hasn't been already. We're going to specify our method lists. And for this example, let's just do authentication. I'm going to ask you a question. Do you remember the name of the method list that, if we put it in place, it applies to all the login.


So what is the login method list called that, once it's applied, applies to all the points where we could login? VTY lines. Console. Auxiliary. Do you remember the name, the special name, of the method list? It is default. So if we have an authentication method list named default, basically, all the VTY lines, all the console ports, all the auxiliary ports, and anywhere somebody could do a login, they would follow the rules of that method list.


So on our default method list we're going to specify two methods. We're going to specify a TACACS server or a group of TACACS servers. And then that will be our first option. And then we'll specify the local database. So here's what will happen. If Bob tries to authenticate to the router, the routers going to go, oh, I need to check with a TACACS server.


Oh, there's not one configured. Or if there is one configured, he's not responding. And then it will fall back to the local database. And if the user name, Bob, is in the local database, or admin, or whoever he's logging in as, he can authenticate. We could also do this.


We can make a third option. And that third option could be enable. Now, what does that mean? Well, that means that if a TACACS server is not reachable, no response, and the user logging in doesn't have an entry in the local database, there's no user account.


It's not that there is a user account named Bob, and he has the wrong password. There's no Bob in the local database. Then it will default to the enable secret. At which point, it would prompt you for the password. So Bob would connect, initially. Bob would have a bogus user name that wasn't in the local database.


And then it would fail. And then it would just ask us for a password. And that would be the enable secret. So this could be our method list as a fallback. Or we might want to say even we could do four. I guess we'd say none. If there's no enable secret, the default method would go to none.


But that's not a good idea. Saying none for an authentication method isn't a good idea. So we'll do these steps. We'll create the local user, enable AAA, separate method list, and we're also going to specify at least one AAA server. So we will tell R1 about the IP address of a AAA server so that when the AAA server is configured, which is our next step, it'll be able to go ahead and communicate and respond and do authentication with it.


So that's our plan. Step by step. Inch by inch. Life's a cinch. Let's go ahead and, first, take a look at R1, create our local user, enable AAA, and set up our method lists. So let's bring in our router. He's about to get a makeover with security with AAA. What I did on this router is I wiped it out as far as any of the previous security measures we had taken with AAA because I wanted to give you the ability to see it all step by step by step on a brand new device.


So on this device, the very first thing we're going to go ahead and do is in privileged mode, privilege level 15, we'll get into configuration mode. And then we'll create a local user account. Why? Because if all else fails,-- we can't reach an external AAA server, we have a password configured incorrectly, what have you-- we want to have a method in our method list that says use the local database.


And we want to make sure we have a local user that has privilege level 15 access. So it'll only create two users. One for admin with privilege level 15. And one for Bob at privilege level one. Because we use the secret key word, both of those are stored as the MD5 digest and their secret. They're kept that way.


Next, we want to make sure we have an enable secret. And we also want to enable AAA. Well, the next thing we want to do is I want to tell this router, hey, guess what? Dear Mr. Router, there's a TACACS server available. Let's take a look. So if this router's on the 192 168 zero network and the 10 three and the 10 two and the 10 one, I've also got another network.


It's, actually, off of this firewall. It's like on a little sub network. That's the 192 168 one sub net. And that happens to be where the TACACS server is. So I'm going to tell this router that if it ever needs to talk to TACACS server for any reason,-- he doesn't have any good reasons yet to do it-- I want to give him the IP address of that tactic server.


So that's our next task. It is to say, for a TACACS server, there's a host at 192 168 one dot 252. What we also might want to do is verify that we can ping that host just to make sure we have basic connectivity in place. So let's do a do ping of 192 dot 168 dot one dot 252. And hopefully, we have connectivity.


Good. We do. So one of those got eaten by ARP, which is normal. And then the rest of them made it. That's fantastic. We also need to tell the router what the password is that it should use to encrypt the entire session with that TACACS server. So we're going to specify TACACS server key.


I'm going to use a key of Cisco 1, 2, 3. When we configure the TACACS server to respond to this router, we'll have to configure the same keys so they can successfully communicate with each other. So far we've enabled AAA. But we haven't done is we haven't specified a default method yet.


So if we want to specify default method, let's do this. Let's tell this router that the default authentication method for character mode login-- we want it to be, first, one of the group of TACACS servers. Currently, we have a group of one. That's OK. And if we can't reach a TACACS server successfully, go ahead and use the local database.


Because the TACACS server is not online yet and it's not fully configured yet, we definitely want to have that fall back to the local database in our default method list so that we can still log on as a local user administrator. So we'll do that right now.


And you might also notice that, as I do this, there's no clicking of the keyboard. I have a lot of this pre done because I want to make it available for you in the Nugget lab area. So for this video, for video three, using AAA with radius, there's a Nugget lab file that is going to contain all the commands that I'm implementing here.


So you can download that, review it, and make sure you're comfortable with them. Because that applies to the VTY lines, the console, the auxiliary port and anywhere that we can get a login access for authentication that's going to apply. Let's create a custom method list that we can create and apply, if we want to, to an individual console or individual VTY line just so you get a feel for the whole picture.


So we'll create a custom authentication method list for character mode login. And I'm going to call it free bird. My good friend Kevin Wallace did a quality of service and he used the term free bird in it regarding how long it would take with or without quality service.


And I still think of him, to this day, whenever I think of free bird. But this method list called free bird says, if this method list is used, no authentication is required. So I'll tell you why we're going to use that. Let's use that on line console zero.


Why? Because if we apply that to line console zero, then I won't have to go ahead and authenticate when I connect to the console. It will make it a lot easier for me. For security, not that great. We might want to leave the default in place. But to demonstrate applying a specific method list, we're going to line console zero.


We're saying login authentication free bird. And guess what? Now, as we connect to the console, it will look for the method list and say, oh, no authentication required. Just come in because the method list is there. In fact, we could demonstrate that and we will.


Let me finish the config, and we'll demonstrate all of these together. All right. Next, just for fun, let's go ahead and set up a couple of authorization method lists just for grins. Now, authorization is optional. So once you've authenticated somebody, if you want to additionally ask the router to perform authorization for that individual, we can authorize lots of different things.


We can authorize exec shells. We could authorize people who are trying to go into privilege mode. We could authorize commands at privilege level one or privilege level 15. You can authorize, virtually, anything. And authorization means this. If you're telling the router authorization is required, the router won't let that happen until the authorization gets the two thumbs up saying, yes, that's OK to happen.


So this first authorization method list says any commands at privilege level one, use a TACACS server. And if your TACACS server is not reachable, check with the local database for a valid user. And the second method says any commands at level 15 should be checked against a TACACS server.


And if one can't be reached, check the local database. So these names right here-- instead of using the keyword default, I use this name. And that's what makes this a custom method list. What are the two methods in this list? It says use a group of TACACS server.


That's the first method. And if that's not reachable, go ahead and use the local database. And there's a similar functionality for the commands at level 15. It's amazing. Behind the scenes, the routers keeping track of all the commands that are being issued and what level they're at.


And this, these authorization lists, they are not in place yet. They're not enforced yet. They're, simply, authorization lists that are sitting in global config. But they would need to be applied to be worth something and used. Actually, before we apply them, let's create a couple of accounting method lists as well.


It's the same exact concept. We're going to create a method list for accounting records. We're going to specify what should be accounted for. And then we'll specify where to go ahead and send them. For accounting, it doesn't make sense to send it to the local database because there's no accounting server there.


However, if you do have a TACACS server or a RADIUS server, you could, certainly, send your accounting records up to the TACACS or RADIUS server that you had already gotten defined. So this one right here also, this command in the middle, is an interesting one that, by default, even if you're doing command authorization, if somebody goes into configuration mode, by default, the router stops checking for authorization.


By issuing that highlighted command, it also says, oh, by the way. Even though this user is in configuration mode, still keep checking to see if router rip is OK, or OSPF is OK, or anything else they might issue in configuration mode. So that one in yellow is, kind of, like a little gotcha.


A lot of times people say, I want to authorize every single command everywhere on the router. And then they don't include that. And once the guy gets into configuration mode, they wonder why their accounting records stop or their authorization records stop.


And that command needs to be there for the tap in. So the accounting records, the accounting method list, says I want to do accounting on commands at privilege level one. And here's this method list called TACACT1. I just made it. I want to account for when they started, when they stopped, and I want to go ahead and send it to a TACACS server.


So if there's a TACACS server configured and working, it'll send all the commands that are being issued at privilege level one and privilege level 15 if this method list is applied. So any customer method list is not applied by default. So we're going to fix that right now.


We're going to take our method list, our custom ones for authorization and our method list for accounting, and let's go ahead and apply them to actually put them to work. To apply them means to apply them to a logical place we're somebody would try to authenticate.


So we're going to apply these, as an example, to the VTY lines. So we'll go to VTY lines zero through four. And we'll say authorization for commands at level one. Authorization for commands at level 15. Use your respective method lists. For you who are brand new to AAA, in this video Nugget that we're doing together, right now, I'm showing you a large portion of all the pieces.


How they fit together. The basic concepts are, however, that AAA new model says I have a new paradigm of how to control authentication, authorization, and accounting. We can use default method lists for authentication, authorization, and accounting, which apply everywhere.


Or we can create custom method lists and apply them, as we are, right here for various aspects to control access on that line. Case in point. Somebody tries to tunnel it in right now on a VTY line. Because they're coming in on the VTY line, they're going to subject to the default authentication method list, which applies everywhere.


And they're going to be subject to this custom method list for authorization at commands at level fifth one and commands at level 15. As well as, accounting for commands at level one and 15. On the console we have a custom method list saying none. So no authentication and no authorizations happening there, whatsoever.


And let's demonstrate this. In fact, let's do this. Now, a trick here is I'm not going to leave the router. I'm going to tunnel that in to myself because if something goes terribly bad I don't want to completely lock myself out. So instead of logging all the way out, let's do a telnet to That's my own address.


And let's also do some debugging. That'll be fun too. We'll do the AAA authentication. That'll be enough for now. And lets do a telnet to Now, what I would expect to happen is, because they're going to be coming in on one of these four VTY lines, the authentication is going to use the default method list if we go up to here and take a look at it.


And here's our default authentication method list right here. And this default authentication method list says, go ahead and try a group of TACACS servers first. If you can't find them, use the local database. If we try to go in the console because it has the free bird method list we should see nothing.


In fact, this let's go to the console. Let's demonstrate that first because that way you can see the actual free bird being mentioned. So back on the console, debugging is still active. Take a look at that. It said, oh, you're coming on the council, which method list should I use? Free bird.


And free bird said no authentication required. And poof. It didn't prompt me for a user name. It didn't prompt me for a password. It just let me in. So let's go ahead and tell that. I need to put the right password in for going into privilege mode. So let's go ahead and tell that to ourselves with the debug still running.


And now we're coming in a VTY line. And now look at what method list it chose for authentication. It shows the default method list. And that default method list said use a TACACS server first. Timed out. Couldn't find one. And then it's going to local database.


So we can type in the local user admin. And a password of Cisco. And we're in. Now, if we wanted to see that, as well, check this out. We could do a debug of TACACS. And we could see the router trying to talk to the TACACS server saying, hey, are you there? I got a user.


Oh, I'm timing out. OK, I'll use the local database. So let's try that telnet, again, to the TY lines. So here's our TACACS+ request. It started a five second time out. So it sent out a request on TCP. And the TCP port is 49, as we have right here. So they sent out a TCP request to the TACACS server saying, hey, I've got somebody trying to login.


Are you there? Are you there? It wasn't there after five seconds. It timed out and went to the local database. Still asking me for a user but now it's off to the local database. And now I'm in. So there's the authentication. Again, it' just based on where we connect to.


So I would encourage you, for this, to, maybe, download the file from the Nugget lab site. And go through the commands and practice with this on a non-production router because the first couple of times you do this, you're very likely to unauthorized yourself right out of the router.


We have to physically turn it off and physically power it on. Let me tell you a quick true story. In 2003, I went to go get my CCIA in security. And I had a great time. Lots of fun as those labs always are. And I, absolutely, locked myself out of one of my devices.


So I had been saving as I went. I got to a AAA task. I was in a hurry. I put a default method list for authorization. I pressed enter and it was done because no longer did I have the authorization to access my gear. So to fix it I had to power off the router that I was working on.


Power it back on. It came back right to where we left it. We put in the correct commands, continued, and passed. However, it happens to the best of us. Where do we go from here? Now that we have this functioning, we have the basic configuration set up on the router, let's go ahead and take a look at setting up the AAA server to support it.


And our AAA server is right here. He's out on this network. And he's off of the firewall. And he's at So setting up the AAA server, the big concept here is that we have a centralized server that is willing and able to take the request of these AAA clients, the routers.


And verify user's credentials, verify whether authorization should be permitted or not, and, essentially, keep accounting records. So let's bring over Cisco's ACS. And the actual configuration of ACS, it's a big animal. It's got lots of bells and whistles.


And I'll tell you why. It's possible that in an organization with hundreds of devices, or thousands of devices, and dozens of administrators, you might want certain users to have certain rights on certain devices. So we have network device groups that we can set up.


We have user groups that we can set up. We can give different permissions to the groups. And then we can put users in those groups to get access to certain devices. So it's mix and match. Very modular. Let's take a look, first of all, at our network devices and AAA clients.


Here's R1. Let's go take a look at him by clicking on him. It says this is R1. His location is here. His device type is a group of routers device type. Again, we can categorize that as west coast routers, east coast routers, and so forth. And here's the IP address.


Now, this IP address, 192 168 1.125, doesn't look right. So let's take a peek over here. Oh, I see what's happening. So there's some network address translation that's happening between the AAA server that's off of here as it goes through this firewall. So the AAA server is actually seeing the router.


Even though its' address is 192 168 0.1, it's seeing it as 192 168 1.25 as goes through NAT. Network Address Translation. All right. So that works. And then, here, we have TACACS. So for TACACS, we want to put the correct secret, which is 1, 2, 3. If you don't have the right secret, they won't be able to successfully communicate.


And I'll submit that. And then we'll go take a look at users. Here's our internal users. I've got Admin, Bob, King Kong, Sally. We could make a new one. So I'll click on create. Let's call it Test Admin. And his password, we'll make the password Cisco. It's not very secure but very easy for me to remember.


Now, this is the magic. If we already have groups set up, we could say, you know what? I want to put this user as part of the admin group. And by that association, he'll get all the rights that the admin group has to a certain group of routers in a device group.


So that's the mixing pot of how certain rights get associated with individuals. So we'll click on OK. And I need to confirm the password of Cisco here. And submit it. And now I've got this user called Test Admin who's a member of the admin group. I've also got a user called Sally who's a member of the help desk who, of course, won't have the same rights as Test Admin.


And I've got Bob, King Kong, Admin. So how do we test something like this? So the AAA server knows about the router. The router knows about the AAA server. It is so easy to test this. Check this out. From the router, let me bring him back over here. Let's do a debug of TACACS, again.


And let's just do a test. This is a fantastic troubleshooting tool because a lot of times there's so many moving parts. Like, how do we verify that this user connecting from that place is using the AAA server in the back end? This is a great test between the client and the AAA server just to make sure that piece is working correctly.


Let's do a AAA. And we'll specify a group TACACS, which represents a group of TACACS servers. We happen to have one at the moment. That will do. And then the next TACACS will be the user name. How about that user we just created? What was her name? How about Test Admin? Let's check test admin, the one we just made.


We'll put in this password. Unfortunately, for this test it's going to be clear text on the screen. So if somebody's watching you, that wouldn't be a good thing. But it is what it is. Maybe, make a test account. Try it out. Delete the test account. And then there's an option for how we want to send it.


And I'm going to use legacy method. So now what? OK, wow. That worked first time. Fantastic. So this says attempting to authenticate to the server group TACACS. User was successfully authenticated. And the debug is, simply, showing us that it found out you had the user information.


It wanted to get the password, which it all did from that one command test of AAA. And the success was pass. The status was pass. So if it come back as fail-- let's do it. Let's do a fail. Let's do another test. Lets put a user that doesn't exist. How about Billy just to make sure that Billy doesn't exist here? All right.


So Billy doesn't exist. And we'll go ahead and see the responses. It was rejected by the server. And look at this. It has a fail message. So we have a message from the TACACS debugging saying, yep, the AAA server responded. And the answer was no. It wasn't that we timed out.


It was that the AAA server said no. So now if we leave the debug running and we do a debug AAA authentication, and debug AAA authorization, and debug AAA accounting because I think we have a whole bunch of stuff for the VTY lines. Then we're telling it to ourselves.


And let's go in as test admin. And the password is Cisco. And then we'll go into privilege mode. Now I didn't do authorization of the exec shell. And that's why it didn't, automatically, put me at privilege level 15. I didn't tell the router to check for authorization for an exec shell, which would have tied it to my own privilege level.


So in this Nugget, we've identified how we can extend the reach of a centralized AAA server and make it usable by multiple clients. This guy could use it. In fact, the switches could all tie into for authentication of users if they were doing something like 802.1X. Port based authentication, as well.


We can use, as the language of love, TACACS or RADIUS. They both have their pros and cons. And here's what I'd like to do as a final little exercise with AAA. I realize that AAA can be a little daunting. There's a lot of bells and whistles. Here's a little exercise I'd like each of you to do.


First of all, I'd like you to start off with a router that's not in a production environment. You've got a command line interface to it. And here's what I'd like you to do. I'd like you to get into privilege mode. And then go to configuration mode. I'd like you to turn on set enable secret.


Go to AAA new model. Enable that. And then set a default method list saying I want the enable secret to be my default method for authenticating. So with just those commands right there. Enable secret. AAA new model. And a default method list. This guy right here.


Now, if we tell that to ourselves or go back on the council, either way, it should prompt us for a password. So the password is going to be Cisco. The first thing it said was get the password because the default method was enable secret. And then, when I supplied the correct password, it let me in.


Let's try it again. And let's put in the wrong password. So I'm going to put in the incorrect enable secret. I want you to see visually how it says fail. Wrong password. And now it's prompting me, again, for another password. I put in the correct password.


It lets me in. So the basic concept of AAA is make sure you find out who people are. Or if your using a method like the enable secret, make sure you have the correct enable secret supplied. Once you have a user authenticated by identifying who that user is, if you're using the local database or TACACS, you can then authorize if you want.


That's the second A of AAA. And then you can send accounting records, as well, up to the AAA server. I have had a lot of fun in this Nugget on AAA and, actually, putting it in motion. Most companies are using some type of centralized authentication for medium and large companies.


You definitely want to be comfortable with it. Again, I'd encourage you to do the practice, the hands on. Go visit the Nugget lab. Download all the commands I used in this Nugget, and practice them yourself. I hope this has been informative for you. And I'd like to thank you for viewing.

Securing the Switched Data-plane

Tools to Protect the Management-plane

Controlling the IPv4 Data-plane with ACLs

Protecting IPv6 Networks

IOS Firewall Fundamentals

Zone Based Firewall Implementation

ASA Firewall

Intrusion Prevention Systems (IPS)

IOS-based IPS

Cryptography Essentials

IPsec Site to Site VPNs


Defense in Depth

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Intermediate 11 hrs 17 videos


Basic Plan Features

Speed Control
Included in this course
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Included in this course
Follow what the trainers are saying with ease.

Included in this course
Files/materials that supplement the video training

Premium Plan Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Included in this course
Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Included in this course
Develop and maintain a study plan with assistance from coaches.
Keith Barker
Nugget trainer since 2012