cuong do

Posted on Oct 13 Originally published at gitlab.com

Defender for Endpoint Day 2: onboard a device, then decide who can see it

#microsoftdefender #mde #endpointsecurity #azuresecurity

My own Day 2 study notes on Defender for Endpoint, rewritten as a hands-on guide and checked against Microsoft Learn (October 2026).
Day 1 was about plans and licenses (MDE Day 1: licensing and permissions). Day 2 is where it gets real: a device shows up in the portal, and suddenly everyone wants to know who is allowed to touch it.

The classic Day 2 surprise: you create a nice device group for the server team, forget to assign any user group to it, and the helpdesk can still see every server. Nobody hacked anything. That is just how the default works. Let's avoid that.

All screenshots come from my own lab tenant. URLs with tenant IDs are cropped out.

TL;DR

The local script is for testing on up to 10 devices. Production gets Intune, Configuration Manager or Group Policy.
Access in MDE is two questions: what can you do (a role) and on which devices (a device group). You need both.
A device group with no user groups assigned is open to everyone who has portal access.

1. Pick how you will onboard
2. Onboard one Windows device with the local script
3. Put people in Microsoft Entra groups first
4. Create a custom role (what people can do)
5. Create device groups (on which devices)
6. Let rules tag devices for you
Day 2 checklist

1. Pick how you will onboard

Before clicking anything, decide the architecture. Microsoft groups it into four:

Architecture	Fits
Cloud-native	No on-premises management, or moving away from it. Uses Intune
Co-management	Mix of on-premises and cloud. Configuration Manager + Intune
On-premises	You want to keep using Configuration Manager or Active Directory (Group Policy)
Evaluation and local onboarding	A pilot, or a small corner with no management tools, such as a DMZ

And the tools per platform:

Platform	Tools
Windows client	Intune, Configuration Manager, Group Policy, Defender deployment tool, local script (up to 10 devices), VDI options
Windows Server	Local script, Defender for Cloud integration (needs a server plan)
macOS	Intune, JAMF and the other macOS methods
Linux server	Installer script, Ansible, Chef, Puppet, Defender for Cloud, and more (needs a server plan)
Android / iOS	Intune (iOS also has an option for unmanaged devices)

Source: Identify your architecture and select a deployment method · Get started with your deployment

2. Onboard one Windows device with the local script

The local script is the instant noodles of onboarding: perfect for one hungry lab VM at 2 a.m., not how you feed 5,000 laptops. Microsoft says it plainly: 10 devices or fewer.

In the Defender portal go to Settings > Endpoints > Onboarding.
Pick the operating system, then Deployment method: Local script (for up to 10 devices).
Select Download onboarding package.

Copy the zip to the device and extract it. You get WindowsDefenderATPLocalOnboardingScript.cmd.
Open Command Prompt as administrator and run the script. Press a key when it asks.
Give it a few minutes, then find the device in Assets > Devices. Sensor health should be Active.

Run the detection test

The onboarding page gives you a one-line PowerShell command (step 2 in the screenshot above, also on the Microsoft Learn page below). Copy it from there and run it in an elevated Command Prompt on the onboarded device.

The window closes by itself. That is normal, not a crash. An alert for the device should show up in the portal in about 10 minutes, and the onboarding page shows First device detection test: Completed, like in my screenshot. The command writes into C:\test-MDATP-test, so in my lab I create that folder first.

Sources: Onboard Windows devices using a local script · Run a detection test on a newly onboarded device

Gotcha: there are two "local onboarding scripts"

My original notes linked the Microsoft Purview local script page. It looks almost the same, but it is a different package (DeviceComplianceOnboardingPackage.zip, downloaded from the Purview portal) and it onboards devices for Endpoint DLP and Insider Risk Management, not for MDE. Same 10-device advice, different product. If your device never appears in the Defender portal, check which zip you ran.

Source: Onboard Windows devices to Microsoft Purview using a local script

3. Put people in Microsoft Entra groups first

Every access decision in MDE points at Entra groups, so sort the groups out before the roles.

	What it is for
Security group	Access to resources. Members can be users, devices or service principals. Use this one for MDE
Microsoft 365 group	Collaboration (mailbox, shared files). Users only

