WEBVTT

1
00:00.000 --> 00:03.560
So we did our verification, we integrated Active Directory,

2
00:03.560 --> 00:08.160
we enabled the DFW and Gateway Firewalls for identity services,

3
00:08.160 --> 00:12.440
and we also created our NSX group that is linked back to our Active Directory

4
00:12.440 --> 00:12.840
group.

5
00:12.840 --> 00:15.500
We also verified that when we looked at that group,

6
00:15.500 --> 00:19.580
it showed the effective member as this little Windows client machine right here

7
00:19.580 --> 00:19.760
.

8
00:19.760 --> 00:22.920
So our next step is to go ahead and take that NSX group,

9
00:22.920 --> 00:25.080
which is using the Active Directory group,

10
00:25.080 --> 00:27.480
and then use it in a firewall policy rule.

11
00:27.480 --> 00:29.560
So for the demonstration, here's what I propose we do.

12
00:29.560 --> 00:32.400
Let's go ahead and modify our distributed firewall policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.560 --> 00:32.400
Let's go ahead and modify our distributed firewall policy.

13
00:32.400 --> 00:35.400
Let's specify that we want to go ahead and first of all,

14
00:35.400 --> 00:38.040
deny SSH for everyone,

15
00:38.040 --> 00:39.680
and then we can test that as well,

16
00:39.680 --> 00:42.320
and then we'll come back in and create another rule above it,

17
00:42.320 --> 00:49.080
permitting SSH if the source is coming from a member of that NSX group,

18
00:49.080 --> 00:51.120
which is linked back to the Active Directory group.

19
00:51.120 --> 00:54.840
Also as a test here, let's also bring in a computer over here.

20
00:54.840 --> 00:56.360
I've got a computer called Mint.

21
00:56.360 --> 00:57.720
20 right here.

22
00:57.720 --> 01:00.240
So at the moment, both this client right here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.720 --> 01:00.240
So at the moment, both this client right here,

23
01:00.240 --> 01:02.400
the Windows client and also this Linux client,

24
01:02.400 --> 01:07.760
they should both be able to do an SSH session up here to the 23.1.2.1 address,

25
01:07.760 --> 01:09.480
which is our little external router.

26
01:09.480 --> 01:12.920
So before we implement our security policy rules and levers the group,

27
01:12.920 --> 01:18.160
let's verify first that we have full SSH connectivity from both these VMs

28
01:18.160 --> 01:21.880
up to the router interface at 23.1.2.1.

29
01:21.880 --> 01:24.440
So to do that, let me make sure all those VMs are running.

30
01:24.440 --> 01:26.040
We'll go to the VM and templates view.

31
01:26.040 --> 01:27.640
So Mint 20 is running.

32
01:27.640 --> 01:29.400
I just want to confirm where it's at.

33
01:29.400 --> 01:30.680
So it's over on segment 20.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:29.400 --> 01:30.680
So it's over on segment 20.

34
01:30.680 --> 01:31.640
Fantastic.

35
01:31.640 --> 01:35.800
And our Windows 11 client is running and it's on segment 10.

36
01:35.800 --> 01:37.960
Let's bring up remote consoles for both of those.

37
01:37.960 --> 01:42.740
So we'll go to Mint 20 and go to summary tab here and click on launch remote

38
01:42.740 --> 01:43.320
console.

39
01:43.320 --> 01:48.840
So here on the Mint 20 device on segment 20, let's bring up a command prompt.

40
01:48.840 --> 01:54.040
And let's do a ping first just to verify connectivity to 23.1.2.1.

41
01:54.040 --> 01:55.240
And that is great.

42
01:55.240 --> 01:59.960
And we'll do a control C and let's do an SSH dash L to log in as VYOS.

43
01:59.960 --> 02:04.040
That's the username up at 23.1.2.1 press enter.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:59.960 --> 02:04.040
That's the username up at 23.1.2.1 press enter.

44
02:04.040 --> 02:04.840
And that's work in.

45
02:04.840 --> 02:06.280
We'll say yes to accept.

46
02:06.280 --> 02:09.240
And then we'll put in the password and we are in.

47
02:09.240 --> 02:12.520
So if we do a who, that shows us who are currently connected as so we're going

