1
00:00:02,040 --> 00:00:04,470
So now that we've created a basic traffic filter,

2
00:00:04,470 --> 00:00:06,420
you get the idea of how that's implemented,

3
00:00:06,420 --> 00:00:09,030
you can control access by source, destination,

4
00:00:09,030 --> 00:00:12,900
protocol, port, port address range, those types of things.

5
00:00:12,900 --> 00:00:16,700
If you want to tie this to an application,

6
00:00:16,700 --> 00:00:18,710
so if you want to get even more granular,

7
00:00:18,710 --> 00:00:22,600
our policy says that anything can RDP to the internal network.

8
00:00:22,600 --> 00:00:25,920
But what if we want to tie that to a very specific application?

9
00:00:25,920 --> 00:00:28,150
So we can do that.

10
00:00:28,150 --> 00:00:30,620
Unfortunately, you're not able to do that in Endpoint Manager.

11
00:00:30,620 --> 00:00:31,540
Let me demonstrate.

12
00:00:31,540 --> 00:00:34,240
So if we go to the Configuration settings and we click Edit

13
00:00:34,240 --> 00:00:36,650
and we go to our Apps and Traffic Rules,

14
00:00:36,650 --> 00:00:41,790
you'll see that there is an Associate apps with this VPN,

15
00:00:41,790 --> 00:00:44,580
and you could choose Associate apps here.

16
00:00:44,580 --> 00:00:46,960
Or if you're using Windows Information Protection,

17
00:00:46,960 --> 00:00:48,510
or WIP, you could do that as well.

18
00:00:48,510 --> 00:00:51,690
However, this doesn't work as you might expect.

19
00:00:51,690 --> 00:00:57,440
This specifies which applications can trigger the VPN connection,

20
00:00:57,440 --> 00:01:01,930
not which applications can access data over an existing connection,

21
00:01:01,930 --> 00:01:04,990
meaning our Always On VPN connection is always on.

22
00:01:04,990 --> 00:01:08,910
And so what we're looking to do is simply add a further

23
00:01:08,910 --> 00:01:12,590
restriction in our existing traffic filter,

24
00:01:12,590 --> 00:01:14,690
so RDP to Internal Network,

25
00:01:14,690 --> 00:01:18,290
and say it can only be all of this would apply only

26
00:01:18,290 --> 00:01:22,580
to a very specific application, and that doesn't exist today,

27
00:01:22,580 --> 00:01:23,460
unfortunately.

28
00:01:23,460 --> 00:01:27,140
So for that, we will have to use XML.

29
00:01:27,140 --> 00:01:30,770
So to implement a traffic filter with an application filter,

30
00:01:30,770 --> 00:01:32,890
you'll actually do that using XML,

31
00:01:32,890 --> 00:01:36,650
and you'll see on your screen here that the code looks almost

32
00:01:36,650 --> 00:01:39,640
identical to the code that we used for the traffic filter except

33
00:01:39,640 --> 00:01:42,390
that we added an App element here.

34
00:01:42,390 --> 00:01:46,540
So we added the App, and then we specified the Id,

35
00:01:46,540 --> 00:01:49,120
and this is pretty obvious what the app ID is.

36
00:01:49,120 --> 00:01:52,640
It's just simply the path to the executable.

37
00:01:52,640 --> 00:01:56,810
Now, this works out well for your traditional Windows,

38
00:01:56,810 --> 00:01:59,680
you know, applications, your Win32 apps.

39
00:01:59,680 --> 00:02:01,710
You know where they are on the disk,

40
00:02:01,710 --> 00:02:04,430
you can specify the full path to the executable,

41
00:02:04,430 --> 00:02:05,360
and you're good to go.

42
00:02:05,360 --> 00:02:09,150
However, if you have Windows Store applications,

43
00:02:09,150 --> 00:02:12,040
then those must be treated a little bit differently.

44
00:02:12,040 --> 00:02:18,080
So for example, if we were using the Remote Desktop Windows Store app,

45
00:02:18,080 --> 00:02:21,550
which is obviously not a, you know, Win32 executable,

46
00:02:21,550 --> 00:02:23,650
then the app ID looks a little bit different,

47
00:02:23,650 --> 00:02:27,890
and you'll see here that it has this kind of interesting‑looking string.

48
00:02:27,890 --> 00:02:32,440
Let me show you where you can find that.

