I had a few folks recently approach me on the MacAdmins slack asking for help with deploying Microsoft Defender ATP for Mac. We got it working, but it came down to 2 issues: conflicting documentation and Jamf/inTune specific templates. Once I was able to parse through the Jamf/InTune documentation, we were able to put together some guidance. We recently published this guide to the EUC Samples GitHub Repository.
The initial problem I found was some confusion generated by Microsoft’s documentation. The first article, Set Preferences for Microsoft Defender ATP referenced a payloadType of
com.microsoft.wdav. These preferences seem related to the UI and various configuration settings. In other words, it controls what changes can be made in the UI if opened by the end-user.
The second article, JAMF-based deployment for Microsoft Defender ATP for Mac, referenced a payloadType of
com.microsoft.wdav.atp. This “MDM Deployment” specific article only mentions the profile downloaded as part of the Onboarding package. This specific profile looks geared towards licensing and linking the Defender ATP to your specific tenant in the threat protection cloud for telemetry.
For anyone uninitiated, the payloadType in a configuration profile is essentially the key that tells macOS to which preference domain the key-value pairs apply. As such, you’ll usually find the payloadType relates to a payloadType.plist file somewhere in
/Library/Managed Preferences (or `~/Library/Managed Preferences). Initially, I found it odd that the Defender client would be reading TWO separate preference domains. Also, neither article made mention of the other as a complete “story” for managing the client.
Don’t forget to grant Terminal.app permissions in the Security & Privacy preferences to validate the payloadType.plist in one of the two Managed Preferences locations.
Jamf and inTune Specifics
The Deployment with a different MDM system article left a lot to be desired. I find that in this instance, the Jamf-specific deployment information provided the specific detail required for us to put together an appropriate plan. Much of the guidance in that article also applies to Workspace ONE UEM, but with some slightly different terminology:
Jamf Policies = Profiles in Workspace ONE Parlance
In Workspace ONE UEM, you need only click Add > Profile in the top right corner, and build a macOS Device profile. While we typically suggest only a single payload per profile, in this instance, you need multiple payloads for a single app. Since none of the settings you’ll be managing should conflict with other similar payloads, I would suggest creating a single profile with the following two payloads:
- The Custom Settings payload for
- The Custom Settings payload for
I would then suggest creating separate profiles with each individual payload as follows (or add the information to a pre-existing profile containing the specific payload):
- The Kernel Extension payload whitelisting the Team ID:
- The Privacy Preferences payload granting
com.microsoft.wdavthe SystemPolicyAllFiles entitlement
With regards to the Notification Settings payload, I recommend testing this setting with other apps in your environment generating notifications. In my experience, some apps in some versions of macOS have shown unintended behaviors when managing notification settings via MDM.
As you go to build the Custom Settings payloads, it’s important to note that Workspace ONE UEM expects ONLY the payloadType dictionary (e.g.
<dict>...</dict>) and not the full mobileconfig profile with the Configuration wrapper. What this means is you’ll need to trim down the content of the payload to make it work in Workspace ONE. I cover some of these basics in the Custom XML Payloads document on the EUC-Samples github repo.
When adding multiple custom settings to a profile, use the plus sign (+) to add additional custom settings payloads. DO NOT paste multiple custom settings payloadType dictionaries (…) in the same text box (e.g. a single payload).
Jamf Packages = Internal Apps in Workspace ONE Parlance
To deliver the
wdav.pkg file to devices, you should parse it with the VMware AirWatch Admin Assistant app. You can then upload the package and plist as an internal macOS application. Next, paste the uninstall script in the uninstall script textbox for the Internal app.
In my experience, you can distill documentation meant for a different MDM or UEM vendor into a valid, workable solution for Workspace ONE. Also, when you find documentation that is confusing or incomplete, don’t hesitate to file feedback!