Search This Blog

Monday, February 18, 2019

Windows Defender Application Guard

This time let’s give Windows Defender Application Guard a very simple test:

You can test this on a physical client or a Hyper-v client, take a look here for the requirements:

Testing Windows Defender Application Guard on a VM

The test will be done in an enterprise Active Directory domain (Enterprise-managed mode).

First lets create a Group policy (GPO) for Windows Defender Application Guard and apply it to the OU holding our clients.

Go to the following setting:

Computer Configuration\Policies\Administrative Templates\Network\Network Isolation\Enterprise resource domains hosted in the cloud

In the Enterprise cloud resources you can enter a pipe-separated (|) list of domain cloud resources (Trusted domains).

The domains you enter here will be rendered using Microsoft Edge (or Internet Explorer) and won't be accessible from the Application Guard environment.

You can use a leading "." as a wildcard character to trust subdomains. Configuring .mindcore.dk will automatically trust subdomain1.mindcore.dk and subdomain2.mindcore.dk etc.

image

Next go to:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Defender Application Guard\Turn on Windows Defender Application Guard in Enterprise Mode

Enable Windows Defender Application Guard for Microsoft Edge by setting the option 1:

image

Update group policies on the client by running gpupdate /force

image

Lets open Edge and go to https://www.mindcore.dk, since this is a trusted domain the site will open directly on the host PC instead of in Windows Defender Application Guard.

image

Now let try a site not in the trusted list like https://www.microsoft.com this time we will be redirected to the hardware-isolated Edge environment, shown with the icon in the upper left hand corner:

image

Starting Application Guard too quickly after restarting the device might cause it to take a bit longer to load and show you this message. However, subsequent starts should occur without delays.

image

Now lets try the same in Internet Explorer, https://www.mindcore.dk still opens directly in Internet Explorer:

image

www.microsoft.com will again be redirected to the hardware-isolated Edge environment:

image

If you try to copy to or from the Windows Defender Application Guard Edge browser you will see the message:

Your admin doesn’t allow you to copy and paste this content between Application Guard and other apps.

image

Stay tuned on till next time, were we will test some more Windows Defender Application Guard settings.

Wednesday, February 13, 2019

Testing Windows Defender Application Guard on a VM

If you want to test Windows Defender Application Guard your test environment must meet the requirements:

A 64-bit computer with minimum 4 cores (logical processors) with CPU virtualization extension, minimum 8GB RAM and 5 GB free space.

But what if we want to test this on a virtual Windows 10 running on Hyper-v?

When you try to enable Windows Defender Application Guard you might see warnings like these.

Windows Defender Application Guard cannot be installed: The Processor does not have required virtualization capabilities:

image

Windows Defender Application Guard is not supported on this device configuration:

image

But we can still test on hyper-V, let me show a working configuration, you will be able to use lower settings, but it order to test this will work:

Use a Generation 2 VM with at least 4 GB RAM:

image

Use at least 2 virtual processors:

image

I have TPM and secure boot enabled, but it seems to work without, but enabling both will not hurt:

image

Then we need to enable nested virtualization on the VM, with PowerShell on the Hyper-v host:

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

image

Next since we do not fulfill the requirements, let’s lower requirements with use of registry settings as explained in the WDAG FAQ:

https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-guard/faq-wd-app-guard

I have lowered the processor requirement (SpecRequiredProcessorCount) and the memory requirement (SpecRequiredMemoryInGB)

HKLM\software\Microsoft\Hvsi\SpecRequiredMemoryInGB

HKLM\software\Microsoft\Hvsi\SpecRequiredProcessorCount

 image

And now we are able to enable Windows Defender Application Guard:

image

A reboot is required:

image

We are now ready to test, stay tuned for the next article about Windows Defender Application Guard.

Tuesday, February 5, 2019

Office Client Policy Service

Microsoft has made the new Office Client Policy Service available as preview, and this is looking promising.

The solution is a cloud-based service that can enforce policy settings for Office 365 ProPlus on the office client. This is possible even if the device isn’t domain joined or otherwise managed.

The policy settings will be applied to whichever device the user signs into and uses Office 365 ProPlus. The solution includes many of the same user-based policy settings that are available when using Group Policy (GPO).

We need to be aware of the following:

  • Office 365 Proplus must be at least Version 1808.
  • User accounts must be created in or synchronized to Azure Active Directory (AAD). The user must be signed into Office 365 ProPlus with this AAD-based account.
  • A Security group must be created in or synchronized to Azure Active Directory (AAD), with the appropriate users added to the group.
  • To create a policy configuration, you must be assigned one of the following roles in Azure Active Directory (AAD): Global Administrator, Security Administrator, or Desktop Analytics Administrator.
  • Only user-based policy settings are available. Computer-based policy settings aren’t available.
  • Not all user-based policy settings are available. Only user-based policy settings that configure a single value are available currently. Work is being done to make more user-based policy settings available.
  • As new user-based policy settings are made available for Office, the Office client policy service will automatically add them. There is no need to download updated Administrative Templates files (ADMX/ADML).
  • Policy settings from the Office client policy service are stored in the registry under HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud\Office\16.0.
  • Policy settings from Office client policy service take precedence over policy settings implemented by using GPO, and they are taking precedence over preference settings or locally applied policy settings.

When all this in place let give it a quick test-drive:

Lets start by creating a Group in over local AD and let it sync with Azure AD connect.

image

And then add our test user to the group:

image

Let’s start an Azure AD connect sync (PowerShell) to speedup the process:

Start-ADSyncSyncCycle -PolicyType Delta

image

And when we can see the group in Azure Active Directory we are ready to continue:

