Hello and welcome, my name is Tyler McMinn with Aruba, a Hewlett Packard Enterprise company. This is the network security basics course part 1, where we are going to continue our discussion from last video where we were talking about out-of-band management, centralizing our authentication across multiple operating systems. Without further ado, let's jump on in. When we log in to our switches and to our controllers, we have a different set of rights that we can access. We're going to talk about two major operating systems. Well, really three, when it comes to Aruba, you have the older Aruba switches known as the Aruba operating system switch or OS switch. This has been around for a long time. These are more edge switches that are essentially layer- three switches that do switching very well. The Aruba CX switch, or Aruba OS-CX, is this new line of switches. They have slightly different operating system that's a bit more standardized as to what, if you've worked with other switch vendors and you've been in the business, you'll recognize those commands pretty well. We're going to be jumping between these two and I'll demonstrate on both of these. I did say there were three though. This 7210 that I have down there is known as a mobility controller, so that'll be the Aruba OS. I know it's a little bit confusing Aruba OS without the switch. This refers to wireless. This is what our access points, our campus and our remote access points, they are managed by these 7210, by these Aruba OS Mobility Controllers. We will be jumping between these two. Not so much on the wireless, this part or this section of videos, but in the next one we'll be doing a lot more with the mobility controllers stuff. For now, we'll just focus on the older Aruba operating system, but still out there and the newer operating system on our CX switches. Notice the similarities though, in both cases you have operators and you have managers or instead of managers, we call it administrators NCX. The difference is operators are essentially read-only. They just do normal show me this, show me that, what we call show commands. Same operator exists on both the switch and the CX. If you're logging in as a front desk support person, or you're just doing a little bit of troubleshooting, an operator login is often all you need. If you are an administrator with full read-write access and you want to be able to issue changes. You would want manager level or administrators level on a CX switch. Then CX also introduces a third login known as an auditor. Why have these different roles? Why not just make everybody a manager and be done with it, and in smaller environments, that's what they do. However, this breaks the idea of least privilege as security concept called least privilege says, ''If I need this amount of privilege to do my job, only give me that amount of privilege. Don't give me the whole thing. That'll give me too much rope or enough rope to hang myself on.'' Setting up external authentication for management, this means instead of having a 100 different switches where I got to put in usernames and passwords for all 12 of my IT people, what I can do is put all those onto one central AAA server. That server then is where we make updates to our usernames are passwords, or we use that AAA server to just tie into our Windows Active Directory list of usernames and passwords then I have to put them anywhere. They're already built in Active Directory when you get hired. Instead, my edge switches, my 100 switches, my thousands of APs or my dozens of controllers or whatever it is, that's on the edge of my network here, they don't need to know anybody's identifier, all that information when it comes in, I could pass it to my AAA server, who then might query other databases as well. But the AAA servers, the one that handles how they authentication takes place. This idea of centralization means that I've got all my configuration in one place and I can easily increase it, decrease it make changes. I can affect policy a lot easier with less mistakes than if I have to repeat the policy on switch after switch after switch after access point, after access point, after access point. To do external authentication, you first want to tell your switches who the external servers are, you want to specify how they talk to that external server. How do I send the username and password? What if the user presents a certificate? How do I pass that to my AAA server? How do I set that up? We're going to specify one of two major protocols, RADIUS or TACACS. Predominantly most people use radius for just regular users and if it's an IT person, a manager, who's logging in to the switch itself, not through the switch to get to the Internet, but just to the switch to manage it through command line or open up that pretty good interface or whatever else, we would use TACACS. TACACS is a little more secure and has different features that lend itself to management over something like radius. There's nothing non-standard, everything is standardized that we're going to try or at least I'm going to stick to as much standardization as possible in describing these features of security. That's really important with security. The more you start to get away from the standards, the more you risk mistakes and that could open up exploits in your network. Specify an external access method we have on the older Aruba OS switches, the commands AAA authentication, we can then specify what access we're giving, are they just logging in or they're getting Manager privilege level? What type of access is the user attempting? Is it command line through Telnet or the secure shell protocol? Are they trying to get console access or they open up the GUI? Are they running scripts against our switch? Good scripts, not bad scripts. Then if that's true, what's the first type of server that we're going to authenticate against, is it just going to use the username and password locally on the switch? Or we're going to go to a RADIUS server or group of radius servers. Are we going to go to TACACS server or group of TACACS servers? You might think, oh man, this is so much, but literally, here's two examples, where the first one enables this AAA authentication, authentication and authorization accounting to reach your server, and it enables it for login access and then again for Manager access, for enable access. That's it. Two quick lines and you're done. You put this on every switch in your network. Every switch has now enabled to use TACACS or a group of TACACS servers for their first SSH login. If TACACS is unavailable when I try and SSH to that switch, the switch will then try the credential against a local account. If TACACS server is not available. If it gets sent to a TACACS server and my username and password is wrong, then that's it. You don't go to local, it fails out. What's different then if I use a more modern CX switch? This is where we'll stop. It's basically the same exact commands you do in AAA authentication for login access or enable. I could put that there as well, for SSH as the protocol, and I want to check it against the group TACACS and if the group TACACS is not available, try local. Very little difference in the commands. That's going to be it for this discussion. We talked a lot about how do we harden our devices, setting up out-of-band management access. Talked about that out-of-band management important there, the advantages of out-of-band management access. Then the different roles on an actual enterprise switch, operator managers versus operator administrators and the auditors. I introduced the concept of the two different operating systems we'll be touching on, as well as using external access and a couple of quick examples of the commands that will be seen here in some later labs. Let's pause for there. In the next video, we'll get into Securing our protocols like RADIUS and TACACS like SSH over Telnet, HTTPS over HTTP. But I'll save that for the next video. Thank you very much for your time. I'll see you in the next one.