48
02:12.520 --> 02:12.760
through

49
02:12.760 --> 02:16.520
that and we appear like we're coming from 23.1.2.60.

50
02:16.520 --> 02:18.920
And our address here is a fudun.io config.

51
02:18.920 --> 02:22.600
Our address here is 10.20.0.153.

52
02:22.600 --> 02:27.240
All right. So SSH works from the Mint 20 VM over on segment 20.

53
02:27.240 --> 02:31.810
And let's also verify that SSH works from our Windows client, which is over on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:27.240 --> 02:31.810
And let's also verify that SSH works from our Windows client, which is over on

54
02:31.810 --> 02:32.680
segment 10.

55
02:32.680 --> 02:35.160
So let's bring up a command prompt on our Windows computer.

56
02:35.160 --> 02:35.720
There it is.

57
02:35.720 --> 02:38.200
And let's do a ping to 23.1.2.1.

58
02:38.200 --> 02:39.320
And that looks great.

59
02:39.320 --> 02:44.760
Let's also do an SSH to that same IP address with SSH space dash L for log in

60
02:44.760 --> 02:46.200
as VYOS.

61
02:46.200 --> 02:52.520
And then the IP address of that router, which is 23.1.2.1. And that looks good.

62
02:52.520 --> 02:55.400
We'll say yes and log in with the password.

63
02:55.400 --> 02:56.200
And that looks good.

64
02:56.200 --> 03:00.920
We'll type in who and we are also being netted to that IP address right there.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:56.200 --> 03:00.920
We'll type in who and we are also being netted to that IP address right there.

65
03:00.920 --> 03:05.160
So if we logged on over here as well and we did that same thing and then we did

66
03:05.160 --> 03:05.720
a who,

67
03:05.720 --> 03:07.160
we're going to have two people logged in.

68
03:07.160 --> 03:10.440
One of them is the Windows computer and the other is the Linux fantastic.

69
03:10.440 --> 03:14.280
So we'll type in exit and we'll exit out of the SSH session for both of them.

70
03:14.280 --> 03:18.440
All right. So now back in the NSX manager, which we'll go to right now,

71
03:18.440 --> 03:24.040
let's create a new security policy rule to deny all SSH traffic if it's going

72
03:24.040 --> 03:25.480
to that external router.

73
03:25.480 --> 03:28.360
So to do that, let's go ahead and use the distributed firewall to implement

74
03:28.360 --> 03:28.920
that.

75
03:28.920 --> 03:30.680
And let's add a new policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:28.920 --> 03:30.680
And let's add a new policy.

76
03:30.680 --> 03:33.320
And let me go ahead and collapse the left hand side.

77
03:33.320 --> 03:37.480
And let's call this new policy, our SSH policy.

78
03:37.480 --> 03:39.800
And then I'll make this column a little bit bigger here.

79
03:39.800 --> 03:40.760
Fantastic.

80
03:40.760 --> 03:45.640
And for this policy, let's create a new rule and let's deny SSH for everyone.

81
03:45.640 --> 03:48.440
So we'll say the source is going to be from anywhere,

82
03:48.440 --> 03:52.600
but for the destination, we'll deny all SSH to that specific IP address

83
03:52.600 --> 03:58.550
of our external router, which is at 23.1.2.1 and press enter and click on apply

84
03:58.550 --> 03:58.840
.

85
03:58.840 --> 04:00.520
All right. So that's the destination.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
03:58.840 --> 04:00.520
All right. So that's the destination.

86
04:00.520 --> 04:06.120
And for the services, let's go ahead and specify just TCP port 22.

87
04:06.120 --> 04:09.640
So we'll type in SSH. They've already got that identified force.

88
04:09.640 --> 04:13.080
So in the services column here, SSH, we're really talking about traffic

89
04:13.080 --> 04:14.040
matching at layer four,

90
04:14.040 --> 04:18.360
the protocol TCP going to the well known port of 22 and we'll click on apply.

91
04:18.360 --> 04:22.500
And then we could also furthermore implement a context profile to make sure it

92
04:22.500 --> 04:23.000
's really the

93
04:23.000 --> 04:26.690
SSH application. But for our demo, this will work just fine with just looking

