Network Access Control (NAC) and Authentication Wrap-Up

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 »

8 hours 19 minutes
Video Transcription
one other services on the network that we want to talk about in relation to authentication access is network access control, sometimes referred to as N A C.
As we know, there are all sorts of acronyms that sound the same.
Don't confuse this with an 80 not, of course, network address. Translation.
We're on network access Control.
The idea behind an A C and one of its primary uses is to either allow or deny access to clients based on their health.
When we talk about client and think about health of a system, things that make a client healthy, do they have antivirus and anti malware? Are they running a firewall or spyware protection? Are they up to date, or are they behind in their patches?
We can specify various pieces of criteria to what we consider makes a healthy client.
Then we can figure the policy that essentially says, this is how we determine what's healthy. And if a client meets our health requirements,
then they are allowed access to a resource.
If they don't meet our health requirements, then they're either denied access or could even be potentially sent to a remediation network.
For instance, if I require my clients to have anti malware and a client doesn't.
Then they could actually be redirected to a segment of the network where they could download anti malware and try again.
There's all sorts of capabilities with network access control.
The idea is, as you can see on the screen, we have the requester of services. In this instance. Maybe I'm at home and I'm trying to be PM into my internal network.
As I make my request, I would connect to a VPN server, or in this case, it looks like the access requesters connecting into a switch.
At any rate, what we see is the request is actually being forwarded to a radius server.
We talked about Radius multiple times. It could be forwarded to the N A C server, as you see active directory, firewall, whatever.
We have three big pieces. We have the client initiates, request the enforcement point and the decision point.
If we were doing this and trying to connect into the switch with credentials, that request would be sent to the decision point.
The decision point asks. Is that client healthy or not? Here are the criteria to consider the client a healthy client
that's passed back along to the switch. The access is either denied or allowed.
Ultimately, the access is there at the enforcement point, yes or no.
The real decision is made at the next level at a policy decision point.
It's the same way with radius. You connect to a VPN server and the VPN service says, Hang on, let me forward the request of Radius Radius comes back with the decision, and then that enforcement point either allows or denies access.
It's the same idea here with network access control.
This idea of having the client verify and validate their health to the health server is going to be really helpful If I have laptop computers that come and go from our organization and you may be connecting to one network today, a different network tomorrow.
That's one way that systems can really become infected is because different organizations have network security variances.
Every time a client comes into log onto your network, having to provide a statement of its health is going to go a long way, making sure you're infected. Clients don't get on the network
that's going to require that your client be capable of providing a statement of health.
Most operating systems that are current have that capability, but it's a service that is not turned on by default in Windows.
It would be something that you would have to enable. You would have to enable it on the enforcement point and configure the policy on the decision point on the back end.
Very frequently, stuff like this is done on either Radius R N A. C or Windows has a function called Network Policy Server.
That's where that includes decisions for Radius or for N A. C or any other element.
The bottom line here is we can either allow or deny access to resources by challenging a client or saying, Prove to me you're healthy.
That client provides a statement of health based on what's allowed or what's configured in the operating system.
The statement of health provides the necessary security stated by the N I C server. Then the system is allowed to connect in.
It's a good feature, and it helps us make sure we don't have devices connecting to our network. That R and S is updated as they need to be.
Some key takeaways from the section.
We talked about the benefits of single sign on making it much easier on our users, not weighing them down with lots of passwords to keep up with.
It also makes it easier on administrators because they have a single directory database that they have to monitor and control.
It makes it easier to secure the environment, and it makes it easier to allow access.
When we're looking at an internal network infrastructure, it's often Kerberos that we use to provide our single sign on
once we want to extend beyond our domain and start sharing identity information with other software as a service providers or cloud providers. That's where we rely on our administrator, creating Federated Trust with them.
Once the trust is established, we either allow s AML tokens or open ID connect tokens to provide that authentication information for our users. We also said, Oh, off to piano is a part of open ID connect, and that goes beyond just authentication
that allows for the delegation of services.
Last but not least, we talked about network access control network access controls. Purpose is to prevent client systems that are not healthy from joining the network. It's a network administrator that determines what health of a client should be.
And I see you put a system in place so the client verifies their health and that it meets the minimum requirements to join the network or to access the resource.
Up Next