Membership can be Assigned (you add people by hand) or Dynamic (rules add and remove users or devices from their attributes). Dynamic membership needs Microsoft Entra ID P1.

Role-assignable groups

If you want to give an Entra role (for example Security Administrator) to a group instead of to people one by one, the group must be role-assignable. The rules are strict, and they bite people who try to "just tick the box later":

You can only set it when you create the group. You can't convert an existing group, and you can't undo it.
Membership must be Assigned. No dynamic rules, and no nested groups.
Maximum 500 role-assignable groups per tenant.
Needs Entra ID P1, and at least Privileged Role Administrator to create one.
With Entra ID P2 you can put the group in PIM, so members activate the role only when they need it. Require approval for that, or a less-privileged admin could reset someone's password and activate it for them.

Sources: Learn about groups and membership · Use Microsoft Entra groups to manage role assignments · Create a role-assignable group

4. Create a custom role (what people can do)

With Microsoft Defender unified RBAC, roles live in Permissions > Microsoft Defender XDR > Roles > Create custom role. You need at least Security Administrator in Entra ID, or all Authorization permissions in unified RBAC.

The wizard asks for three things:

Permissions, in groups:
- Security operations: alerts, response, live response, file collection, email and collaboration actions
- Security posture: vulnerability management, exception and remediation handling, security baselines, Exposure Management
- Authorization and settings: roles, core security settings, detection tuning, system settings
- Data operations (preview)
Assignments: Entra security groups (or single users) and the data sources the role applies to, such as Defender for Endpoint.
Review and submit.

Two things that catch people:

A new unified RBAC role is not enforced until you activate unified RBAC for that workload. Until then the portal happily shows your role and ignores it.
The role says what, not where. For MDE, device groups still decide which devices a user can see and act on. Configure them separately.

My lab still had the older Endpoints roles page (Settings > Endpoints > Roles). The idea is the same: a role gets one or more Entra groups.

Sources: Create custom roles with Microsoft Defender unified RBAC · Permissions in unified RBAC

5. Create device groups (on which devices)

Settings > Endpoints > Permissions > Device groups > Add device group. The wizard has four steps.

General: name, description and the remediation level for automated investigation: No automated response, three "Semi" levels (approval required for all folders, non-temporary folders, or system folders), or Full remediation.

Devices: the matching rule. Conditions are device name, domain, tag and OS.

A device must match all the conditions you fill in.
Several values for the same condition work as OR. Up to 10 values per property.

Preview devices: shows up to 10 devices that match. Use it. It is much cheaper than finding out next week.

User access: the Entra groups that may see this device group. Only groups that already have an RBAC role show up here, so do step 4 first.

How ranking works

A device that matches several groups joins only the highest-ranked one (rank 1 wins). Think of it as a VIP list with one door. Devices that match nothing land in Ungrouped devices (default), which you can't delete or re-rank, but you can still set its remediation level and user access.

The default that surprises everyone

If you assign no user groups to a device group, it is visible to everyone with portal access. It is the opposite of a nightclub: no list means everybody gets in. Always assign at least one group.

Other limits: up to 2,000 device groups per tenant, and changes can take from minutes to a few hours to show everywhere.

Source: Create and manage device groups

6. Let rules tag devices for you

Tags feed device groups, and nobody enjoys tagging 300 servers by hand. Settings > Microsoft Defender XDR > Asset rule management creates rules that add a tag when a device matches conditions such as name, domain, OS platform, internet-facing status, onboarding status or an existing manual tag.

Changes can take up to an hour to appear.
Tags set by a rule can't be edited by hand, and the rule removes the tag when a device stops matching.
Want to pause a rule? Use Turn off. Deleting it can change the tags already applied.

Sources: Create and manage device tags · Asset rule management: dynamic rules for devices

Day 2 checklist

[ ] Deployment method chosen per platform. The local script stays in the lab
[ ] Test device onboarded, sensor Active, detection test alert seen
[ ] Entra security groups created for each team (role-assignable only if they need Entra roles)
[ ] Custom roles created, assigned to groups, and unified RBAC activated
[ ] Device groups created, ranked, previewed, and every group has user access set
[ ] Asset rules tag new devices automatically

Day 3 is next: device timeline, inventory and vulnerability management.

DEV Community