94
04:26.690 --> 04:27.720
at the layer four port

95
04:27.720 --> 04:31.080
and protocol in use. And then for the action, we'll go ahead and use the drop
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:27.720 --> 04:31.080
and protocol in use. And then for the action, we'll go ahead and use the drop

96
04:31.080 --> 04:32.440
down, say reject,

97
04:32.440 --> 04:36.120
and then we'll click on publish. All right. So that is done. We'll click right

98
04:36.120 --> 04:36.680
here,

99
04:36.680 --> 04:39.960
where it says in progress, we'll click on the refresh. And that looks great.

100
04:39.960 --> 04:44.850
So at this very moment, if this VM tries to do an SSH session here, or if this

101
04:44.850 --> 04:45.080
VM,

102
04:45.080 --> 04:49.320
which is meant 20, tries to do an SSH session, they should both be blocked.

103
04:49.320 --> 04:52.200
And because we're doing it with the distributed firewall, it would be done

104
04:52.200 --> 04:56.840
respectively by host A over here and host B over here, both of which have

105
04:56.840 --> 04:57.400
copies of that

106
04:57.400 --> 05:01.320
distributed firewall. And both would deny that traffic if it was attempting to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
04:57.400 --> 05:01.320
distributed firewall. And both would deny that traffic if it was attempting to

107
05:01.320 --> 05:03.000
go up to that IP

108
05:03.000 --> 05:06.440
address. So while we're here, let's verify that. So this is our Linux client. A

109
05:06.440 --> 05:07.160
moment ago, we were

110
05:07.160 --> 05:11.160
able to SSH and we'll hit the upper key. And now it's saying boom, connection

111
05:11.160 --> 05:12.040
refused.

112
05:12.040 --> 05:15.520
And let's also verify that from the Windows client. So here it is right here.

113
05:15.520 --> 05:16.200
And we'll hit the upper

114
05:16.200 --> 05:22.010
key and try to do SSH and survey says that connection is refused as well. So

115
05:22.010 --> 05:22.680
that's NSX

116
05:22.680 --> 05:26.840
denying that traffic. So if we clicked here on stats, even though it hasn't got

117
05:26.840 --> 05:27.800
to the full 15

118
05:27.800 --> 05:30.630
minutes yet, so we don't have this information right here, it does show us that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
05:27.800 --> 05:30.630
minutes yet, so we don't have this information right here, it does show us that

119
05:30.630 --> 05:31.240
we do have some

120
05:31.240 --> 05:36.490
hit counts over here. So that rule is indeed being hit. Also, that rule is 7144

121
05:36.490 --> 05:37.320
. We could also

122
05:37.320 --> 05:41.400
verify it's being hit by going to plan and troubleshoot. And then on the left

123
05:41.400 --> 05:42.040
hand side,

124
05:42.040 --> 05:46.110
expanding that going down to traffic analysis. And then here in the trace flow

125
05:46.110 --> 05:47.080
tile, clicking on

126
05:47.080 --> 05:50.860
get started. And so for the traffic, we want to go ahead and say we're looking

127
05:50.860 --> 05:52.440
for TCP traffic,

128
05:52.440 --> 05:57.070
going to the world on port of 22, it'll look like a send request initially. And

129
05:57.070 --> 05:57.640
for the VM,

130
05:57.640 --> 06:02.200
let's go ahead and choose the Windows 11 client. And let's go ahead and also
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
05:57.640 --> 06:02.200
let's go ahead and choose the Windows 11 client. And let's go ahead and also

131
06:02.200 --> 06:03.080
for the destination,

132
06:03.080 --> 06:07.000
specify that instead of going to a VM, we're going to an IP address. So use IP

133
06:07.000 --> 06:08.120
Mac, a layer three

134
06:08.120 --> 06:13.570
for IP only, and 23.1.2.1. And then we'll click on trace to go ahead and

135
06:13.570 --> 06:15.240
validate that that traffic

136
06:15.240 --> 06:19.780
is indeed being denied by that rule as part of our distributed firewall policy.

137
06:19.780 --> 06:20.200
So we'll give

138
06:20.200 --> 06:24.330
that a moment to crank that out. And sure enough, so because the Windows client

