Once I had solved my recent Windows Defender Application Guard (WDAG) problems:

Resolving Windows Defender Application Guard Issues

I now wanted to get it working in a manner that suited me. That meant that I wanted Microsoft Edge to work normally for things like Microsoft 365, Azure and other Microsoft sites but to automatically open Edge with WDAG if I ventured outside that. I also wanted to retain the flexibility to have a third party browser (Brave) also working on my machines. In essence, I am trying to achieve the ability to automatically ‘sandbox’ general internet browsing from work in the Microsoft Cloud as way of protecting the workstation from malicious web sites.

I’m not going to cover off setting up WDAG on your machine or via Intune because there are plenty of articles out there that show you how to enable it. You can start here:

Windows Defender Application Guard Overview

In essence, WDAG opens a defined set of URLs in a sandboxed version of Edge automatically. This means you’ll need to do a little configuration and add some features to your local version of Windows prior to getting it working. You can read about that here:

Prepare to install Windows Defender Application Guard

My configuration will be in Enterprise-managed mode. This means that I can automatically ‘white-list’ domains that I don’t want WDAG to operate with via a policy pushed from the Internet. In my case, these will be Microsoft Cloud URLs like http://www.office.com, portal.office.com and so on. Everything, apart from what I ‘white list’ I want to open using WDAG for protection.

The first thing to note here is that if you want to use Enterprise-managed mode you will need to have Windows 10 Enterprise edition. Windows 10 Pro edition only supports stand alone mode. This means:

In this mode, you must install Application Guard and then the employee must manually start Microsoft Edge in Application Guard while browsing untrusted sites.

To do this manually, you must edit the local computer policy using the local Group Policy editor or like as shown here:

Application Guard in stand alone mode

It is pretty easy to set up and get working but not really scalable. Scripting may help overcome that.

In Enterprise-mode my initial questions was ‘Where do I define my sites?’. As it turns out, this isn’t particularly obvious, so it took me a while to track down. The definitions for the sites you want to ‘white list’ for WDAG are actually in the Intune App Protection policy settings.

Turns out they are in the Advanced settings of your Intune App Protection policy, as shown above.

I had wrestled with these settings previously, which I detailed here:

Intune App Protection Policy blocking browser

What I didn’t appreciate initially was that sites you define here however ALSO APPLY to WDAG! Makes sense now that I look at it, but I certainly didn’t think it was the place I should be looking to ‘white list’ sites for WDAG. Now you too are the wiser.

Another subtle configuration option that took me a while to figure out was:

Network isolation wildcards

Initially, I had portal.office.com white listed from WDAG but in fact the navigation was going to http://www.office.com, which means WDAG would trigger and open http://www.office.com because it wasn’t ‘white listed’. Then I thought *.office.com would work, but no. Maybe office.com? Nope. Turns out what I needed was

..office.com

which:

Trust all levels of the domain hierarchy that are to the left of the dot. Matching sites include shop.contoso.com, us.shop.contoso.com, http://www.us.shop.contoso.com, but NOT contoso.com itself.

So be super careful with how you configure you network perimeter settings and domain wildcards as it can make things very confusing if you don’t have a good handle on it. My suggestion is to start with only one or two sites in your network perimeter and ensure that they work. Only then scale up once you have verified it is operating as expected.

Finally, with all that configured correctly, WDGA was working as expected. Yeah! This meant that when I went to a Microsoft Cloud URLs like http://www.office.com, portal.azure.com, etc. WDGA wasn’t activated, but if I went elsewhere, WDGA launched and navigated to that site in the WDAG container. In the end I also white listed sites like bing.com, docs.microsoft.com, etc as I go there many times a day.

If you browse to a non ‘white listed’ site (here www.ciaopsacademy.com), then a WDAG session is launched. You’ll see WDAG spin up, if it is the very first time it has been activated. You’ll then see the browser load the site in question and then you’ll notice a WDAG icon in the toolbar as shown above, which, when opened, will let you know that the current browser is using WDAG.

You configure WDAG settings via Intune Endpoint protection policies as shown above.

My suggestion would be to enable the option to Retain user generated browser data as shown above.  This means things like extensions, session cookies and the like will be retained between sessions. However, if you want a totally clean experience each time, then disable that option.

By default, you’ll find that any file you download while WDAG is active, will be saved into an Untrusted files folder as shown above.

You can also get a WDAG companion app from the Windows store:

https://www.microsoft.com/en-au/p/windows-defender-application-guard-companion/9n8gnlc8z9c8#activetab=pivot:overviewtab

This allows you to manually launch a WDAG session, which is probably handy if you are not using Enterprise-managed mode. It will launch this is a container isolated from anything that automatically launches via your browsing, keeping that separate as well.

If you want non Microsoft browsers to also be protected with WDAG then you’ll find plugins available:

for Chrome

for Firefox

With these plug ins installed, those browsers will also only open non-whitelisted sites. Anything else will be opened in an Edge WDAG session for protection.

So now I have WDAG working the way I wanted. My main stumbling block was no appreciating that the WDAG ‘white list’ was the same as WIP and set via Intune App Protection policies. I now have a better appreciation for the breath of the settings in these policies.

I’m sure I’ll be tweaking WDAG along the way but I feel much more secure in the fact that I have it working and protecting my ‘random browsing’. Like most security configurations, WDAG takes a little bit of understanding and setup to get working but the end result is a much safer environment to work in and I’m all for that. Hopefully you are too!