brianbenavidez
Contributor
Contributor

WDAC Policies with WS1 UEM

Jump to solution

Is it possible to implement Windows Defender Application Control (WDAC) policies through Workspace ONE UEM? I see the Application Control payload under Windows Restrictions but it says it's for AppLocker configuration files. Searching for WDAC in the payload search returns Application Control so perhaps this can receive WDAC XML policies, too?

Labels (2)
0 Kudos
1 Solution

Accepted Solutions
ArsenBandurian
VMware Employee
VMware Employee

Hi.

You can implement WDAC policies via WS1 UEM.

However, there is no "nice" UI for that currently - you will need to implement a Custom Settings payload in your Win10 profile.

1. Read the docs at https://docs.microsoft.com/en-us/windows/client-management/mdm/applicationcontrol-csp

2. The https://www.vmwarepolicybuilder.com/​ tool will help you build XML, so you don't have to do it all by yourself

The Application Control payload is for AppLocker only.

We hope to make the WIn10 management UI better in the future, but there's just to many options and ways of using them...

Hope this helps. If it does - please mark it as an answer for others and maybe share your XML sample.

View solution in original post

5 Replies
ArsenBandurian
VMware Employee
VMware Employee

Hi.

You can implement WDAC policies via WS1 UEM.

However, there is no "nice" UI for that currently - you will need to implement a Custom Settings payload in your Win10 profile.

1. Read the docs at https://docs.microsoft.com/en-us/windows/client-management/mdm/applicationcontrol-csp

2. The https://www.vmwarepolicybuilder.com/​ tool will help you build XML, so you don't have to do it all by yourself

The Application Control payload is for AppLocker only.

We hope to make the WIn10 management UI better in the future, but there's just to many options and ways of using them...

Hope this helps. If it does - please mark it as an answer for others and maybe share your XML sample.

View solution in original post

brianbenavidez
Contributor
Contributor

Thanks, Arsen. The Custom Settings payload with ./Vendor/MSFT/ApplicationControl/Policies/{GUID}/Policy as the LocURI and the WDAC binary created from ConvertFrom-CIPolicy and converted to base 64 in the Data field works. However, how does VMware suggest users update WDAC policies? I can think of 3 ways this can be done, only one of which seems to work in practice:

Replace CSP: Create a Custom Settings Profile and put the Replace CSP in the install settings section whose data payload is the updated policy but with the same policy ID. In other words, change a given policy without changing its ID (this is the only way the Replace CSP would work), compile, and send to the device with the Replace CSP using a temporary profile. Then, delete the temporary profile (deleting doesn't cause the underlying Custom Settings’ remove command to trigger). Now, since the old policy is still in the original Profile, it's Add CSP needs to be changed to the new policy for any new devices that get it installed. Doing this triggers the install command which causes all sorts of problems on the device, presumably because it's already installed. So this doesn't seem to be a viable solution.

Remove CSP and Add CSP, same policy ID: Manually trigger the remove command by removing the profile from the device. In order for this to work, the device needs to be restarted (Windows supports no-restart Adds, but not no-restart Deletes for WDAC policies). This causes an issue because this doesn't also send a notification to the device to restart so there's no saying when it will be restarted. This means that you can't then update the profile with the updated policy (same ID) because Windows thinks it's still installed and it will error out (just like the issue above). So this doesn't seem to be a viable solution, either.

Remove CSP and Add CSP, new policy ID: Manually trigger a remove command by removing the profile from the device. Create a new profile with the updated policy but this time ensure the updated policy has a unique ID. Add the new profile to the device. This will allow us to prevent blocking any new or changed software that would otherwise be blocked by the old policy. However, if we are updating a policy in order to block something, we would need to explicitly deny it in the new policy (I think this would work, I haven’t tried it yet) because the old policy would still allow it until the device restarts at some point. This works, but isn’t ideal.

Ideally, we would have the ability to send Replace CSPs for currently installed policies while also updating the relevant profile’s install settings without automatically sending an Add CSP.

0 Kudos
kaamir
VMware Employee
VMware Employee

There is also this video on YouTube which walks through App Locker policy: Link

Another option is Carbon Black App Control which goes deeper into App Control policies but this is a separate solution. You can read more about it here.

AK
brianbenavidez
Contributor
Contributor

Kaamir, thank you for the fast response. I have successfully used AppLocker to control apps using Workspace ONE UEM; however, my goal is to protect against malware and persistent threats. Unfortunately, AppLocker is not intended to be a security solution according to Microsoft. That being said, does VMware intend to provide robust support for WDAC through UEM or is Carbon Black meant to cover this area in VMware's device management portfolio?

0 Kudos
kaamir
VMware Employee
VMware Employee

I would recommend taking a look at Carbon Black solutions for advanced threat protection: 1) CB App Control (Previously CB Protect) & 2) Carbon Black Cloud Endpoint. While App Control would give you levels of application controls, the CB Cloud Endpoint solution will offer threat protection, live audit & remediation, Behavioural EDR. Carbon Black is also part of Workspace One Trust network & integrates with Workspace One Intelligence thereby complementing WS1 UEM.

AK