139
06:24.330 --> 06:25.480
was running on host

140
06:25.480 --> 06:29.940
day, host day saw that traffic looked at the distributed firewall, there was a

141
06:29.940 --> 06:30.600
rule specifically
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:29.940 --> 06:30.600
rule specifically

142
06:30.600 --> 06:35.040
rule 7144. And it matched on that rule. So it denied the traffic. And that was

143
06:35.040 --> 06:35.720
the end of that

144
06:35.720 --> 06:40.190
conversation from that VM's perspective. So next, let's add another rule in

145
06:40.190 --> 06:41.640
front of that one on

146
06:41.640 --> 06:46.140
our distributed firewall that's going to permit the traffic if the client is

147
06:46.140 --> 06:47.560
coming from a member of

148
06:47.560 --> 06:51.440
that NSX group, which is tying back to the active directory group. So with

149
06:51.440 --> 06:52.680
security selected on the

150
06:52.680 --> 06:55.660
left with distributed firewall selected, I'm going to collapse that left hand

151
06:55.660 --> 06:56.360
side to give us a little

152
06:56.360 --> 07:00.510
more room here. And then for our SSH policy, we'll simply go ahead and select
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
06:56.360 --> 07:00.510
more room here. And then for our SSH policy, we'll simply go ahead and select

153
07:00.510 --> 07:02.040
it and we'll add another

154
07:02.040 --> 07:05.850
rule. And we're going to put this rule above the deny. So for the new rule, we

155
07:05.850 --> 07:06.840
'll call it permit

156
07:06.840 --> 07:11.300
SSH. And for conditions for this rule being matched for the source, here's

157
07:11.300 --> 07:12.680
where we're going to specify

158
07:12.680 --> 07:16.650
the source group. So we'll click on the pencil and the sources column here for

159
07:16.650 --> 07:17.240
this rule.

160
07:17.240 --> 07:20.440
And then we're going to select this group right here. Now also, it'd be a great

161
07:20.440 --> 07:21.720
idea just to verify

162
07:21.720 --> 07:25.920
that at this moment that if we click here on view members, that that VM shows

163
07:25.920 --> 07:26.840
up as a member of

164
07:26.840 --> 07:30.690
that group, which it does. And that's due to the group definition, which is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
07:26.840 --> 07:30.690
that group, which it does. And that's due to the group definition, which is

165
07:30.690 --> 07:31.880
tying back to the active

166
07:31.880 --> 07:36.590
directory group called the S two SSH. So that looks great. We'll go ahead and

167
07:36.590 --> 07:37.560
click on close

168
07:37.560 --> 07:41.840
and then click on apply. And then as we continue configuring this rule, we're

169
07:41.840 --> 07:43.080
specifying that traffic

170
07:43.080 --> 07:47.060
is coming from a member of the group called NSX group tide. Let me go ahead and

171
07:47.060 --> 07:47.640
make that a little

172
07:47.640 --> 07:51.130
bit bigger tied to the active directory group. And if the destination is, and I

173
07:51.130 --> 07:52.120
'm going to put that

174
07:52.120 --> 07:56.240
same destination address. So for the destination, I'm going to use IP address

175
07:56.240 --> 07:58.520
and put in 23.1.2.1,

176
07:58.520 --> 08:02.280
and then click on apply. So there's the destination. And then for the service,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
07:58.520 --> 08:02.280
and then click on apply. So there's the destination. And then for the service,

177
08:02.280 --> 08:03.160
I also want to specify

178
08:03.160 --> 08:07.910
we're looking at layer four for TCP going to the well known port of 22. So we

179
08:07.910 --> 08:08.840
'll click on the pencil

180
08:08.840 --> 08:12.620
in the services column, then we'll do a quick filter looking for SSH. There it

181
08:12.620 --> 08:13.400
is right there.

182
08:13.400 --> 08:18.320
TCP going to port 22, click on apply, and let's check our work. So this rule

183
08:18.320 --> 08:20.280
permit SSH matches

184
08:20.280 --> 08:24.760
if the source is in this group, and the destination is this IP address, and the

185
08:24.760 --> 08:25.640
layer four protocol

