Hello, my name is Tyler McMahon with Aruba, a Hewlett Packard Enterprise company and you are watching Part 2, of our Aruba, the network security basics course. This is video 15 where we are going to finally start looking at different types of authentication. Three specific types of authentication, that pretty much match almost every scenario you're going to run into out there in the world. Sounds crazy? Well, stick around and let's check it out. If you were wondering that the answers for the previous pop quiz here was matching your certificate authorities and public-key infrastructure terms to their descriptions, the root CA, is an entity believed to be trustworthy. The intermediate and subordinates CAs, those are entities that issue certificates to end entities. Entities being devices, switches, PCs, mobile devices, and an end entity, well, as I just explained, devices that obtained certificates, but do not actually issue those certificates. Let's go on to those three types of network authentication, how we can break this down. While there's a lot of variables here, they fall general under those three different methods. We want to be able to authenticate users as they connect to our network, whether they're guests, whether their Internet of things devices, or old laptops or old printers and things like that that maybe can't authenticate themselves very well, or whether it's a fully trusted corporate laptop, two-factor authentication, three factor authentication, whatever connection that we're using here. Either way we want to establish zero trust. We want to know exactly who's logging in, when they're logging in, where they're logging in, what kind of device they're logging in. We want to gather all that information. We want to have a consistent policy across the entire network here. To be able to get this type of deep view and control over our end advices, we're going to implement a couple of things here. One, we're going to push the authentication to the edge of the network. As soon as someone gets connected, they're not going to get far at all before we're questioning their authentication, and we can check what type of traffic they're sending, permitting or denying through in-depth deep-packet inspection firewalls that we run on our mobility controllers or gateways in our network here, as well as a centralized policy through a AAA server such as ClearPass Policy Manager. Aruba switches, Aruba access points, Aruba mobility controllers, and you're going to have full support for tunneling back to the mobility controller that's doing the Aruba firewalling or just totally right here to this controller, that's fine, as well as offloading your policies so you don't have to come up with the same policy on 1000 different devices, you can just come up with at once on your set of ClearPass servers and it would leverage across your entire network there. Access then is based on not only who the users, but we can also set policies to dictate more or less access, authorize based on device type and other factors, time a day, where the device is located, operating system, is the device healthier or not all sorts of stuff. The first option we're going to look at here, and by no means the most important, but just one of three is guest authentication. This is every time you've gone to a coffee shop or travel to a hotel or an airport or something, you'll see these free open Wi-Fi access points to allow you to get connected pretty easily. Here the user connects to an open authentication endpoint, so we're not really encrypting, is just open, seems like there's no authentication whatsoever. However, there being blocked by the authenticator and this case a wireless mobility controller an IP, but it could be a switch if they're wired, or it could be a standalone access point, same thing would occur. The device obtains an IP address just so that we can redirect them to a guest web portal page or a captive portal page to gather user information. Maybe they self register, maybe they just click a link and they're online and we don't care about their username and password. Maybe they have to have pre-generated usernames and passwords, or they're being sponsored by an employer at your organization. Either way, the user will be given the option to log in with or without credentials depending on what you set up and once they do log in, the request gets passed to the radius server within ClearPass, and this could all be one server by the way, but the radius server, that functionality of the policy manager tests whether they've passed authentication or whether they made a mistake. If they passed, we can then also authorize what level of access we give them. You might think, well, guess or guess, but maybe it's a contractor, not an employee, and they need additional access beyond just someone's sitting in your lobby looking at Facebook all day. Devices can generally access Internet and other appropriate resources as you desire, but keep in mind, guests mean that you don't know or trust who the user is and you don't know or trust the device they're on. The basic tenant of security here is don't give them internal access, just pipe them right out to the Internet. That's easy to do with session-based firewalls that you have available to you on the controllers. MAC authentication is the second major type of auth that we're going to look at. The advantage is this is no requirements or set upon the device, you had old rusty printer, wireless printer like I have downstairs, dozens of word 802.1X, doesn't support webpages, doesn't support using the password, it doesn't support anything. I can still get the MAC address of the device and just simply say "If you have this MAC address or this kind of MAC address, I'll let you on. You don't need to authenticate beyond that." Although it is easy, the downside is anybody can spoof that MAC address, mallory the malicious could easily spoof the MAC address, would not be difficult at all, and it can be a little bit of a pain to create a whitelist of what MAC addresses are allowed and which ones are denied. The way we supplement this is by fingerprinting the device. We check and see things about the operating system, about where it's connecting, how it's connecting, to see if someone is indeed spoofing a printer or spoofing Internet of things device with their laptop. Then finally, 802.1X authentication is the best, last for best. This is what we've been using for 20 plus years. It was originally a wired only standard and was adopted to wireless, and we'll look at a final slide here, listing all the different flavors of 802.1X. Why 802.1X is still valid today, even though it's so old, is because it's so flexible. It's a suite of different authentication options. But they all follow the same basic structure where you have a supplicant that is trying to authenticate to the network and it's going to be blocked access only allowing 802.1X traffic to be received. The switch that they're plugged into or the axis point that they're associated to blocks all other frames, all other traffic, unless it's IP traffic. In fact, it will challenge the supplicants saying, "Hey, send me your extensible authentication protocol traffic over the land." That traffic once it's received, is going to be tunneled to your AAA server using what protocol? You guessed it, radius. As it goes over to the radius server, the radius server then sends a response back saying yes, that is the credential you are allowed or no, that is not the credential you are denied. You might think, okay, well, what credential is required? Well, not only is the supplicant authenticated to your ClearPass or AAA server, but your server is also going to be mutually authenticated to the client. It's like when you get pulled over and the cop says, "Hey, driver's license ID," you provide your client credentials. But you're also say, "Hey, let's see your ID buddy," just tell them, I said that was a good idea. In that example, the server is providing its authentication to the client or the supplicant through the use of a certificate. All modern versions of 802.1X that we still use require a server installed cert that's been signed by a trusted certificate authority, that you're connecting supplicant or connecting client also has installed. Every client in this that's using a cert, should have that cert validated by a central certificate authority for the entire company, if not, you need it signed by a third party like they do cert their servers or something like that. That's it for this on,. in the next video, we're going to actually see this installation take place where we'll go through and connect the client in the lab environment to a switch, use Aruba ClearPass to start sending out the wireless client, and this is a neat tool with ClearPass where you can onboard the client and install those certs. A real issue when you start scaling certificate based TLS, super-strong encryption and certificate based authentication there, which everybody wants, but it's such a hassle without tools like onboarding to make it much, much easier. I'll demonstrate that in the lab and show you how quickly you can do that, as well as configuring 802.1X on wireless. We'll actually see this being built out, become familiar with Windows 802.1X settings, and then take a look in a later lab deploying this in a wireless LAN. I hope this has been interesting for you. Let's go ahead and stop there, and in the next video we'll jump into the labs.
