>> One other service on the network
that we want to talk about in relation
to authentication access is Network Access Control.
Sometimes referred to as NAC.
As we know, there are
all sorts of algorithms that sound the same.
Don't confuse this with NAT.
NAT, of course,
Network Address Translation,
we're on Network Access Control.
The idea behind NAC 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 how the VA system,
things that make a client healthy.
They have anti-virus and anti-malware.
Are they running a firewall or spyware protection,
are the up-to-date or are they
>> behind in their purchase?
>> We can specify various pieces of
criteria to what we consider makes a healthy client.
Then we configure the policy that essentially says,
this is how we determine what's healthy
and if a client needs our health requirements,
then they're 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 an 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 requestor of services.
In this instance, maybe I'm at home and I'm
trying to VPN into my internal network.
As I make my request,
I would connect to a VPN server,
or in this case, it looks like
the axis requester's connecting into a switch.
At anyway 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 NAC server.
As you see, active directory, firewall, whatever.
We have three big pieces.
We have the client that initiates the request,
the enforcement point, and the decision point.
If we were doing this and trying to
connect into the switch with credentials,
that request will be sent to the decision point.
The decision point asks,
is that client healthy not.
Here are the criteria to
consider the client a healthy client.
That's passed back along to the switch.
The axis is either denied or allowed.
Ultimately, the axis 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 services hang on.
>> Let me forward the request to 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've
laptop computers that come and
>> go from our organization,
>> and you may be connecting to one network
today and different network tomorrow.
That's one way that systems can really become infected,
it's because different organizations
have network security variances.
Every time the client comes in
>> to 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 the 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'll be something that you'd have to enable.
You'd 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 in
either radius or NAC or Windows,
has a function called Network Policy Server.
That's where that includes decisions or
radius or for NAC or any other element.
The bottom line here is we can
either allow or deny access to
resources by challenging the client
or say 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 NAC server,
then the system is allowed to connect
in. It's a good feature.
It helps us make sure we don't have
>> devices connecting to
>> our network that aren't as is updated
>> as they need to be.
>> Some key takeaways from this section.
We talked about the benefits of single sign-on.
Making it much easier on our users,
not weighing them down and 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, so 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 SAML tokens or
OpenIDConnect tokens to provide
the authentication information for our users.
We also said, OAUTH 2.0 is a part of OpenID Connect.
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.
An AC puts 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.