186
08:25.640 --> 08:30.130
is TCP going to port 22. So we're not going to be using context profiles. We're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
08:25.640 --> 08:30.130
is TCP going to port 22. So we're not going to be using context profiles. We're

187
08:30.130 --> 08:31.000
not looking at the

188
08:31.000 --> 08:33.670
application layer. We're just looking at layer four and the services column

189
08:33.670 --> 08:34.520
here. And then it's

190
08:34.520 --> 08:38.500
applied to artistry to firewall, and it's allowing the traffic. So we'll go

191
08:38.500 --> 08:40.200
ahead and click on publish.

192
08:40.200 --> 08:45.000
And here it says in progress, we'll click on refresh. And that looks good. So

193
08:45.000 --> 08:45.880
let's bring in,

194
08:45.880 --> 08:49.880
first of all, our Linux client, which is not an active directory, and it's also

195
08:49.880 --> 08:50.200
not in that

196
08:50.200 --> 08:55.080
active directory group. Let's verify that from our Linux Mint 20 computer that

197
08:55.080 --> 08:55.800
is still going to

198
08:55.800 --> 08:59.720
match on this rule, which is denying the SSH traffic. So here is our Linux

199
08:59.720 --> 09:00.680
computer. We'll
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
08:59.720 --> 09:00.680
computer. We'll

200
09:00.680 --> 09:05.100
hit the up arrow key and try to SSH connection refused. If we try to ping, for

201
09:05.100 --> 09:07.400
example, 8888,

202
09:07.400 --> 09:10.200
that is being allowed. So that's great. We still have connected to the internet

203
09:10.200 --> 09:11.080
. We're just being

204
09:11.080 --> 09:16.800
blocked on that connection for SSH to 23.1.2.1. Also, we tried to ping 23.1.2.1

205
09:16.800 --> 09:18.040
. That should work

206
09:18.040 --> 09:21.800
because we are not explicitly denying that either. And so that's going all the

207
09:21.800 --> 09:22.440
way through our

208
09:22.440 --> 09:26.440
distributed firewall policy and being permitted by the final rule there. So we

209
09:26.440 --> 09:27.080
'll do control

210
09:27.080 --> 09:31.600
C there. But just to confirm, we cannot SSH. We're still being denied because
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
09:27.080 --> 09:31.600
C there. But just to confirm, we cannot SSH. We're still being denied because

211
09:31.600 --> 09:32.360
we're not a member of

212
09:32.360 --> 09:36.030
that active directory group. So let's minimize that. And let's bring in our

213
09:36.030 --> 09:37.400
Windows client, which,

214
09:37.400 --> 09:40.840
because it's a member of this group, it should match on this rule. And that

215
09:40.840 --> 09:42.040
traffic should be allowed.

216
09:42.040 --> 09:48.160
So here is our Windows client. And just to confirm, let's do an IP config. Sure

217
09:48.160 --> 09:48.440
enough,

218
09:48.440 --> 09:54.040
this is a 10 10 zero one 66. And a moment ago, when we tried our SSH session,

219
09:54.040 --> 09:55.000
it was being denied.

220
09:55.000 --> 09:58.410
But now, because we have the new rule that says, Hey, if you're a member of

221
09:58.410 --> 10:00.040
this group as the source,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
09:58.410 --> 10:00.040
this group as the source,

222
10:00.040 --> 10:04.760
and you're going to this IP address 23.1.2.1, and as TCP port 22, we're going

223
10:04.760 --> 10:05.240
to go ahead and

224
10:05.240 --> 10:08.620
permit it. So we'll press enter. And sure enough, it's asking us to log on to

225
10:08.620 --> 10:09.800
that external router.

226
10:09.800 --> 10:13.720
I'll put in the password there. And we are good to go. So for that rule right

227
10:13.720 --> 10:13.880
there,

228
10:13.880 --> 10:17.470
let me go ahead and scrunch these columns a little bit over. Let's click on

229
10:17.470 --> 10:18.840
stats. So notice here

230
10:18.840 --> 10:23.100
that we have had some traffic that's matched on that rule as shown right here.

231
10:23.100 --> 10:24.200
So in the popularity

232
10:24.200 --> 10:27.650
index and session count, it has numbers here. And again, with the warning that