image

Start my going to:

https://config.office.com/officeSettings/officePolicies

Sign-in with your account, remember that it should be Global Administrator, Security Administrator, or Desktop Analytics Administrator:

image

Accept the license terms:

image

And then create a new policy configuration:

image

Name the policy and the slick on Select Group:

image

Find the group created for this purpose, select it and then click on Configure Policies:

image

Let’s select a policy we can easily se in the UI when it’s applied, here we will select Block the Office Store:

image

After clicking the policy we will set Configured to True, and then close the popup:

image

And finally create the policy by selecting Create:

image

And our policy is now created:

image

Before the policy is applied, let’s take a look at UI in Word, let choose the Insert tab and click Get Add-ins:

image

Here we can see Add-ins available from the Store:

image

After the policy has been applied, no add-ins from the Store are available:

image

You will be able to see in registry when the policy has been applied under HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud\Office\16.0

image

If the user is a member of multiple AAD groups with conflicting policy settings, priority is used to determine which policy setting is applied. The highest priority is applied, with “0” being the highest priority that you can assign.

image

At the date of writing we have 1625 policies available:

image

Office 365 ProPlus will check with the Office client policy service on a regular basis to see if there are any policy configurations for the user. If there are, then the appropriate policy settings are applied and take effect the next time the user opens an Office app.

When a user signs into Office for the first time, a policy check is made. If the user isn't a member of an AAD group that is assigned a policy, then another check is made again in 24 hours.

If the user is a member of an AAD group that is assigned a policy, then the policies are applied and a check is made again in 90 minutes.

Now test it out in your own environment.

Tuesday, January 29, 2019

Enterprise State Roaming

This time I will have a quick test-drive of the Enterprise State Roaming Feature (ESR) with a hybrid Azure AD joined device, for those of us still using our own AD.

Enterprise State Roaming will offer a secure synchronization of user settings from Windows and applications to the cloud.

You can think of it as the modern roaming profiles, but it will not roam existing Windows desktop apps (Win32 apps), in order to roam these settings we need UE-V (preferred before the old roaming profile).

We also need to be aware that Enterprise State Roaming only is available with an Azure AD Premium or Enterprise Mobility + Security (EMS) license.

Azure Active Directory Connect must be setup and configured for Hybrid Azure AD Join and the Service Connection Point (SCP) must be configured (Azure AD Connect will take care of this with the right credentials).

We can use Pass Through Authentication (PTA) or Password Hash Sync (PHS) on managed domains (so for now we forget about federated domains).

image

The automatically SCP setup requires Azure AD connect at version 1.1.819.0 or newer, this will significantly simplify the configuration process.

If you are not synchronizing all OU’s, make sure that the one used for the client is selected:

image

Then for the devices in question we will create a Group policy object, enabling devices to register in Azure AD:

image

This registration will take some time, because we have to wait until Windows 10 has registered and Azure AD connect has synchronized.

On the client you can use the command dsregcmd /status – this will show the current status of the client:

image

In the computer certification store you must also see two new certificates like the ones shown here:

image

In Azure Active Directory – Devices you can se the client and that it is Hybrid Azure AD joined:

image

SCCM can also be used instead of the GPO approach, use client settings:

image

But now the client has hybrid joined we are ready to test Enterprise State Roaming, first we create a test user in the local Active Directory.

When testing Enterprise State Roaming on a managed domain (not federated), it is very important that you use a routable login ID with a valid verified domain, if you use non-routable domains - ESR will not work.

image

You can test with a onmicrosoft.com domain if you add the domain to your Alternative UPN suffixes and use it on the user.

Don’t use mixed case User Principal Name.

image

Let’s start a Azure AD connect  sync to speedup the process:

Start-ADSyncSyncCycle -PolicyType Delta

image

We can see the user In Azure Active Directory – Users when synchronization has occurred:

image

In Azure Active Directory go to Devices - Enterprise State Roaming:

image

We will select the user who should use Enterprise State Roaming, it can of course be a group also a synchronized group from the local AD.

So here we choose Selected and click on No member selected:

image

Select Add members:

image

Select the user in question and click select:

image

Select OK:

image

And finally save the changes:

image

Now lets login to the local domain with our new user:

image

Go to Windows Settings and Accounts:

image

Select Sync your settings and make sure Sync settings is on:

image

Lets do a simple change by moving the taskbar to the left side:

image

Then login on another client with the same user, and watch the change propagate to the second machine within five minutes (ESR in action).

Locking and unlocking the screen (Win + L) can help trigger a sync.

image

Individual sync settings can be disabled by using Group Policy (GPO):

image

GPO in effect:

image

The next question is what data roams?

Windows settings: the PC settings that are built into the Windows operating system. Generally, these are settings that personalize your PC, and they include the following broad categories:

  • Theme, which includes features such as desktop theme and taskbar settings.
  • Internet Explorer settings, including recently opened tabs and favorites.
  • Microsoft Edge browser settings, such as favorites and reading list.
  • Passwords, including Internet passwords, Wi-Fi profiles, and others.
  • Language preferences, which includes settings for keyboard layouts, system language, date and time, and more.
  • Ease of access features, such as high-contrast theme, Narrator, and Magnifier.
  • Other Windows settings, such as mouse settings.

Application data: Universal Windows apps can write settings data to a roaming folder, and any data written to this folder will automatically be synced.

I would be very nice also to see UE-V settings roam to the cloud, but not there yet….

In Azure AD we can see the user’s devices syncing settings, Select Azure Active Directory – Users – Select the user in question – Devices, and select Devices syncing settings and app data

image

Now test in your own environment.