How to Setup and Deploy Microsoft Endpoint Management and Defender for Endpoint
As part of Microsoft’s (here onwards referred to as “MS”) current corporate Endpoint Management and security architecture lies MS Endpoint Manager, MEM in short (formerly known as Intune) and MS Defender for Endpoint (MDE).
Both solutions are leaders in their segments according to analysts and they support multiple Operating Systems, most notably Linux, Windows, MacOS, iOS and Android. So whatever you need these on, you should be covered.
I set out to learn how to Architect and Deploy these solutions in a Windows Endpoint scenario. A task that can be daunting, but not if done with guidance.
The best part about this is that setting up MEM will allow you to manage Windows and Mobile devices, with security policies and even run compliance checks, later on, leading to conditional access setup in a Zero Trust-enabled environment.
So in short, MEM can be a fundamental piece of end-to-end risk assessment to your architecture.
Disclaimer
1. These are my notes on the subject, by no means deploy these products without consulting the official, relevant documentation first, which are all referenced in this document.
2. This entire article is based in public documentation from Microsoft.
3. Any security changes should always be discussed with relevant stakeholders prior to being put in production. Something discussed by Microsoft here.
I followed many documents, including this one: Plan your Microsoft Defender for Endpoint deployment | Microsoft Docs
Let’s then go over my findings on the subject.
./overview
Deploying these solutions can be time consuming if done from scratch, especially if done to mobile devices such as iOS and Android that require their own certificates for Enterprises.
MEM setup involves enrolling devices , onboarding devices. Simple enough, of course there can be complexities involved such as deploying (and managing) device certificates.
MDE setup can be as simple as three steps.
First, defining the architecture,
Secondly, defining how to deploy. And
Third, setup and push policies.
Naturally, each of these steps have multiple tasks required to achieve them so it’s not that simple. However, it’s good to know them, since they are aimed at making the process simple from a top level perspective.
./prereqs
Before we continue, the prerequesites to configure everything here is to have users licensed for Microsoft 365 E5.
Make sure your users are licensed with E5 by going to admin.microsoft.com then Active users and checking under Licenses.
For users with this licensing tier, you can setup everything discussed following.
MEM
MEM is Microsoft’s Unified Endpoint Management solution which includes Mobile Device Management (MDM) and Mobile Application Management (MAM) capabilities.
We can setup them individually as per required.
Its architecture allows for native integration with MS’s IdP, AAD which is a major advantage when setting it up IMO.
./enrollment
As the documentation states, quotes:
there are several methods to enroll your workforce’s devices. Each method depends on the device’s ownership (personal or corporate), device type (iOS, Windows, Android), and management requirements (resets, affinity, locking).
By default, devices for all platforms are allowed to enroll in Intune. However, you can restrict devices by platform.
Naturally, Windows supports the most enrollment methods:
Without getting into details of each one of these, I will move on using the Auto-enroll method since it suits my use case. About it, the documentation states, quotes:
Automatic enrollment lets users enroll their Windows devices in Intune. To enroll, users add their work account to their personally owned devices or join corporate-owned devices to Azure Active Directory. In the background, the device registers and joins Azure Active Directory. Once registered, the device is managed with Intune.
To setup Auto-Enroll, let’s enable MDM within AAD, open portal.azure.com, find AAD, then on the menu on the left hand side, find Mobility (MDM and MAM) then click on Microsoft Intune on the list on the right hand side.
Next, we’ll be able to define the scope of MDM and MAM. There’s an important note here, If you enable both MDM and MAM for All devices, MAM will take precedence for Windows BYOD and it will cause these devices to not be MDM enrolled and to receive WIP Windows Information Policies if they have been configured. (source)
This means that for my use case, I will need only to enable MDM for all users of my AAD tenant.
note: If you want to deploy to SOME users, have a look at the section “groups” of my guide, below.
In the documentation you can find details on how to use CNAME to simplify enrollment, which I have already setup so I will skip for this guide.
./onboarding
After MDM has been setup, it’s a matter of onboarding or Enrolling the device to MDM, which can be done from the Windows machine.
Official document for reference.
In your Windows device navigate to Settings, then Access Work or School. Follow with the prompts, essentially log into your AAD user account. You’ll have to enroll in an MFA method if you haven’t done so yet.
The device will be registered to your MDM:
Finally, you’ll be able to verify that the device is enrolled from the Client’s perspective, within Windows’ Accounts screen as seen below:
And the Admin can also verify enrollment from endpoint.microsoft.com, under Devices, Overview:
That’s it, MEM is setup for all users in your AAD, Onboarding them into MEM and enrolling devices, which is as easy as adding an account in Windows.
./groupSettings
This is optional in my scenario, but If you wish to deploy MDM to SOME users, create a GROUP with the users you want to test.
To create a group head to endpoint.microsoft.com then Groups, then New group.
Create a group, enter type as Security, enter the group name, for membership type, choose Assigned, then click under Members and choose the people that should be part of this test group.
Now once you are enabling MDM and MAM, you can choose SOME and select this group. Easy.
Next, Let’s setup MDE for users enrolled with MDM.
MDE
Defender for Endpoint is Microsoft’s EDR + EPP + Vulnerability shielding platform. Cloud-managed and Agentless, this solution supports integration with other first-party and third-party platforms. It also acts as the piece connecting to Microsoft 365 defender platform, which serves as the EDR manager.
./architecture
Ok then, to get started, we must define the architecture and scope of the solution.
Four different Architecture types are mentioned in documentations:
- Cloud-native
- Co-management
- On-premise
- Evaluation and local onboarding
The Cloud-native architecture looks like this:
I will be using Cloud-native since I want the simpler and yet the most widely supported method to deploy them.
Just as a footnote, deployment for tests could be a lot simpler with the use of of scripts instead of relying on MEM to deploy MDE — hence removing the need to deploy MEM entirely!
Scripts are also used to deploy MDE policies to Servers.
Here’s a look at the simpler way MDE can be deployed:
./deployment
Secondly, we must define what deployment method we’ll be using.
The supported types are these:
- Microsoft Intune
- Configuration Manager
- Group Policy
- Local script
If my objective did not include an MDM such as MEM, then like I mentioned before, we could simply utilize scripts to deploy Defender to Windows machines. Depending on other platforms, other deployment alternatives would be available.
The following document explains all the supported deployment types of Defender, per Operating System: Plan your Microsoft Defender for Endpoint deployment | Microsoft Docs
I chose to Architect my deployment with MEM since, as you can see in the list from the document, it’s the most widely supported deployment method across different Operating Systems.
In order to deploy MDE to MDM users, we can rely on this document, have a look at page 2.
It details what steps are included in the whole deployment of this solution. I’ve covered the initial part of the deployment (MDM). Now we need to look at deploying Defender for Endpoint.
In a enterprise environment it pays to be aware of advanced networking and proxy settings that might be required prior to deploying it, these are all mentioned in documentation. For my use case though, it’s not relevant as my device is not behind any proxy.
The remaining steps then are:
At this step there are a few endpoint security dashboards that you could be looking at, namely:
- endpoint.microsoft.com
- security.microsoft.com
- securitycenter.windows.com
Securitycenter.windows.com is being replaced by security.microsoft.com soon.
You also need to know that Defender features can be configured from a number of other tools, according to documentation:
- Microsoft Endpoint Manager (which includes Microsoft Intune and Microsoft Endpoint Configuration Manager)
- Group Policy
- PowerShell cmdlets
- Windows Management Instrumentation (WMI)
- Tenant attach
From within MEM you can access Endpoint Security and access all settings above , so no need to jump into a different dashboard other than endpoint.microsoft.com , handy.
Now let’s onboard Defender for Endpoints into Endpoint Manager. There’s a video on how to do it, and how I’ve done is shown below.
In order to onboard devices into Defender we should enable the MEM to Defender integration manually. Here’s how to do it: From securitycenter.windows.com, head to settings, then Advanced Features and then turn on Microsoft Intune Connection.
Alternatively, if you’re deploying MDE via script you can head to security.microsoft.com, settings, Endpoints and onboarding. Choose the OS you’re deploying, windows 10 and 11 in my case, the deployment method, MEM in my case and then download the onboarding package, if you wish. I found that this file was not utilized in my walkthrough.
Park this tab for now, we’ll get back to it soon.
Now let’s add EDR into the Endpoint compliance policies, from within endpoint.microsoft.com still.
When it comes to EDR policies within MEM, we must understand the different policy options.
This document describes them well. Essentially, there are 3 options:
Intune — The following are supported for devices you manage with Intune:
Platform: Windows 10 and later
Profile: Endpoint detection and response (MDM) — Intune deploys the policy to devices in your Azure AD groups.
Platform Windows 10, Windows 11, and Windows Server (Preview)
Profile: Endpoint detection and response (Preview) — Endpoint Manager deploys policy to Azure AD Groups, and distributes it to Microsoft Defender for Endpoint Clients.
Defender for Endpoint — The following are supported for devices that receive security management policy with Microsoft Defender for Endpoint:
Platform Windows 10, Windows 11, and Windows Server (Preview)
Profile: Endpoint detection and response (Preview) — Endpoint Manager deploys policy to Azure AD Groups, and distributes it to Microsoft Defender for Endpoint Clients.
The one I will be using then, is Endpoint detection and response (MDM), which has been slightly modified in the UI as seen below:
When creating the profile you get to choose how much telemetry Defender should be reporting, I’m thinking this will impact the device performance during very intensive IOPS tasks, given experience with this kind of products in the past — though I do lack resources confirming this suspicion or actual performance impact for this EDR, if you are aware and have actual data, please share and I’ll append to this document.
Sometime afterwards, you should see that the first device has been onboarded using MEM, within Defender interface in the same section we had parked, a few steps back:
You can verify that the device was onboarded as expected by navigating to security.microsoft.com , Endpoints — Device inventory and seeing your device listed under Endpoints.
Pro tip:
For the best use of EDR into an informed, zero trust environment, make sure to enable EDR with an acceptable Risk score, under Compliance Settings, Defender for Endpoint and then Machine Risk Score
Once onboarded, it’s a matter of configuring the protection settings, let’s get into that.
./configure
As for the setup of MDE, there are a number of supported features for Windows devices. A complete list can be found in documentation.
There are multiple ways you can setup MDE policies, utilizing GPO and powershell commands are some of them. But for Managed Windows devices I recommend the following setup.
From a configuration perspective within MEM you can setup and use Security baselines, which can be attached to profiles, and these attached to user groups defined by Admin/Policy.
To add/review this, head to endpoint.microsoft.com, then Endpoint Security, Security Baselines and then, Microsoft Defender for Endpoint Baseline.
Once you click on create a new profile
MEM will have a number of settings pre filled for all the supported protection mechanisms of Defender for Endpoint:
Pro tip:
Review Firewall settings carefully, as the default might be restrictive and block network access to your device — especially if you’re relying on a cloud endpoint through RDP :-)
Since this is a demo, I set firewall to Not configured:
The Profile then can be attached to Specific groups or all users and even to all devices, as needed.
After you confirm the settings, the profile will be implemented to the chosen group/user/devices.
Now let’s add a Compliance Profile to MEM, this is what will determine devices’ state to your policies. It will allow you to create conditional access later down the line, which I won’t be covering here.
This is where you can define what’s acceptable in terms of configuration for a device to be compliant in MEM. Settings include Device health (update status) even password settings:
./test
With all that set and done, now we must test the security settings. Let’s run a harmless test, as recommended by Microsoft in the documentation.
It’s a simple test, create a local directory, and run this command from an elevated CMD prompt while in it:
powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference = ‘silentlycontinue’;(New-Object System.Net.WebClient).DownloadFile(‘http://127.0.0.1/1.exe', ‘C:\\test-MDATP-test\\invoice.exe’);Start-Process ‘C:\\test-MDATP-test\\invoice.exe’
A few minutes later you’ll see Defender picked up the event and reported it under Incidents:
So with this we know we configured MEM integrated to Defender for Endpoints, pushed EPP and EDR policies to devices!
Then this is how to configure Defender for Endpoints on Managed Windows devices.
./finalTouches
However, for the purpose of this article, there are key features that I want to put in action, this is following the deployment document, which lists them as Services, under Service Adoption.
The top four items that must be thought of and setup for MDE are, in order of the recommended Service Adoption with descriptions provided by documentation:
- EDR: Endpoint Detection and Response
Defender for Endpoint endpoint detection and response capabilities provide advanced attack detections that are near real-time and actionable. Security analysts can prioritize alerts effectively, gain visibility into the full scope of a breach, and take response actions to remediate threats.
Let’s configure EDR in block mode, a setting recommended for post-breach events for Antivirus. It’s recommended for non Microsoft antivirus antivirus, but it can be turned on with Defender for Endpoint.
Here’s how to to do it:
- TVM: Threat & Vulnerability Management
Threat & Vulnerability Management is a component of Microsoft Defender for Endpoint, and provides both security administrators and security operations teams with unique value, including:
Real-time endpoint detection and response (EDR) insights correlated with endpoint vulnerabilities
Invaluable device vulnerability context during incident investigations
Built-in remediation processes through Microsoft Intune and Microsoft System Center Configuration Manager
No configuration needed, once you onboard devices into M365 Defender, you’ll be able to see vulnerability reports for all devices in the dashboard.
TVM is supported on a number of Windows and Linux OS even Android and iOS devices. For an extensive list of supported OS, refer to documentation.
- NGP: Next Generation Protection
Microsoft Defender Antivirus is a built-in antimalware solution that provides next-generation protection for desktops, portable computers, and servers. Microsoft Defender Antivirus includes:
Cloud-delivered protection for near-instant detection and blocking of new and emerging threats. Along with machine learning and the Intelligent Security Graph, cloud-delivered protection is part of the next-gen technologies that power Microsoft Defender Antivirus.
Always-on scanning using advanced file and process behavior monitoring and other heuristics (also known as “real-time protection”).
Dedicated protection updates based on machine-learning, human and automated big-data analysis, and in-depth threat resistance research.
As stated before, these settings can be configured in multiple ways, I recommended using MEM for windows endpoints. For Servers you might be better off using Scripts.
- ASR: Attack Surface Reduction
Attack surface reduction capabilities in Microsoft Defender for Endpoint help protect the devices and applications in the organization from new and emerging threats.
As stated before, these settings can be configured in multiple ways, I recommended using MEM for windows endpoints. For Servers you might be better off using Scripts.
Thank you for reading and leave your thoughts/comments! Keen to improve this document if you find any inconsistency (as there may be some), leave a note if so!
Learn more about my Cloud and Security Projects:
Listen: bit.ly/cloudnsecspotify
Read: bit.ly/cloudnsecmedium
Watch: bit.ly/cloudnsecyoutube
./references
Scattered Throughout the document.
