In the previous video, we created an identity profile
that lets us leverage Active Directory.
However, it's not too helpful yet because we
haven't associated that with a policy about what
we're allowing or not allowing.
We're going to correct that by creating a new access
policy that gets a little more tougher on what
categories of URLs an individual named Bob is allowed to go to.
So I've just logged into the Web Security Appliance.
This is the My Dashboard page.
And if we scroll down to URL categories,
notice that we have alcohol.
We've got some events or transactions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got some events or transactions
regarding an alcohol website.
So if we wanted to filter that for a certain user,
we could simply create a policy to pull that off.
And to do that, we go to Web Security Manager and then
on the dropdown, we select Access Policies right here.
So this is the default Global Access Policy
that monitors 86 different categories as
of this version of software.
86 different categories based on your URL filtering
and applications--
345, but it's not stopping or denying any traffic by default.
So what we could do is this.
We could modify the global policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We could modify the global policy.
So at our company if we want to say alcohol-related sites,
gaming-related sites, nobody gets there,
we could modify the default-- that'd be great,
or we could create an additional policy
and place it above it that would match on,
for example, a certain group or a certain user
and apply that policy.
And these are processed going top down.
So when there's a match-- for example,
if Bob is matched via authentication,
and then we have a policy that says
he can't go to alcohol websites or alcohol-related categories,
then it would drop his traffic or not allow the traffic.
And even if there was a policy that was more lenient below, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And even if there was a policy that was more lenient below,
once he has a match, that match is executed,
and then Bob at that point is either permitted or denied
based on the policy to that website
that he was trying to reach.
So here's what I propose we do.
Let's create a new policy and we'll
add it before the Global Policy, so it'll catch first.
So we'll click on Add Policy.
And let's call it "NoDrinksForBob."
And what we'll do in this policy is
we'll go ahead and place it above the Global Policy.
That's what we're specifying here.
We can put a description here, and that description
is going to be very helpful later
for us just to remind ourselves and what this policy was for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for us just to remind ourselves and what this policy was for.
"NoDrinksForBob" is pretty clear though in the title there.
And if we scroll down, we can then specify the conditions
for this policy.
So we can say we want to use all identification profiles
or we could choose one or more of the identification profiles
that we've created.
Now at this point in the show, we've
only created one identification profile.
So if we select it here, called "OurProfileOne,"
it would then pull from that.
And then it says All Authenticated Users
or if you want t select just a certain user.
So I click the radio button for just a specific user or group.
And then for users, we'll click on No users entered, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for users, we'll click on No users entered,
and we'll change that.
And I'm going to specify if it's Bob, that would be a match.
And we'll click on Done.
So we're creating this policy called "NoDrinksForBob."
It's going to match using the "OurProfileOne,"
it's going to look for a user specifically called Bob.
Now a great question that we should be asking ourselves
right now, is we just created this policy
and it's going to match on Bob, but it didn't say what
we're going to do about Bob?
Are we going to allow these categories of URLs?
Are we going to deny it?
How do we set that up?
Let me show you that right now. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let me show you that right now.
So now we have this policy called "NoDrinksForBob,"
and by default as far as URL filtering and everything else
across here, it's using the same defaults
as the global policies.
So what we do for this policy click here and we can modify,
we can change the defaults regarding this specific policy.
So this is going to match on Bob,
and then we can also specify the actions
based on that match of what Bob will or will not
be able to reach based on URL filtering
if we modify it right here.
So let's do that.
We'll click here in our policy we just
created under URL filtering and then from here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
created under URL filtering and then from here
we can specify exactly what we want to have in this policy.
So as an example, we'll grab Alcohol.
We've already proven that we can get to a site like that,
and we'll just click on Block right here.
So if this policy matches if it's Bob,
and he's trying to go to an alcohol-related website,
the Web Security Alliance is going
to block him because of this policy
once we save and commit the changes.
So there is a Submit button right here,
which I'm going to go ahead and click.
And then we have a bunch of changes that
have not been committed yet.
In fact, this whole policy itself,
that's "NoDrinksForBob," including WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's "NoDrinksForBob," including
the block on alcohol-related websites-- none of that's
going to be effective until we click on Commit
up here in the upper right.
So we'll click on it and we'll say, "Sorry, Bob," and click
on Commit Changes, and in a moment, that'll be active.
So once this is all done, we get a confirmation message
that it happened, we'll go ahead and test it from both Louis
and also from Bob, and we'll verify
that Louis won't match this first policy because his name
isn't Bob, which is part of the policy, and as a result,
he should be allowed to go ahead and go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
he should be allowed to go ahead and go
to any website in any category.
On the other hand, if we're Bob when we log in,
it'll match on this first policy, and then as a result,
the alcohol-related websites will be blocked.
So let's go and test with Louis first.
So we're open up a browser and we'll
go to fireballwhiskey.com, we'll log in
as Louis, supply the password, press Enter, and away he goes.
All right.
So that was successful.
I'll close that window and let me open a browser again.
Also if there's information that's cached,
you might want to just verify that your cache is
cleared before you do each of these attempts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
cleared before you do each of these attempts.
So we'll go to that site one more time.
This time, we'll log on as Bob.
This is the WSA authentication being done against the Active
Directory server.
Click on Sign In.
Oh my gosh, it's still working.
Why is that?
Oh!
And that looks like it's working.
Hmm, let me go ahead and let me bring up incognito.
So New Incognito Window and we'll try that one more time.
We go to Fireball Whiskey, log in as Bob, authenticate,
click on Sign In, there we go.
That's much better.
And just for fun, let me go ahead and try it with Louis one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And just for fun, let me go ahead and try it with Louis one
more time in incognito mode just to do an apples
to apples comparison here.
So we'll go to Fireball Whiskey again,
I'll log in as Louis, press Enter,
and sure enough, this time no problem whatsoever.
And I'm going to say that Louis is over 18.
So in this video, we've created an access policy
that specifically, if it was Bob based on the matching,
it was going to deny Bob from going to any websites
in the category of alcohol based on the URL filtering.
Now there's more that we can do with access policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now there's more that we can do with access policies.
So let's continue this discussion about what else
we can control and restrict with the Web Security Appliance
in the very next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you
and I'd like to thank you for viewing.