Hello everyone and welcome to the last lesson of our Encore wireless section.
This is all about WebAuth.
WebAuth is that little portal you see when you're trying to join a network.
A lot of you guys have that experience in a hotel.
Many of you probably have this as a guest wireless LAN environment for your enterprise
environment.
It's really important to understand WebAuth.
It has its own security features and it has its own, like, it's in its own security realm,
let's say.
There's some important things we're going to cover for our Encore exam, so let's go
ahead and get started here.
So WebAuthenticationTypes, what are you going to see?
So WebAuth is the basic one, right?
This is a basic message where you're going to see, I'm going to make sure that you're
going to see that.
What happens is, let's roll back a little bit, I had too many things going through my
mind there.
What happens is you attempt to join a network, an SSID, and you're presented with a page
and the page says, oh, you need to enter your credentials.
And oftentimes if you're at a hotel, it's like your room number or a pre-shared key
or things like this.
This is the regular WebAuth.
There's also AuthBypass, and this is used with a MAC address as the client identity.
Now what this does is this validates with the authentication server and you're ready
to go.
But it uses that HTTP front end in order to get you there.
And then there's the consent.
This is the one where there's not really any authentication that takes place.
You just got to kind of agree to the user policy or the policy for using the network.
You must accept the policy to use it.
That's how that works.
And then lastly, one of the authentication types is WebConsent.
Now WebConsent is very important because it does both.
Now you always kind of want to have, when you have a guest on your network, you want
them to accept the access policy.
So really this is where people should really live and breathe, down here in the WebConsent.
If you're using WebAuth for a guest wireless LAN, you really want to use WebConsent because
this is what, you know, your employees often sign papers with HR that say, I consent to
this or that when using the network or when using company equipment and things like this.
WebConsent is different because you have guest users on that account.
You don't have that HR paperwork and backing.
And usage policy is important if something goes wrong.
Usage policy allows you to prosecute people who may have nefarious intentions.
You're not welcoming them on your network.
And believe it or not, the legal aspect of this is real.
It's a real thing.
So having a usage policy is important, but also having that authentication where they
have to have something you give them, right?
Something they know, something, you know, have that security systems go with something
you know, something or some type of authentication.
You want with that usage policy, you want a username or password or something you give
that guest user so that you don't have just anyone joining your network like you would
with just a consent policy.
You want them to actually have to have some token you give them or some knowledge you
give them so that only authenticate users.
Now, if you're a public place like a Starbucks, the consent is obviously the way you're going
to go.
Maybe you could have, if you're a coffee shop, small coffee shop, you could have the
password of the day up there and change it, but that's a lot of work and it depends on
your organization.
But these are the WebAuth types and I'd like you to know them for the exam.
I'm going to take myself off the screen.
I'm kind of covering some of the words here.
Let's go ahead and take a look at WebAuth roles.
Now we talked about the types.
Now let's talk about the roles.
First, there's clients.
Those are the people who request access to the wireless LAN and the services.
These are the people who want to use it.
The access point is where they're going to connect to.
This restricts IP traffic except DHCP and DNS when they initially connect.
We're going to go through this step by step, but the access point is really what they're
hitting first and your guest or WebAuth roles are going to constrict everything until they
sign that user policy, until they say yes.
They're really only going to get traffic to DHCP, DNS, and your wireless LAN controller.
The controller itself manages the access points and clients.
We know that already.
It intercepts the HTTP request, so that HTTP request we initially send out, we stop there
and it redirects to the wireless LAN controller and shoots out that page that you create,
the WebAuth page.
Let's take an example.
I'm sure you guys have all seen this or most of you have at least.
You try and join that hotel network and then immediately you're redirected to the HTTP.
It's got that thing and then it's got the big web page and it says enter your room key
or enter your token or your password and then agree to the usage policy.
That's what the wireless LAN controller is doing in this case.
Then you have the authentication server.
That is very dependent on your configuration.
If I'm just doing consent, I'm not going to see a lot here, but we'll show you both of
those systems.
Now, let's start with the first one.
What does this connection look like with those roles in mind?
We have the client, we have the AP, we have the wireless LAN controller, and there's that
AAA server.
There are roles.
We even talked about the DHCP and DNS.
We're going to go through this process.
First off, our client's going to connect to the web off SSID and it's going to go directly
to that AP.
We're coming out here.
Boom.
The AP responds with, ooh, all right, so somebody's trying to connect to me.
We're going to use that CapWack tunnel to throw this directly here to the DHCP.
Notice I didn't say anywhere else.
It's going to go to the CapWack tunnel, it's going to go to the wireless LAN controller.
They're going to get an IP address from DHCP and there's going to be a DNS in there that's
going to point us to that HTTPS.
This configuration is important.
This is going to assign the IP address to a client.
I know what you're thinking.
I know you're saying, whoa, must be done already.
He has an IP address or she has an IP address and they have DNS access, they must be able
to get the internet.
No, remember the wireless LAN controller is going to stop all other communication.
We're in that CapWack tunnel.
So our traffic is segregated from regular data at this point.
We're going directly to the wireless LAN controller.
We're going to initiate that HTTP session.
So that webpage that says, oh, can the user get in, yes or no, do you sign the acceptable
use policy?
That's what we're sending back.
See, the web auth, we're going to redirect.
That's what we're sending back.
That's really what people are going to see.
Then on that webpage, you have to enter your username or password or if you're using consent,
click yes or no here.
Yes, I agree to the user policy.
Once that's done, it's then sent to that AAA server as a validator and it says, oh, did
they click yes or no?
It says, oh, is that password correct?
Oh, is that username correct?
If it's an okay, then yes, and then you get redirected to your original URL.
That's what's happening behind the scenes.
Now if it's a no, you get shot right back here, okay?
So if you click no or if the password's incorrect, you're going to be sent right back to that
HTTP.
You are not outside of that CapWAP tunnel until you finish this process.
You are dealing directly with that web auth configuration.
So clear the screen a little bit.
What about if we have an external web server that's actually happening here, a more custom
configuration?
Well, really, it just adds this in.
So really, the wireless LAN controller contacts this.
We go through DHCP.
You still get the same thing.
That's the only difference.
Your AAA, RADIUS, or TACAC server still handles the authentication.
Maybe you're not using AAA.
Maybe you're using something else.
Maybe it's just a simple password, a pre-shared key, something of that nature.
If it's a pre-shared key or something of that nature, then it actually goes to the wireless
LAN controller for authentication.
Let's talk about some of these features.
Secure HTTP access, HTTPS.
We do certificate validation, so make sure you rotate this annually or however long it
takes for them to go out.
Remember, certs expire.
So however long your cert's valid for, you need to rotate them.
If not, what your clients are going to see is certification expired, and they're going
to have to accept it.
Some of the Apple products get really funky about this.
If a certificate, even if it's just on your wireless controller, doesn't match, and rightfully
so.
That is a security setting.
So make sure you rotate these annually or you rotate them as needed.
Custom WebAuth login portals, you can create this.
If you have a developer on hand or you're handy enough to do the development yourself,
you can create fancy pages for your organization.
In fact, a lot of the hotels you see have their own custom WebAuth.
That's why we have that server.
Let me roll back.
That's when this comes into play, that external web server.
That's when that comes into play.
Custom web browsers and banners, sometimes you can put a banner on here that says, if
you connect to our network, you consent to our user policy.
That's important.
Or another thing I've seen for web browser banners is no unauthorized users are allowed
on this network.
Please disconnect now.
That can be set up by legal.
That means you could be prosecuted for connecting to that network.
It's like a no trespassing sign, really.
But you can set up custom browsers also letting them know, hey, this is going to go down.
But this is really cool.
This is a CLI configuration.
And then when not configured for the username or password, it's going to appear somewhere
else.
So the custom web browser banners appear when people log on.
But when not configured on username or password, they appear at the login screen.
That's when you're using just consent again.
You can set up custom authentication and proxy web pages and pre-authentication ACLs and
URL filters.
So if you're coming from here, we can go ahead and skip here.
We can put in URL filters to further limit those web auth users on what they can actually
reach.
Remember, this is really used for guest wireless LANs, guest SSIDs.
That's really where you see this the most.
One configuration note that I would note for the exam, when we're dealing with virtual
IP addresses for web auth, this can be IPv4 or 6.
Use only between the controller and the wireless client.
That's only for this virtual IP address.
It redirects the address to the web authentication login page.
We saw that in our configuration.
These are non-routable IP addresses.
That's one thing to note.
And these do not overlap with the network infrastructure addresses.
And these have their own RFC.
What did I say about underlining?
If I underline something, I would know it.
I would know this, these ranges, the 2030113, the 19851100, and the 192020.
They're all slash 24s.
But these are the ones I would know, know this.
All right.
That was the last lesson in our web auth.
We talked about a few things here.
Let me roll back a few slides just so you can get this in your brain.
Take a look at this process again.
Broadcast SSID.
We try and connect to the SSID, assign the IP to the client, goes out to the session,
comes back with the browser, the HTTPS.
This is the yes or no.
This is that web page where you fill out your information, either consent or web auth with
consent, which would mean the username and password.
Those credentials that you entered are sent back to the AAA server or whatever authentication
server is at this point.
Then what happens?
Well, it's either yes or no.
Those match or they don't match.
If it matches, then we go down.
If it doesn't match, we go back up.
Matches applies the access policy, then we can go wherever we want from here.
We are a part of that guest traffic.
Whatever policies we have in place for that, that's what gets applied to the data traffic.
But now we are regular data traffic instead of being in a box.
You are in a box from here to here.
You cannot leave this communication, this internal communication, unless you get that
authentication from that AAA server.
All right, everyone, that wraps up our ENCQOR wireless sections.
That's everything you should know for the exam.
Remember to look in our supplemental learning assets.
I've got two websites there for you to go through.
Know this stuff.
Watch these videos one time through.
Go through those tables, and you should be well prepared for the exam.
Thank you very much.
I enjoy wireless quite a bit, and I enjoy teaching, so I will see you in one of my other
courses.