So now that we've created a basic traffic filter,
you get the idea of how that's implemented,
you can control access by source, destination,
protocol, port, port address range, those types of things.
If you want to tie this to an application,
so if you want to get even more granular,
our policy says that anything can RDP to the internal network.
But what if we want to tie that to a very specific application?
So we can do that.
Unfortunately, you're not able to do that in Endpoint Manager.
Let me demonstrate.
So if we go to the Configuration settings and we click Edit
and we go to our Apps and Traffic Rules,
you'll see that there is an Associate apps with this VPN,
and you could choose Associate apps here.
Or if you're using Windows Information Protection,
or WIP, you could do that as well.
However, this doesn't work as you might expect.
This specifies which applications can trigger the VPN connection,
not which applications can access data over an existing connection,
meaning our Always On VPN connection is always on.
And so what we're looking to do is simply add a further
restriction in our existing traffic filter,
so RDP to Internal Network,
and say it can only be all of this would apply only
to a very specific application, and that doesn't exist today,
unfortunately.
So for that, we will have to use XML.
So to implement a traffic filter with an application filter,
you'll actually do that using XML,
and you'll see on your screen here that the code looks almost
identical to the code that we used for the traffic filter except
that we added an App element here.
So we added the App, and then we specified the Id,
and this is pretty obvious what the app ID is.
It's just simply the path to the executable.
Now, this works out well for your traditional Windows,
you know, applications, your Win32 apps.
You know where they are on the disk,
you can specify the full path to the executable,
and you're good to go.
However, if you have Windows Store applications,
then those must be treated a little bit differently.
So for example, if we were using the Remote Desktop Windows Store app,
which is obviously not a, you know, Win32 executable,
then the app ID looks a little bit different,
and you'll see here that it has this kind of interesting‑looking string.
Let me show you where you can find that.
So on our Windows endpoint, I'm going to open up the PowerShell,
and I'm going to run the Get‑AppxPackage PowerShell command.
And if I were to just simply run this command,
I would get a ton of information back.
So I'm going to have to search, and I want to search at the command line.
So I'm going to pipe this to the Where‑Object command, and then I
will specify the search field. In this case,
I want to search in the Name field. Then I will use the ‑like operator because
I'm looking for a specific string in the Name field, and I'm going to search
for the word remote anywhere in the Name field.
And you'll see that we got a return here, so the
name is Microsoft.RemoteDesktop.
And the important thing that we're looking for here is the PackageFamilyName.
The app ID can be a Windows executable like a Win32 app,
but if you're going to use Store apps, you must use the PackageFamilyName.
So when you're creating traffic filters with application restrictions,
then you will also include this string.
So just copy that and paste that into your XML. So I've already loaded
the updated XML on this test client, so let's see how it works. To
begin, I'm going to run Test‑NetConnection,
try to establish a connection on TCP port 3389 to an internal resource.
And here you'll see that TcpTestSucceeded reports False.
And the reason for that is that this application is not the
application defined in the traffic filter.
So although we met all the other requirements,
source, destination, protocols, and ports,
the traffic was not generated by the application we
identified in the traffic filter.
And so in this case, the application is
powershell.exe, so the traffic is denied.
So let's take it one step further, and let's open up the native Windows
Remote Desktop client and see if we can establish an RDP connection. And
as expected and by design, the mstsc.exe,
the native Windows RDP client, cannot connect. Again, it
matches all the other parameters of the rule,
but it is not the correct executable generating the
traffic, so Windows blocks it.
Now let's take a look at what happens when we try to
connect with the authorized client.
In this case, it's that Windows Store Remote Desktop client. And as you can see,
we have a successful connection.
And the reason for that is this is the package family name of
the application that generates the traffic, it matches the
rule, so Windows then allows it.
So in this case, I can allow RDP to the internal network, but tie it to a very specific executable or application.