Network Access Control Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

4 hours 25 minutes
Video Transcription
hi and welcome to module to lessen 3.3. In this lesson, we're gonna cover network access control, otherwise known as neck. We're gonna talk about the basic functionality of neck. How does it work? Why do we use it? We'll also talk about supplicant and non supplicant devices. And all of supplicant is is software that speaks a certain language.
We're gonna talk about what what we could do after authentication. So knack is just basically a way to authenticate devices before they access the network, and we'll talk about how that works. But we also then talk about
after authentication some of the issues that can come up.
Let's start with basic neck functionality. As I said before, Knack is just a way to authenticate a device before it actually gets onto your network. You can have the net would be smart enough to detect whether the device it's trying to connect to it is friend or foe. You can also have it be smart enough to detect what type of device it is and put it in certain
parts of the environment, depending on what type of device it is
now. This works on both a wired and a wireless environment,
and it works on the basic protocol of 802.1 x, which is a standard layer to authentication protocol it support level authentication protocol.
It's a basic functionality. Whenever a device tries to connect to the network, that network is going to detect that connection either in the form of Link State. If it's a wire device, are just in the form of an incoming connection. If it's wireless
if configured for 802.1 x authentication or neck, the device is gonna have there's gonna be a two way ah challenge credential request and response mechanism that happens between the end point in the device and then that information is going to be sent to a back end authentication server.
In our case, we're gonna talk about using a radius server on that back in for the final authentication mechanism.
And then once an authentication decision is made, the switch will put that device onto the appropriate villain. And only then can that device actually communicate on the network. All of this authentication happens before the network layer even even starts. This is all that layer to
Let's take a look at this in a little bit more depth. 802.1 x It takes makes use of a protocol called the Extensible Authentication Protocol, otherwise known as eep.
And the way this works is on the left side of the screen. Here, we've got our in point. Let's just say that this is a work station and it has an 802.1 x supplicant loaded on it. Now all that means is it is a supplicant is a piece of software on that system that understands how to speak the 802.1 x protocol
in the middle. We have our authenticator. In this case, it's our switch, and on the right we have authentications server, and this is where the actual authentication decision is going to be made. And in this case, it's going to be a radius server.
When that device first connects to the network,
the switch detects a link state. It detects a new connection
so that switch or authenticator,
will send back an EAP identity request. It basically says, Hey, who are you?
The device. If it has a NATO to don't want X supplicant installed on it and it knows how to speak. Edited out one X protocol and deep language. It will respond, and it'll say Here, Here you go, Here's my identity. Here's who I am.
That information is taken in its encapsulated into a radius request and it's sent from the switch to the back end Authentication server in the form of radius
the radius Request the radius server basically says, Okay,
prove it. It sends back a radius access challenge. You say you're this person or say they do this device
prove that you're that device.
That radius challenge gets de caps elated outside a radius and it gets converted into an ape response. And that response is basically sent back to the supplicant again in the form of another eep request. And this is an epic challenge request
and says, Okay, prove who you are.
Now that's supplicant.
Should be configured to hand back a certain set of credentials when challenged, the very common one, and are very effective. One is a machine certificate.
So if you've got, say, a PK I environment, you got a certificate environment in your internal network, you can actually issue trusted certificates to all of the devices in your environment. And that way, any time they're challenged with with a Radius challenge, they can hand that certificate back. And that's how the Radius Server will know that they're actually
and a company asset versus some other device that, you know, some guests just walked in and plugged in.
But when this request comes back, if the supplicant is configured to hand back, say a machine certain it's going to respond with that as its response, it's gonna it's challenge response. It's gonna hand the certificate back to the authenticator, the authenticators gonna in capsule at encapsulate that back into radius again and send that response back to the authentication server or the Radius server.
Now, at this point, the Radius server looks at its policies internally and says, OK,
you've identified yourself. You've proven your identity. Now let's see if that identity is something that our policy is going to allow on the network. So the Radius server goes through its policies and it makes a decision yes or no. Along with that decision, it could also send additional information back so it sends a radius access decision back to the switch.
But it's not just a yes or no decision.
Other information could be coupled into that decision as well. For example, if that certificate what if, instead of it being a laptop over there on the left hand side? What if it's a phone? Because a lot of voice over I p phones have the ability to. They have a low to no one except Wiccans, and they have the ability to have certificates.
Maybe you have different certificates for phones than you do PCs, and the phones certificate is gonna be distinguishable from the PC. So when that phone identified itself and it handed over its certificate, the authentication server not only says yes, you're a phone and your validated to be on our network, but it knows you're a phone because of what your certificate looked like
so it can pass that information back to the authenticator
at the same time it makes a decision so it can pass back. Say, yes. This thing is authenticated, and by the way, it's a phone.
The switch then finishes the EAP decision, and it opens up the villain and puts the device on the proper villain.
You know, if it's a company asset. Maybe it's the production be land. If it happens to be a guest device and it doesn't have a company as a company certificate, it puts it on the guest feelin. If that device happens to be a phone, maybe there's a voice V land or a printer villain. You can have different V lands for different devices, and those certificates can help identify what types of devices they are
and that can be used in the decision
on which of the land to put these devices in two. And then you can wrap security around its. Each of you land in the form of ankles or firewall rules or something like that.
Now on Lee, after all of this takes place, that villain is then open. That device is then placed on the villain, and only then can that device actually go out and try to get an I p address and start communicating on the network. So all of this happens before the device is even allowed to communicate on the network
Up Next