So to really appreciate the identity firewall and what that brings to the table
,
let's imagine that we have a whole bunch of users that are using these VMs.
Perhaps they're running remote desktop connections to the VMs or they're using
VDI solutions.
And on the back end, let's also imagine all these VMs that they're using are
part of Microsoft Active Directory.
So if that's our scenario, let's imagine that we want to control traffic going
through the network.
We want to allow some traffic, so we'll use the green line here to represent
traffic we want to allow.
And we'll use the red to represent traffic that we want to deny. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll use the red to represent traffic that we want to deny.
Or in the world of NSX, as far as a security policy goes and the rules there,
the options are drop or reject.
So if we have firewall policies that we want to sit up to permit or deny
certain types of traffic based on who's logged on to these VMs,
how exactly are we going to pull that off? Well, the answer to that is if we
are running Active Directory on the back end,
we can actually base these rules in our firewall policies based on Active
Directory group membership.
So let's imagine over here in Active Directory that we have a domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's imagine that domain is NSX demo dot local.
And within that domain, we have a container called users.
And then furthermore, let's imagine inside that container, we have groups and
also users.
Let's also mention that one of our groups, I'll go ahead and use a little icon
for a group here.
Let's mention one of our groups is called yes, meaning in that group, we want
to go ahead and permit certain types of traffic through the network.
And then for everybody else who's not a member of that group, we want to go
ahead and deny it.
So in our firewall policy, this could apply to distributed firewall or a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in our firewall policy, this could apply to distributed firewall or a
gateway firewall.
We could set up some rules. We could say, for example, if the source is a
member of the yes group,
then go ahead and allow the traffic, the traffic we want to permit.
And that could include the ports and protocols and the applications that we're
using.
And it could also include specific IP addresses regarding where we want the
traffic to be allowed.
Then we get a follow up rule that says, if that's not the case, if it's not
matching this certain group as a source,
then we want to go ahead and deny that flow of traffic.
So for a user that's using VDI or remote desk topping into this VM here and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for a user that's using VDI or remote desk topping into this VM here and
logging into active directory as that user,
if they're in that group, they're going to get the permitted access because it
's permitting that in the firewall rule.
And if they're not in that group, they're not going to match on this rule, and
then the traffic is going to be denied based on the second rule right here in
red.
So the cool benefit is that by managing and working with our AD groups,
effectively we're controlling the traffic based on the existing rules, we're
controlling traffic through the network with NSX,
again, based on group membership here in active directory. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me clean that up a little bit and let's chat about the nitty gritty
regarding how in the world does our NSX environment.
How does it know which group a user is a member of?
And the feature set that allows the interaction between NSX and the active
directory environment is referred to as the identity firewall.
So there's a few things involved in that.
Number one, we're going to tell NSX exactly where our active directory is, and
as part of that, we'll specify the LDAP services in active directory
so that NSX knows exactly who to reach out to to determine which users are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so that NSX knows exactly who to reach out to to determine which users are
parts of which groups.
And if this VM right here is part of active directory and the user is using
that VM as part of VDI or the remote desktop to that VM.
And if that VM has the full complement of VMware tools installed on it, this
little VM when that user logs on to active directory,
that specific information about this user on this VM that's now logged into
active directory that gets communicated over to the NSX manager
and that's done via the VMware tools on this VM.
So I'm going to make a little note here that VMware tools is critical for this, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to make a little note here that VMware tools is critical for this,
for the reporting or the informing of an NSX manager regarding
the user who just logged into active directory via this VM.
Now what if we have another segment where we have a physical Windows client
that is also logging into active directory?
So this is the client and this image.
We also have a Windows server here.
If we want to implement our security controls as part of our firewall based on
this physical client,
the problem is this physical client is not running VMware tools and it has no
way to report to the NSX manager because it's not running VMware tools WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
way to report to the NSX manager because it's not running VMware tools
because it's a physical computer.
So the solution there, if we have a physical client, what we're going to do is
we're going to train NSX to go out to the active directory environment
that that client is logging into and we're going to scrape the security logs.
Effectively, that's a fancy way of saying we're going to read the security logs
that include information about who just logged into that computer
and what is their IP address.
So by NSX going to that server and looking at these security logs, that's yet
another way to inform NSX.
So again, whether we have a VM natively with the VMware tools, that's logging WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So again, whether we have a VM natively with the VMware tools, that's logging
into active directory, or we have an external physical client,
that's logging into active directory and we're scraping the security logs
looking for that information.
Both of those options can be used to train NSX for clients that are logging
into active directory.
So with that information in place, what we would then do in NSX is we would
create NSX groups.
And as far as membership in those NSX groups, we could have those dynamically
populated based on active directory groups. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we have nine or 10 users in this specific active directory group that's
included as part of an NSX group,
we could then use that NSX group as part of our security policy rules.
Then these nine users, if they've logged on, will be included effectively in
that NSX group.
And then if we use that as a group as part of our security policy rule, they
can then be permitted or denied based on that security policy rule.
So one of the best ways to really appreciate the integration between active
directory and the groups and NSX using the identity firewall is to actually see
it in action. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So join me in the next video as we put a specific game plan together regarding
what we want to accomplish.
And then with that game plan in place, we'll walk through step by step the
implementation and verification of identity firewall leveraging active
directory.
I'll see you in the next video.
[BLANK_AUDIO]