Manage Defender for Endpoint for Windows, macOS, and Linux via Security settings management
Recently Microsoft announced a couple of new improvements related to the new security settings management for Windows, macOS, and Linux as part of Defender for Endpoint. In the past years, there was always a bit of a cap between the usage of Defender for Endpoint via the Microsoft 365 Defender portal and deployment of the policies (Defender AV/ Firewall/ Attack Surface Reduction) and more. With the newly released features, there is more simplified and unified management possible between IT and security and more important; visibility in the configured settings from a security point of view.
Blog published: July 18, 2023
Blog latest updated: July 18, 2023
Microsoft announced last year (public preview since late 2021) the availability of the new settings management capabilities also known as MDE Attach/ Security Management for Microsoft Defender for Endpoint. With the new release, the solution is changed and improved.
In the old situation, it was required to register devices fully to Azure AD (AADJ/ HAADJ). With the requirement of Azure AD join it was required to setup Azure AD connect/ change sync rules and sync server objects to the Azure tenant where MDE is located. For “only” deploying and managing Defender for Endpoint it was way too complex, another downside was the limited scope of only Windows 10/11 and Windows Server.
Now the good news; Microsoft has listened and collected all the feedback and improved the flow with new improvements. I have been involved from the start of the development; after many feedback sessions and preview releases, the new solution is way more flexible and future-proof.
What is changed? With the new solution, Microsoft changed the management capabilities and launched a new simplified device onboarding. The full Azure AD join requirement is no longer needed, it can be managed now without joining machines with Azure AD. So no longer changes in Azure AD connect/ sync rules and complexity across domains when one single MDE instance and Azure AD are used.
The new solution is not only supported for Windows 10/11/ Windows Server. Microsoft expanded the scope to macOS and Linux devices and all without the need to join Azure AD or Intune via the normal flow. So now we are finally able to manage Defender for Endpoint via Microsoft 365 Defender for macOS/ Windows and Linux. Sounds cool right – let’s deep dive further into the new solution.
In general with the new feature Microsoft released the following capabilities:
- Simplified device onboarding (Removal of Azure Active Directory hybrid join)
- Native security settings management in Defender for Endpoint
- Create policies directly from Microsoft 365 Defender portal
- Visibility in Microsoft 365 Defender portal in all settings
- Policies synced automatically between Microsoft 365 Defender and Intune
- Applied policies visible via device page
|Important: The new feature is released as part of the public preview. Ensure you have preview features enabled in Microsoft 365 Defender to use Native Security Settings Management for Microsoft Defender for Endpoint.|
What is the best management method?
After the onboarding of Defender for Endpoint via Intune/ GPO or any other solution you need to manage the AV policies. Currently, there are a couple of solutions available for managing Defender AV settings:
- MECM (Endpoint Protection site role)
- MECM via Tenant Attach
- MECM via Co-Management
- Azure Automanage/ DSC
- MDE security settings management
- Not configuring any AV settings (-;
Since the native security settings management integration is based on the Intune mechanism the following is recommended for each type:
Machines Intune joined
When endpoint machines (Windows 10, 11, macOS) are part of Intune it is recommended to use the native capabilities of Intune. Since the device is fully managed by Intune there is no need to use the new MDE setting management feature. When using Intune there are more features available like compliance policies/ custom settings and security baselines. MDE security settings management detects the management state of Intune; and follows the Intune flow when the device is part of Intune.
Machines part of MECM via Co-Management
When machines are part of MECM and synced via Co-Management with Intune it is still using Intune natively. With the workload enablement, there is no need to use the new MDE setting management features – since it is using Intune natively.
Good to know; Co-Management is not available for servers and is only supported for Windows clients.
Machines without Intune
Interesting is the situation where machines are part of domain/ MECM only or without any management and managed via PowerShell script. A good example is machines hosted in Azure/ AWS without any domain or management method. For those machines it is recommended to use the new MDE security setting management feature – this makes it able to use the Intune backend for managing AV settings, without the requirement to join machines completely to Intune.
If a device does not already have an Azure AD identity, the Security settings management will use the lightweight, synthetic mechanism to create the device identity in Azure AD.
With the centralized approach, this is a good solution for managing “unmanaged” machines which are previously managed via PowerShell/ GPO/ MECM/ Ansible/ Yamf or other management solutions and keeping the management as part of the security team included and visible from one single view.
Security settings management
When you use Microsoft Defender for Endpoint, you can deploy policies from Microsoft Intune/ Microsoft 365 Defender to manage the Defender security settings on all devices that are onboarded without the need to enroll those devices directly with Intune. Following the Microsoft docs this feature is called; Defender for Endpoint security settings configuration aka security settings management
For all prerequisites read the following docs: Manage Microsoft Defender for Endpoint on devices with Microsoft Intune
When using the new security management feature it is needed to have Defender for Endpoint licensed. An MDE subscription gives access to the Endpoint security node in Microsoft Intune – when managing devices via security settings management it is not needed to buy an Intune license for using the security settings management.
The new security management feature is supported for the following platforms:
|Important: For Windows it is recommended to update the latest available patches and update the Defender AV platform version to the latest released version. When all patches are installed the solutions work fine and the new preview release is working.|
- Red Hat Enterprise Linux 7.2 or higher
- CentOS 7.2 or higher
- Ubuntu 16.04 LTS or higher LTS
- Debian 9 or higher
- SUSE Linux Enterprise Server 12 or higher
- Oracle Linux 7.2 or higher
- Amazon Linux 2
- Fedora 33 or higher
For Linux good to know the installed MDE version must be version 101.98.84 or later.
- Windows 10 Professional/ Enterprise
- Windows 11 Professional/ Enterprise
For down-level servers make sure the Sense version is 10.8295.22621.1023 or higher.
- Windows Server 2012R2/ 2016 with the unified agent (MMA is not supported)
- Windows Server 2019
- Windows Server 2022
- macOS 13 (Ventura)
- macOS 12 (Monterey)
- macOS 11 (Big Sur)
What happens when we have non-persistent desktops like VDI/ Azure Virtual Desktops?
It is not recommended to use the Security settings management for non-persistent desktops, since all the objects will be created and it is hard to map the Azure AD object. For non-persistent desktops, it is recommended to use other methods and configure it directly in the image to make sure the session is protected from the first launch.
Are there unsupported systems?
Currently, the following devices are not supported:
- Domain controllers
- Windows Server Core
Security settings management won’t work for a device that has PowerShell LanguageMode configured with ConstrainedLanguage mode enabled. See about_Language_Modes in the PowerShell documentation.
How works the flow?
When a device is onboarded to Defender for Endpoint and supported it starts the following flow to determine which management method is used and starts the settings management flow when needed:
- When the device is managed by an existing Microsoft Intune environment it is flagged as Intune managed and managed via the normal Intune flow
- When the device is not managed via Intune – it enables the settings management feature
- Creates device identity in Azure AD
- When the device aren’t fully Azure AD registered a new synthetic device identity is created in AzureAD
- When the device is already part of Azure AD via the Fully AD join it uses the current registration based on the existing object. ( Multi-tenancy not supported)
- The policy is retrieved from Microsoft Intune and enforced via Microsoft Defender for Endpoint
- Defender for Endpoint reports the status of the policy back to Microsoft Intune
If a device does not already have an Azure AD identity, the Security settings management will use the lightweight, synthetic mechanism to create the device identity in Azure AD. If a device previously fully registered to Azure AD (e.g. Hybrid Join), it is using the existing AzureAD/ HAADJ object.
Simplified deployment flow for Windows: View larger version here
Simplified deployment flow for macOS and Linux: View larger version here
For macOS and Linux, there is no AzureAD decision flow for macOS and Linux and work together with the synthetic registration in AzureAD.
For additional explanation some examples:
Windows Server 2012+ is part of a workgroup and onboarded with Defender for Endpoint
When the Windows Server is part of a workgroup and onboarded with Defender for Endpoint it will register using the synthetic lightweight version. There is no join type visible in AzureAD since it is using the lightweight version.
Windows Server 2012+ is domain joined and not synced with AzureAD
As long as the device does not have an identity in Azure AD – it will register using the synthetic lightweight version. There is no join type visible in AzureAD.
Windows Server 2012+ is domain joined and synced with AzureAD (affiliated with M365 tenant)
When the Windows Server is part of the AzureAD that is affiliated with the M365D tenant (same tenant) it will use the existing AAD identity.
When the device is already part of another AzureAD with an active AAD identity in a tenant that is not affiliated with the M365 tenant it will not work. Security settings management does not enable the management of devices across multiple AzureAD tenants. It will show the error “enrollment status”.
Configure Security settings management
Defender for Endpoint configuration
Before using security settings management it is needed to configure Defender for Endpoint and Intune and enable the integrations.
First, we need to enable the Security settings management configuration in Defender for Endpoint. Open the Microsoft 365 Defender portal and go to Settings > Endpoints > Configuration Management > Enforcement scope (1)
In this view, we can select the platforms:
- Windows Client devices
- Windows Server devices
- Linux devices
- macOS devices
There is an option between On all devices and On tagged devices. When configuring the option on all devices it will enforce all machines part of the supported OS that aren’t managed by Microsoft Intune. It is recommended to use the feature by selecting the On tagged devices option and testing first with a smaller scope.
Enable the future with the setting; Use MDE to enforce security configuration settings from Intune (2).
Enable the configuration Security settings management for Microsoft Defender for Cloud onboarded devices (3) to make sure the flow is supported for the Defender for Cloud onboarded devices when needed for the environment.
With the configuration Manage Security settings using Configuration Manager (4) it is possible to enable the co-existence with Configuration Manager.
Off: Microsoft Defender for Endpoint will manage security settings on devices even if Configuration Manager is in place.
On: Configuration Manager is recognized as the single security management authority. Defender for Endpoint will not manage security settings on machines that are already managed by Configuration Manager.
When using both channels there is the chance of conflicts. It is always recommended to use one single channel and not use multiple channels for the same setting. When applied from multiple sources it will change between the sync times.
In Microsoft Intune, it is needed to enable the integration between Intune and Defender for Endpoint. Open the Intune portal and go to Endpoint security > Microsoft Defender for Endpoint. Enable here the configuration Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations to On
For the relevant users, there is a new role available in Microsoft 365 Defender for security settings management. For configuring the new role:
Go to Settings > Endpoint > Roles and use the following permission: Manage endpoint security settings in Intune. Users with the new permissions can change and create Endpoint security settings in Microsoft Endpoint Manager without the complete Endpoint Manager Roles.
Azure AD Groups
It is important to create Azure AD Groups. After the onboarding and when the device is part of the Security setting management flow there is an object created in Azure AD, or using the existing object.
Since we need to make sure all machines part of the scope are enrolled and automatically assigned with policies it is important to design a good and flexible device structure.
Previously it was possible to use the MDEJoined or MDEManaged label. With the new preview feature, it is currently not possible to use the previous system labels. There are two solutions:
- Create groups based on OS attributes/ available attributes
- Create groups with the management attribute MicrosoftSense
When using OS attributes the advantage is to include all machines/ including potential machines that are not managed – the policy is only applied when the device is enrolled. Ideally, there is one AV baseline policy deployed to systems for each OS (Intune or MDE managed).
Of course; the grouping method of Azure AD depends on the customer and environment. Personally, I like the following structure based on different rings for each OS level (Windows/ Windows server/ Linux/ MacOS). With this method, there is the option for testing new policies in Ring 0/ Ring 1. Since Ring 2 is dynamic the machines are always included and assigned by the baseline policy.
|Ring 0||Assigned||Machines part of ring 0 for testing. Security is able to use this group for testing the policies without impacting all machines|
|Ring 1||Assigned||Machines part of ring 1 for testing. Security is able to use this group for testing the policies without impacting all machines|
|Ring 2||Dynamic device||The machines part of ring 2 are based on dynamic device rules. With the vision; include all relevant machines – and make sure the device is automatically managed without any manual user interaction or manual assignment to groups.|
Recently Microsoft added the new device-type Windows Server in Azure AD – which results in a good difference between endpoints and servers. Most important is to find a way of automatically adding machines, without requiring admins to perform additional steps for adding devices in groups or creating new policies. With the use of the Windows Server attribute, this is possible.
TIP: Use the graph API explorer for checking the available device attributes of the AAD object. Sample query:
Example rules for dynamic groups
All objects with the OS Windows Server:
(device.deviceOSType -eq "Windows Server")
All objects with the OS Linux:
(device.deviceOSType -eq "Linux")
All objects with management Type Microsoft Sense:
(device.managementType -eq "MicrosoftSense")
The next step in the flow is the creation of the policies. The new native security settings management capabilities in Defender for Endpoint are leveraging Intune on the backend. In general, there are three ways of adding policies:
- Via Intune – Endpoint Security
- Via Microsoft Defender for Endpoint
- Via Graph API (The Graph API can be used for creating settings via the API)
In all cases, the policy is configured in Intune and visible from all of the methods. Policies are automatically synced with Microsoft Intune when creating the policy in Defender for Endpoint.
Before starting with the explanation of the policy creation flow – important to explain which settings are currently supported via Security settings management.
The following policies are part of the security settings management capabilities:
|Platform||Endpoint security policy||Profile|
|Linux||Antivirus||Microsoft Defender Antivirus|
|Linux||Antivirus||Microsoft Defender Antivirus exclusions|
|Platform||Endpoint security policy||Profile|
|macOS||Antivirus||Microsoft Defender Antivirus|
|macOS||Antivirus||Microsoft Defender Antivirus exclusions|
Windows 10/11 and Windows Server
|Platform||Endpoint security policy||Profile|
|Windows||Antivirus||Microsoft Defender Antivirus|
|Windows||Antivirus||Microsoft Defender Antivirus exclusions|
|Windows||Antivirus||Windows Security Experience|
|Windows||Attack Surface Reduction||Attack Surface Reduction Rules|
|Windows||Endpoint detection and response||Endpoint detection and response|
Create policy via Defender for Endpoint
Now we are able to create the policy via Intune/ Microsoft Defender for Endpoint. Via Defender for Endpoint it is possible to create and view the new policies.
By going to Configuration Management > Endpoint Security Policies there is a new view available with all existing policies and the option to create new policies. This view is with the input of Intune.
Use the button Create new policy to create a new policy.
|Currently, not all templates are available via the Defender for Endpoint portal, use Intune when the policy is not visible. Microsoft is working on adding more templates as part of the unified policy experience in Microsoft 365 Defender/ Defender for Endpoint.|
Configure the setting via the policy creation UI. The setting is exactly the same in comparison with the Intune UI.
In the assignment step, it is needed to assign the policy to the AzureAD group. Good to know – there is currently no option to deploy the policy to MDE-related device groups. Hopefully, in the future Microsoft allows more scoping options to the defined MDE groups to allow more flexibility around the scoping.
I like to see the option in the future to use dynamic attributes for defining groups – based on detected software via the TVM component, so it is possible to scope potential exclusions to the relevant systems where the software is detected. This limits the surface of the exclusion. Example; “All machines where Citrix software is detected”Jeffreyappel.nl
This is why dynamic groups are important – the manual method is not recommended for production usage, since new machines are not automatically added to the group. The target type is include/ exclude. Additional tags or assignment filters can be set via the Intune portal.
After the creation of the policy – it is visible in the Microsoft 365 Defender portal and in Intune – the settings and profile are the same. In the backend, Microsoft created the policy in Intune and used the mechanism of Intune.
Microsoft 365 Defender/ Defender for Endpoint view:
In Defender for Endpoint/ Microsoft 365 Defender it is possible to view all related information, including the overview with policy setting status/ applied device status and assigned/ exclude groups.
Additional tabs are policy settings value/ policy settings status/ applied devices/ assigned groups.
Start the enrollment
Since we have now the base configured we can start with enabling the first machines. Depending on the enforcement flow it is configured with the value All devices or On tagged devices enabled the enforcement flow with the value; On tagged devices we need to tag the machines.
For enabling the management use the tag: MDE-Management for each device. When the tag is applied it will launch the Security settings management flow and creates objects in AAD and Intune.
Tagging is available via the portal, API, or registry. Stay tuned for some more ways of setting the tag; Microsoft is working on more methods to assign tags automatically. This is perfect for larger enterprises where the All devices scope is no option in the environment scope.
The first step of the flow is the automated creation of the AzureAD object or using the existing AAD object as earlier explained in the flow.
For both Windows/ Linux and macOS the synthetic object is created in AzureAD:
1: When the Join Type AzureAD Joined is visible, the machine is registered as part of the AAD-join flow.
2: When the devices are visible without any join type/ registered/ activity timestamp the device is created via the synthetic flow. In the image below the new Windows Server OS type is visible.
For Linux the object is visible without Join Type and part of the MDM Microsoft Intune. Linux objects contain the OS and distro version. In the example below it is Ubuntu with version 20.04.
In Intune the object is visible with the managed by value MDE. When the value is Intune the device is natively managed by Intune. With MDE the device is managed via the Security settings management flow.
For Linux and macOS the device is visible via the same view and managed by MDE.
With the use of dynamic groups, the object from AzureAD is automatically added to the group. When the policy is deployed to the AAD group the policy will be assigned automatically.
Result in Microsoft 365 Defender
In Microsoft 365 Defender/ Defender for Endpoint the device is managed by MDE and the enrollment status is completed.
Via the tab Security Policies all assigned policies are visible. When opening the profile the full policy page is visible as explained before in the Endpoint Security Policies view.
For Linux and macOS-supported machines, the experience is the same:
When the device is successfully enrolled and managed by MDE it will take some time before the first initial sync is applied. When the enrollment is succeded the cadence (of 10 minutes) starts immediately when the enrollment succeeds – the first policy sync is after +-10 minutes. After the first policy sync the policies will be synced based on a 90 minutes interval with Microsoft Intune.
Hopefully, in the future, Microsoft support more options for the policy sync. It would be great when it is possible to sync the policy in bulk (device group) or force a complete policy sync via the policy (emergency changes).Jeffreyappel.nl
With the use of the Policy Sync button from the MDE device page it is possible to enforce the policy refresh and receive the new policies (immediately sync in worst case up to 5/10 minutes). The policy sync button is available via the device page:
Simplified sync flow timings:
Troubleshooting during enrollment
During the enrollment, it is possible to troubleshoot the Security management enrollment. There are multiple insights available for checking potential enrollment. The following options are common:
- Device page
- Using client analyzer
- Error code via registry
- Configuration Manager dashboard
With the use of the registry, it is possible to check the current status of the enrollment flow. Useful enrollment status data is part of the Sense CM location.
The Enrollmentpyaload key contains the check-in URL and IntuneDeviceId. When the IntuneDeviceID is visible the machine is enrolled in Intune. Microsoft uses the following URL for the check-in. https://checkin.dm.microsoft.com/devicecheckinfeatp/atp
The enrollment status is the general Enrollment code. With the status of 1, the flow is completed and managed. View the error reference table here.
TenantId of the connected tenant.
Part of the device page in Defender for Endpoint is the device management information. When the device is managed by MDE and the MDE Enrollment status is success the device is correctly onboarded as part of the management.
Configuration management dashboard
Via the device configuration management dashboard, it is possible to view the overall security management status and failed status of the machines.
The client analyzer includes troubleshooting information related to the configuration management flow. Download the client analyzer via: https://aka.ms/mdeclientanalyzer (Windows) and run the MDEClientAnalyzer.cmd.
When completed the folder MDEClientAnalyzerResult contains related files and additional support files for troubleshooting. The folder MdeConfigMgrLogs includes the support files related to the Security management enrollment.
|MdeConfigMgrRegInfo||Registry information of the MDeConfigMgr flow including the enrollmentStatus/ TenantId/ DeviceId/ EnrollmentPayload/ MEmConfiguration and check-in attempts.|
|Policies||Json package of the targeted policies including the configuration and values.|
|Report_||The report file includes the compliance state of the policies and reports the result.|
|SecurityMangementConfiguration||The file includes the configuration of the security management flow; including the mechanism of applying policies.|
For further troubleshooting check the MdeConfigMgrRegInfo file. In this file the enrollment status/ TenantId/ DeviceId and payload are visible. Microsoft uses the URL checkin.dm.microsoft.com/devicecheckinfeatp/atp for the check-in. SenseCmModeSwitch is the management mode. 2 is the new V2 flow of the MDE management configuration. When 1 is visible the MDE management flow is using the old flow and not ready for the synthetic registration.