Now that we have given Azure some time to onboard the virtual machine into Azure Security Center (ASC) Standard tierand create the Microsoft Defender ATP tenant, it’s time to check in on what we do and don’t have access to.
First of all, the indicator that we should have MDATP available or will be available shortly is when we see the Log Analytics workspace and the associated ASC solutions deployed in the DefaultResourceGroup-XXX Resource Group.
We can test this out by heading over to securitycenter.microsoft.com to access Microsoft Defender Security Center (MDSC) where we can see that the Azure VM running Windows Server 2016 VM has been enrolled. In the first post of the series I mentioned that WS2016 supports autoenrollment into ASC and MDATP via the Microsoft Monitoring Agent (MMA), so we don’t need to onboard this into MDATP like we would without ASC.
Before we create and enroll our first Windows 10 VM for this environment, we need to take a step back to the Microsoft 365 Business Premium part of the conversation. This means we should be thinking about letting Intune perform the MDATP enrolment rather than running the MDATP onboarding script. This means we should enable the Intune connection in MDSC, and I’ll also enable the Microsoft Secure Score signal forwarding.
Now the flip side, we need to check in MEMAC that the connection with MDATP is enabled, and if this was a production environment you would also enable the MDM Compliance Policy Settings.
We need to apply a policy for device enrolment into MDATP, so we can stay in the Endpoint security settings and create a new policy with Microsoft Defender ATP (Windows 10 Desktop).
The goal here isn’t to configure all the normal settings, it’s just to get enough done to enroll a device. Enable the two Configuration settings.
Normally we would already have created the appropriate groups to target MDATP to, but as this is a fresh tenant with a limited purpose we can just choose All devices, because we are only going to be deploying a Windows 10 VM in our Azure subscription for enrolment purposes.
Review the settings, making sure especially that you are applying this to the correct target group.
Because this is a Microsoft 365 Business Premium subscription that I’m using as the basis for this series, I didn’t need to set the MDM authority because this had been done already, but I thought it was worth dropping this step in just in case you are following along with another subscription type. You can check this under Tenant admin, Tenant status.
Let’s switch gears and run through the final steps for this post, which is to deploy a Windows 10 VM. We get a choice of three different Windows 10 choices from Microsoft in the Azure Marketplace, and either the Windows 10 Preview or Microsoft Windows 10 options are good options for our testing, but let’s stick to a released build so you can test in something closer to most production environments.
Here we get to choose which build, but because this is Microsoft 365 Business Premium you should make sure you choose Pro and not Enterprise. Prior to MDATP becoming available as a standalone option I would have said choose Enterprise, because you would have needed to license Windows 10 Enterprise E5 to get MDATP in an M365BP environment.
There’s nothing to special in the setup, again I’m choosing a fairly low cost VM for testing purposes.
Remember that even though this will deployed into a subscription with ASC Standard applied, and that the Microsoft Monitoring Agent will be installed automatically, this device won’t be automatically be onboarded to MDATP. Remember that we will do this via Intune enrolment.
I’ll finish today’s post here, but before that, you can now turn off or delete the initial Windows Server 2016 VM you used to trigger the MDATP tenant configuration if you need to keep your Azure costs down. I usually prefer to deallocate the VM and switch any of the VM storage away from Premium SSD to Standard HDD just in case I need to bring it back online but while minimizing cost.