233
10:27.650 --> 10:28.440
this information

234
10:28.440 --> 10:31.970
may be stale up to 15 minutes as there's aggregation that's done every 15
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

234
10:28.440 --> 10:31.970
may be stale up to 15 minutes as there's aggregation that's done every 15

235
10:31.970 --> 10:33.240
minutes. But we do have hit

236
10:33.240 --> 10:37.440
counts here also to reinforce that that rule is being matched. Another way to

237
10:37.440 --> 10:38.360
test this would be

238
10:38.360 --> 10:42.620
to go ahead and disable that rule that's permitting that traffic will click on

239
10:42.620 --> 10:43.560
publish. And then we'll

240
10:43.560 --> 10:47.000
bring back our windows client. And then right here, if we try that SSH again,

241
10:47.000 --> 10:47.960
now it's going to be

242
10:47.960 --> 10:52.150
reset because that rule that's permitting based on group membership is no

243
10:52.150 --> 10:53.640
longer enabled. So if

244
10:53.640 --> 10:57.610
we enable that rule again, click on publish now permitting that traffic based

245
10:57.610 --> 10:58.920
on group membership,

246
10:58.920 --> 11:01.960
and then bring back our windows client, which is a member of that group and hit
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
10:58.920 --> 11:01.960
and then bring back our windows client, which is a member of that group and hit

247
11:01.960 --> 11:02.600
the upper key

248
11:02.600 --> 11:07.600
and press enter. Now we can log in with SSH, no problem. So let's recap. We

249
11:07.600 --> 11:08.840
verified we have

250
11:08.840 --> 11:13.340
active directory set up. We had a client logging on to active directory. We

251
11:13.340 --> 11:14.520
trained NSX on how to

252
11:14.520 --> 11:18.950
interact with active directory, including the use of LDAP, so that NSX could

253
11:18.950 --> 11:19.880
only know who the

254
11:19.880 --> 11:23.980
users are that are logging in, but also what groups those users are a member of

255
11:23.980 --> 11:25.240
. Then furthermore,

256
11:25.240 --> 11:28.800
we specified for the distributed firewall function and the gateway firewall

257
11:28.800 --> 11:29.240
function

258
11:29.240 --> 11:33.400
that we want both of those to be able to use identity based firewall services.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

258
11:29.240 --> 11:33.400
that we want both of those to be able to use identity based firewall services.

259
11:33.400 --> 11:34.040
And then we created

260
11:34.040 --> 11:37.280
an NSX group that was tied to an active directory group. And then we use that

261
11:37.280 --> 11:38.520
group as part of our

262
11:38.520 --> 11:42.420
firewall rules. In our example, we use it as part of a distributed firewall

263
11:42.420 --> 11:44.040
rule permitting SSH,

264
11:44.040 --> 11:48.130
if the source was a member of the group. Also, it's important to note that we

265
11:48.130 --> 11:49.080
're going to be using

266
11:49.080 --> 11:54.040
the identity based firewall for the source information, not the destination. So

267
11:54.040 --> 11:54.920
maybe in the future at

268
11:54.920 --> 11:58.820
some point, they'll change the way that that's allowed. But currently, when we

269
11:58.820 --> 11:59.720
use identity based

270
11:59.720 --> 12:02.970
services as part of our security policy rules, if we're going to use them, we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

270
11:59.720 --> 12:02.970
services as part of our security policy rules, if we're going to use them, we

271
12:02.970 --> 12:03.880
need to use them as

272
12:03.880 --> 12:09.050
the source and not the destination as part of these security policy rules. Also

273
12:09.050 --> 12:09.640
, now that we've

274
12:09.640 --> 12:14.020
gone through this together, what we'll have to do in the next video is present

275
12:14.020 --> 12:15.000
a scenario where

276
12:15.000 --> 12:19.800
something has gone a little bit wrong, and they're going to call upon you and I

277
12:19.800 --> 12:20.600
to identify what the

278
12:20.600 --> 12:25.670
problem is and fix it regarding identity firewall services. So I'll see you in

279
12:25.670 --> 12:26.760
this video as we

280
12:26.760 --> 12:28.440
validate this knowledge together.