49
00:02:32,440 --> 00:02:35,670
So on our Windows endpoint, I'm going to open up the PowerShell,

50
00:02:35,670 --> 00:02:40,240
and I'm going to run the Get‑AppxPackage PowerShell command.

51
00:02:40,240 --> 00:02:42,660
And if I were to just simply run this command,

52
00:02:42,660 --> 00:02:44,500
I would get a ton of information back.

53
00:02:44,500 --> 00:02:47,730
So I'm going to have to search, and I want to search at the command line.

54
00:02:47,730 --> 00:02:51,390
So I'm going to pipe this to the Where‑Object command, and then I

55
00:02:51,390 --> 00:02:53,420
will specify the search field. In this case,

56
00:02:53,420 --> 00:02:58,050
I want to search in the Name field. Then I will use the ‑like operator because

57
00:02:58,050 --> 00:03:01,950
I'm looking for a specific string in the Name field, and I'm going to search

58
00:03:01,950 --> 00:03:06,140
for the word remote anywhere in the Name field.

59
00:03:06,140 --> 00:03:08,670
And you'll see that we got a return here, so the

60
00:03:08,670 --> 00:03:11,260
name is Microsoft.RemoteDesktop.

61
00:03:11,260 --> 00:03:15,840
And the important thing that we're looking for here is the PackageFamilyName.

62
00:03:15,840 --> 00:03:20,670
The app ID can be a Windows executable like a Win32 app,

63
00:03:20,670 --> 00:03:24,610
but if you're going to use Store apps, you must use the PackageFamilyName.

64
00:03:24,610 --> 00:03:28,640
So when you're creating traffic filters with application restrictions,

65
00:03:28,640 --> 00:03:31,340
then you will also include this string.

66
00:03:31,340 --> 00:03:35,610
So just copy that and paste that into your XML. So I've already loaded

67
00:03:35,610 --> 00:03:39,910
the updated XML on this test client, so let's see how it works. To

68
00:03:39,910 --> 00:03:41,620
begin, I'm going to run Test‑NetConnection,

69
00:03:41,620 --> 00:03:46,450
try to establish a connection on TCP port 3389 to an internal resource.

70
00:03:46,450 --> 00:03:54,240
And here you'll see that TcpTestSucceeded reports False.

71
00:03:54,240 --> 00:03:58,270
And the reason for that is that this application is not the

72
00:03:58,270 --> 00:04:00,260
application defined in the traffic filter.

73
00:04:00,260 --> 00:04:02,830
So although we met all the other requirements,

74
00:04:02,830 --> 00:04:05,540
source, destination, protocols, and ports,

75
00:04:05,540 --> 00:04:08,650
the traffic was not generated by the application we

76
00:04:08,650 --> 00:04:10,980
identified in the traffic filter.

77
00:04:10,980 --> 00:04:12,820
And so in this case, the application is

78
00:04:12,820 --> 00:04:16,190
powershell.exe, so the traffic is denied.

79
00:04:16,190 --> 00:04:21,070
So let's take it one step further, and let's open up the native Windows

80
00:04:21,070 --> 00:04:29,640
Remote Desktop client and see if we can establish an RDP connection. And

81
00:04:29,640 --> 00:04:33,430
as expected and by design, the mstsc.exe,

82
00:04:33,430 --> 00:04:37,150
the native Windows RDP client, cannot connect. Again, it

83
00:04:37,150 --> 00:04:39,180
matches all the other parameters of the rule,

84
00:04:39,180 --> 00:04:41,820
but it is not the correct executable generating the

85
00:04:41,820 --> 00:04:43,730
traffic, so Windows blocks it.

86
00:04:43,730 --> 00:04:45,620
Now let's take a look at what happens when we try to

87
00:04:45,620 --> 00:04:47,400
connect with the authorized client.

88
00:04:47,400 --> 00:04:57,530
In this case, it's that Windows Store Remote Desktop client. And as you can see,

89
00:04:57,530 --> 00:04:58,940
we have a successful connection.

90
00:04:58,940 --> 00:05:03,620
And the reason for that is this is the package family name of

91
00:05:03,620 --> 00:05:06,340
the application that generates the traffic, it matches the

92
00:05:06,340 --> 00:05:08,880
rule, so Windows then allows it.

93
00:05:08,880 --> 00:05:19,000
So in this case, I can allow RDP to the internal network, but tie it to a very specific executable or application.