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. Since 7 November the new security settings management feature is generally available for all customers.

Blog information: Blog published: July 18, 2023 Blog latest updated: October 15, 2024

Historic

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 set up 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.

New situation

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 has 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 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 the 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 the device page

Important: The future is since 07 November 2023 generally available. Part of the GA release is the streamlined security settings management in the Defender portal/ Native support for Linux and macOS and the improved device enrollment flow by removing the dependency on Entra ID.

---

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:

• GPO
• MECM (Endpoint Protection site role)
• Intune
• MECM via Tenant Attach
• MECM via Co-Management
• Azure Automanage/ DSC
• Yamf
• Ansible
• PowerShell
• 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 (personal opinion):

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. Co-Management supports more configuration and allows other use of custom settings/ and security baselines. Where Security Settings Management is limited to a pre-defined set of settings related to Defender.

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

Prerequisites

For all prerequisites read the following docs: Manage Microsoft Defender for Endpoint on devices with Microsoft Intune

Licensing

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 to use the security settings management.

Supported platforms

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 based on the latest configuration.

Linux

• 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.23052.0009 or later.

Windows 10/11

• Windows 10 Professional/ Enterprise
• Windows 11 Professional/ Enterprise

Windows Server

For down-level servers make sure the Sense version is 10.8295.22621.1023 or higher. Recommended for Windows Server is to install the latest available patches and make sure the system is fully updated with the latest KB, based on experience this will resolve most of the issues.

• Windows Server 2012R2/ 2016 with the unified agent (MMA is not supported)
• Windows Server 2019
• Windows Server 2022

macOS

• macOS 14 (Sonoma)
• macOS 13 (Ventura)
• macOS 12 (Monterey)
• macOS 11 (Big Sur)

Supported for machines with agent version 101.23052.0004 or later.

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?

Update: Microsoft added recently support for Domain Controllers and Server Core 2022.

Previously Microsoft had no support for Domain controllers and Windows Server Core. Since the latest updates Microsoft allows Domain controllers and Windows Server core. For Domain controllers, additional settings are needed (more on this later)

• Windows Server 2022 Server Core (with KB5025230)
• Domain controllers (preview)

The following systems are not recommended/ supported:

• Windows Server Core 2019 and earlier
• Non-persistent desktops, like Virtual Desktop Infrastructure (VDI) clients
• Azure Virtual Desktop (AVD and formerly Windows Virtual Desktop, WVD)
• 32-bit versions of Windows

PowerShell

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:

1. When the device is managed by an existing Microsoft Intune environment it is flagged as Intune managed and managed via the normal Intune flow
2. When the device is not managed via Intune – it enables the settings management feature
3. 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)
4. The policy is retrieved from Microsoft Intune and enforced via Microsoft Defender for Endpoint
5. 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.

Domain Controllers

Recently Microsoft added a new configuration for Domain Controllers. With the support of Domain Controllers it is possible to enforce and manage Domain Controllers via the MDE-Management channel. This future is currently in preview.

All be careful with the configuration of domain controllers. Using seperate policies and deploying them to the domain controller is recommended. To minimize risk to productivity, firewall policies aren’t supported on domain controllers. Read more: Microsoft

To enable Domain Controllers there is a new toggle. It is heavily recommended to start with the tagged option first, to review a couple of DCs.

Intune configuration

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 Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations to On

MDE permissions

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 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	Membership type	Reason
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 to check the available device attributes of the AAD object. Sample query:

https://graph.microsoft.com/v1.0/devices/<objectid>

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")

All objects with management type Microsoft Sense and platform Windows Server:

(device.managementType -eq "MicrosoftSense") and (device.deviceOSType -eq "Windows Server")

All objects with management type Microsoft Sense and platform linux:

(device.managementType -eq "MicrosoftSense") and (device.deviceOSType -eq "Linux")

---

Create policies

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:

Linux

Platform	Endpoint security policy	Profile
Linux	Antivirus	Microsoft Defender Antivirus
Linux	Antivirus	Microsoft Defender Antivirus exclusions
Linux	EDR	Endpoint detection and response

macOS

Platform	Endpoint security policy	Profile
macOS	Antivirus	Microsoft Defender Antivirus
macOS	Antivirus	Microsoft Defender Antivirus exclusions
macOS	EDR	Endpoint detection and response

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	Antivirus	Defender Update controls
Windows	Attack Surface Reduction	Attack Surface Reduction Rules
Windows	Endpoint detection and response	Endpoint detection and response
Windows	Firewall	Firewall
Windows	Firewall	Firewall Rules

*Windows Security Experience profile is supported, all the Tamper Protection setting is currently not supported

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:

Intune 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/excluded groups.

Additional tabs are policy settings value/ policy settings status/ applied devices/ assigned groups.

---

Start the enrollment

Tag device

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 create 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.

Tag device using asset rule management

With the recently released feature “Asset rule management” it is possible to create dynamic rules for asses and specify specific actions. With this feature, it is possible to create dynamic rules based on the device name, domain, OS platform, onboarding status, or device tag and specify the action. With the action it is possible to tag with the MDE-Management tag.

This feature is a good balance between the All devices scope and tagging devices manually. With asset rule management it is possible to create a phased roll-out of MDE management based on OS/ name convention or other attributes.

Rule condition for all machines with the Windows Server 2019 and Windows Server 2022 OS platform and onboarding status “onboarded”

Important: The below rule condition is currently not supported for MDE-Management. Microsoft is aware and working on a fix to make this feature. Please validate first to check of this future is working in the tenant. In my lab it was not working recently, all it can be changed soon. Alternative is to use Logic Apps or automation to tag devices, when you not want to use the All devices options

AzureAD object

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.

Intune object

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:

Sync timings

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-minute 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

Registry

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.

Computer\HKEY_LOCAL_MACHINES\SOFTWARE\Microsoft\SENSECM

Enrollmentpayload

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

EnrollmentStatus

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

TenantId of the connected tenant.

Device page

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.

Client analyzer

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.

File	Explanation
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 results.
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.

---

Sources

Microsoft: Manage Microsoft Defender for Endpoint on devices with Microsoft Intune

Microsoft: Manage security settings for Windows, macOS, and Linux natively in Defender for Endpoint (preview)

Microsoft: Security settings management now GA | Microsoft Defender for Endpoint (GA)