If we had some friends come over to the house,
and they asked, hey, can we get on your network?
We'd like to say, yeah, you bet.
We'd give them access.
However, in a corporate environment,
if somebody wants to just get on the network,
the default answer should be no.
[MUSIC PLAYING]
So in that light, one of the big aspects of network security
design is access control, access to the network.
And one popular way of doing access control is with
something called 802.1x.
And it works something like this.
The client who wants to get onto the network-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The client who wants to get onto the network--
the switch port right here on this switch is going to say,
you know what?
I'm really not comfortable about allowing
a whole bunch of traffic in here until I know who you are.
And so there's some software running on this computer that's
referred to as a supplicant.
And with that supplicant software,
it communicates with the switch.
And it communicates information about that user--
about their username, their password, or other credentials
that are required.
And the switch itself, if we had to do that locally,
have all the credentials on every single switch, that'd
be a nightmare.
So what we do is we have centralized management. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what we do is we have centralized management.
And we have a AAA server.
And often, that AAA server will be supporting RADIUS.
And in Cisco, what we would be using
is a device called ICE, the Identity Services Engine,
as a AAA server.
So here's the play-by-play.
The client, who wants access to the network.
The switch, acting as an authenticator,
would say, who are you?
And using the software on that computer,
it would communicate who it is.
Then the switch, acting as an authenticator,
would make a little road trip over to the ICE server
and say, hey, I just got this request from so-and-so. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and say, hey, I just got this request from so-and-so.
What you think?
And then the ICE server, where there
is policy and the details for if that user can log on,
based on the time of day and where
he's trying to log on from, will give a response back
to the switch.
And then the switch can say, OK, this port is now authorized.
I can allow your traffic in.
So that way, if we have hackers and attackers who
are trying to get into the network, at least
on the wired network, they won't have
access in because they won't get any further than that switch
port.
Now, 802.1x is not just for wired ports.
We can also use it with our wireless.
So if we have a wireless LAN controller
and we have an access point and we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we have an access point and we
have an ICE server or a AAA server we can use,
we can do it there as well.
And it's really a matter of just linking it up.
We need to tell the wireless LAN controller not only about
the APs that it's managing, but also the wireless
LAN controller about the AAA server.
We specify our policies on the AAA server.
And then when wireless clients try to connect,
we can require 802.1x authentication there to verify
who that user is, again, before we allow them full access
to the network.
So this is the interface for a wireless LAN controller.
Now for Encore, the goal here is just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now for Encore, the goal here is just
to get a big picture of some of the security factors
that we've put into our design.
And I just want to give you a little taste
and feel of some of those parts.
So on this wireless LAN controller,
if we wanted to tell this controller, hey,
you're using a AAA server, and we want to have policies that
are using a AAA server for the 802.1x,
we would specify where that AAA server is under the Security
tab.
And with the Security tab selected, over here
on the left, we'd go to AAA, RADIUS, and Authentication.
And it's here where we can specify the AAA servers
that we want to use.
We'd also want to configure the policies for our various WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'd also want to configure the policies for our various
wireless Local Area Networks, that they should use 802.1x
for authentication.
So we could grab one of our wireless LANs, here.
So here, it's showing a high-level overview
on the general page.
But when we go to Security, this is
where we can specify the details for the type of authentication
that we want to go ahead and use.
This is also where we'd specify the AAA servers that we can
rely on when we need to verify the credentials of a user
who's trying to authenticate with 802.1x.
So here on the AAA server, the RADIUS or the ICE server, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here on the AAA server, the RADIUS or the ICE server,
we have the policies that are specifying what's allowed,
what's not allowed.
Here's also where we'd have either
the information on the user accounts,
or we could integrate ICE with an Active Directory,
for example, to pull and retrieve that information
if we don't want to have it entered twice in our systems.
So the key here is that nobody gets on the network
if we're using 802.1x until we know who they are.
Now, there are some situations where 802.1x just won't fit
the bill.
For example, we're using it maybe
for everybody in our enterprise.
But what about a printer or an internet of things device
that's connected to our network? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's connected to our network?
Well, hopefully that thing is authorized
to be there in the first place.
But if they can't support the interaction with 802.1x,
we also have an option called MAB--
MAC Authentication Bypass.
Basically, we can hard code in the system the MAC addresses
that should be allowed, even if they can't do 802.1x with
a proper supplicant.
So there'd be a process of the authentication that attempts
with 802.1x.
It would time out.
And then it would go ahead and check and see,
oh, do you have a MAC address that's on the list--
the nice list?
And then it could allow that MAC address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it could allow that MAC address
to go ahead and have access into the network
because it was pre-configured.
And one other option that can be used-- this is pretty cool--
is web authentication, or WebAuthn.
And the way it works is this.
When a user tries to connect, if they haven't authenticate yet--
so the system doesn't know who they are, but needs to--
it can redirect them to a web page.
And that web page can give that user the opportunity
to put in their username and credentials, whatever
we're requiring for log in.
And then once that information gets input
by the user, that can be checked with either the wireless LAN
controller for doing it locally there, or better yet,
with a AAA server-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with a AAA server--
ICE again.
And then once the user is authenticated,
we can then allow that traffic to go through.
And that way, we don't have to have
a supplicant on that computer.
But we still have the opportunity
to gain that information about who that user is,
based on pausing them for a few seconds at a captive portal
and doing WebAuthn.
So in this video, we've taken a look at a few different methods
for authenticating devices before allowing
them to connect and get access into the network.
And in the next video, I'd like to chat with you about, well,
once they're on the network, how do we
keep those devices secure and protected?
And that's the focus for our next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.