All right, welcome back. My name is Tyler McMinn with Aruba, a Hewlett Packard Enterprise Company. This is the Aruba Mobilities Essentials part 2 series. In this fifth video, in this series, we're going to cover wireless security and authentication. Really, the authentication and authorization piece, what they call AAA. Authorization, authentication, and accounting. We're going to save the encryption for the next video. There's a lot that we could really dive into here, but I'm going to try and summarize it. Without further ado, let's jump on it. We're going to take a look at role-based access control here through the use of a controller. Before we dive into that, let me explain what you normally do at your house, where I associate up, I connect to my access point and on there I'm using what's known as a pre-shared key or personal mode authentication. With personal mode authentication, you're validating that you belong on this home network here, by virtue of the fact that you have the correct pre-shared key. In other words, I know what the phrase is, I know what the password is, let me on. It's similar to you using a house key. If I have six house keys made and I hand them out to my neighbors, then anybody that has that key, by virtue of the fact they have the key, should be allowed into my house. But it doesn't really identify who you are. It just identifies that you have a piece of information that anyone else who has it would also be allowed to join. This is not really good authentication in that regard. It happens at a very low level, a very early level during the association and authentication process during the pre-shared key exchange or the shared key portion of a wireless user going to authenticate with [inaudible]. After this, is where you would typically do MAC authentication based on your Mac address of your radio, should you be allowed on. Or you would do what we call web authentication as a guest in a network where you would actually associate, get an IP address and everything else, but be blocked from everything. When you go to open up a website, you get redirected to a hosted web server that has a login page, free to login to. You'll see these splash pages, these web authentication pages. I think we're all pretty familiar with them. In Aruba, we refer to these as captive portal pages that you get redirected to. Again, not the greatest authentication, but at least you're approving identity through these types of authentication here. They're not cryptographically strong. They can easily be spoofed, especially in Mac addresses, those are trivial to spoof or to emulate someone else's Mac address. What do we do then in a corporate environment where we might have tens of thousands of users? Like at a college or a hospital or something like that where they all are trying to associate in thousands of times, in some cases per minute or per hour to our local area network here, our wireless network. We want to be able to validate who the user is. So we can choose whether we allow them to have access to the network or not. We need something that's going to be cryptographically strong, and these guys really aren't it. Even though they're encrypting after the fact with a pre-shared key, there is no authentication that's really being cryptographically strong if that makes sense. That's where we come into this idea of role-based access control. We're going to look at this from the view of a controller. Because an Aruba controller like that 7210, that controller and all of our controllers have a capability to do quite a bit. They have these very strong firewalls that are built in to the controllers. Normally a thin AP is going to forward all your traffic to the controller and after the controller, the firewall is going to do deep packet inspection. It's going to look at not just your source IP address or port numbers, but it's going to look at the payload itself and maps the type of traffic, the type of destination you're going to, what websites you're going to, what applications you're using, and make policy decisions or firewall decisions, whether it permits that traffic or blocks that traffic. Even our instant APs have that capability as well. It is a license feature, but it is one that is universally recommended. User access role can be assigned to say, what firewall policy are you going to get? For example, we could have a guest firewall policy that blocks all corporate IP addresses that a guest user might try and be hacking into. It blocks the corporate side, but it allows you to go to the Internet. As long as you going out to Facebook or whatever else, the controller says "Yeah. That's fine." But if you're destined for something internal, it's going to block you. Whereas, if we assign maybe a corporate firewall policy, we would allow you to go to both corporate websites and the Internet. Both would be approved if you received this firewall policy. The question is really when a user goes to login, we don't really know who they are until they provide this authentication through the access point slash mobility controller or firewall, wireless controller. Then it's up to this edge device to try and determine what role or what firewall policy it's going to assign, is it going to assign a guest firewall policy? Is it going to assign a corporate firewall policy? Did you fail your login so badly that it just drops you all together? What is it going to do? The way that it does this is it will typically identify the user through some sort of authentication, and we can even centralize this using what we call a AAA server. A server that's whose job it is, is to keep track of who's who, as far as corporate users, guest users, whatever it is, and then identify or validate their credentials. It authenticates them. It authorizes what access they get, corporate or guest, and it even does some accounting to say, yes you logged in at this time, you logged in at that time. You used this much bandwidth, whatever. With Aruba, we have such a AAA server known as ClearPass. That's the name of it if you want to check it out. There are other versions, the plenty of servers out there that do AAA. You can use ClearPass with pretty much any vendor that's out there. It's a good way to centralize your authentication so you don't have to keep track of users on every single controller, on every single switch. You just point those devices to ClearPass, and then ClearPass figures out whether they're good or bad, and sends a response back saying, "Hey, yeah, they're good, thumbs up, and give them the corporate access." Or they're good, give them guest access, or they have failed drop them. That's basically what ClearPass does. It can tie into your active directory if that's where you're keeping all your users, it can access that in real-time as well. This concept of role-based is really assigning users, once they've authenticated, you're authorizing the user, what level of access they get. We want to authenticate them, either using a username and password like Windows does or using certificate-based authentication, which is generally considered a bit stronger than just username and password. In addition to that, we can take into account not just who they are, but we can take into account what type of device they're on or even whether the device is healthy, if it's been updated recently, if it has any virus on it, you can look at things like that as well. You can take into account what department the user is a part of. Yes, they've authenticated. Yes, they're on the correct device type. You could have different roles set up by department if you wanted to. Each user can actually have a separate role. Normally, groups of users share a role. This makes your job a lot easier by coming up with a good security policy, and then you'd letting something like ClearPass or whatever your authentication server is that you're using, your AAA server that you want to use. You can write that policy into the logic of the server. Then all your controller and access point is doing is whatever it receives an authentication request, it just hands it over to this authentication server. The reason we call this a radius server is because the protocol, your wireless controller, APs we'll use to hand it to the server is called a radius. Then the authentication server can bounce that against active directory as well. I think I drew this earlier. There you go. First, the user attempts to login. When they go to "Login," what the authenticators are going to do the edge of your network here, whether it's an instant AP without a controller, or whether it's controller with a thin client AP, or whether it's a wired connection to a switch, doesn't really matter. It's going to stop the traffic and ask for the user to authenticate. The user, in this case, they call it a client, but really a better name is to call it a supplicant when it comes to authenticating over the network. The user attempts to login, we basically block it and request authentication, and that authentication gets passed to the radius server, the server may validate their credentials against windows if that's where the username and password are stored and get a response back. Then the server will use radius between the authenticator and the server, your controller, your switch, your instant access point, those are your authenticators, it will use radius to communicate back and forth between that edge of your network that you trust, and the radius server. Just to validate what you're getting back and forth. Ultimately the radius server may come up with what role it wants to assign. That's the authorization part. Once it's authenticated, it will send a message back saying yes, they are authenticated, but it can also send messages back saying, not only are they authenticated, but assign them the corporate role or the guest role, or the contractor role, or the student role or, whatever role makes sense based on whatever policies you built into this. Pretty cool because all of that is written once into the radius server and now that radius server access this central real-time management piece. You might think, "Wow, this is a lot." How long does it take between the client going to connect and all this authentication being passed back and forth, and the client being validated and ultimately put into the correct role? The answer is, this should be less than a second in most cases, if not even less than that. We're talking hundreds of milliseconds, if not less. This is meant to be extremely fast and to be able to handle this, we have large clear pass servers that are designed to handle hundreds of authentications per second in some cases, depend on what your needs are in your organization. Ten thousand, twenty thousand, fifty thousand students, no big deal. With an instant AP, no problem. The only difference there is you don't have a controller, so all of the logic goes on the instant AP and really there's not much to it. You just tell the instant AP who the authentication server is. That's it. They have a little shared secret between them, but otherwise, they are good to go. The authentication server is now receiving radius messages from the instant AP, or you can replace that with a switch as well. That is a very short summary of a process known as extensible authentication protocol over the local area network. If you've seen this term before, EAPOL, we can really get into the different phases, we can get into the different types of EAP like; Protected EAP, and EAP first and EAP last and all that certificates, authentication, all of it pre-shared keys and PKI and all the rest of it. But this that I just described, is hopefully a very good overview for you to understand the big picture. Don't get lost. Don't lose sight of the forest for the nitty-gritty trees, if you go off and start reading more about this, it all comes back to essentially the supplicant trying to connect to the authenticator and the authenticator passing that off to a radius server. That's basically at this back and forth with radius or [inaudible] between the radius server and the authenticator. Anyway, I could talk about this for days, so let's stop it there. In the next lecture, we're going to cover the encryption piece. I know I let that out. I'm saving it for the next video. I hope you guys enjoyed this video. I'll see you guys in the next one. Thank you very much.
