How to use tagging effectively (Part 2)
Published Jan 11 2021 09:52 AM 15.4K Views
Microsoft

In Part 1 of this blog series, we learnt about why tags are useful and how to maximise their potential for administration of Microsoft Defender for Endpoint. In the next two parts of this blog serieswe wanted to cover some advanced scenarios for applying tags, starting with…

 

Tagging your Microsoft Defender for Endpoint devices by OU path

Sometimes when working with Microsoft Defender for Endpoint you might want to display your Organizational Unit (OU) structure within Defender for Endpoint to build device groups to get better transparency for reporting.

 

To realize this scenario with Group Policies, we will create one script file in the process:

  • DefenderTagging.ps1

Create this script file and copy it to a location where you have access from a Domain Controller.

Contents of MSDETagging.ps1

 

 

 

 

$DN = (Get-ItemProperty -Path  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" -Name Distinguished-Name)."Distinguished-Name"
$OU = $DN.Substring($DN.IndexOf('OU='))

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging"
$name = "Group"

IF(!(Test-Path $registryPath))
  {
    New-Item -Path $registryPath -Force | Out-Null
    Set-ItemProperty -Path $registryPath -Name $name -Value $OU
  }
 ELSE {
    Set-ItemProperty -Path $registryPath -Name $name -Value $OU
  }

 

 

 

 

 

Depending on how many OUs your environment contains, you might want to fine grain the $OU selection done by this script: configuring too many tags could impact the performance when working in the Microsoft Defender Security Center.

 

Getting our scripts to run: Execution Policy

The Execution Policy restricts the execution of PowerShell Scripts on the system. On newer systems the default setting is “Restricted”. Having this setting configured, the system does not run scripts at all, therefore this setting needs to be changed before we can run the tagging script.

 

Execution Policy is not a real security feature, although some documentation states so. It is rather a feature that keeps you from running scripts unintentionally.

 

To maintain protection from running scripts unintentionally, but to have the ability to run scripts nevertheless, the setting “RemoteSigned” is a good approach:
Only local scripts (scripts within the local domain and signed scripts) can be run, unsigned scripts from the internet will be blocked from running.

 

You can either configure this option manually using the following PowerShell command:

 

 

 

 

Set-ExecutionPolicy RemoteSigned

 

 

 

 

Or since configuring it manually can take quite some effort, you can also configure it via Group Policy.

 

Getting started with the Group Policy

Create a new Group Policy Object which is linked to the root folder in which all your Defender protected devices are located.

 

Then navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.

 

miriamwiesner_0-1607335344610.png

 

Configure the Setting “Turn on Script Execution” and choose the option “Allow local scripts and remote signed scripts”, which configures the Execution Policy to “RemoteSigned”.

 

This setting is the foundation that our PowerShell script will be executed on the systems on which you want to configure your custom tagging.

 

miriamwiesner_1-1607335344617.png

 

Configuring the script in your Group Policy

In the Group Policy Object, navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) and open the properties of “Startup”.

miriamwiesner_2-1607335344623.png

 

Once the properties window opens, navigate to the tab PowerShell Scripts, and click on “Add”. The “Edit Script” window will open. Click on “Browse…” which opens a file browser window.

 

miriamwiesner_3-1607335344626.png

 

miriamwiesner_4-1607335344627.png

 

Per default, the location that is opened is already the right location within your Group Policy Object folder.

 

Now copy your DefenderTagging.ps1 script inside this folder and select the script and confirm with “Open”.

 

miriamwiesner_5-1607335344629.png

 

 

miriamwiesner_6-1607335344631.png

 

Confirm with OK and apply the changes to your Group Policy Object. Your tagging Group Policy is now configured.

 

miriamwiesner_7-1607335344633.png

 

Verify that your tagging was successful

The next time that your device applies the Group Policy, the settings will be configured, and you can also find your properly tagged machines in the Microsoft Defender Security Center.

 

Note:
If the Execution Policy needs to be configured first, you might find the new tag after the GPO was applied to your device for the second time. If you want to apply both settings at the same time, you can create two Group Policies and let the one that sets the Execution Policy run before the GP containing the startup script is executed.

 

miriamwiesner_8-1607335344635.png

 

Finding your devices in Defender for Endpoint can take up one day for the devices to sync.

 

miriamwiesner_9-1607335344636.png

 

Find your tagged device’s events via advanced hunting:

To find your tagged device, you can use an advanced hunting query such as the one below. Simply replace "DC=xyra,DC=local" with the distinguished name of your Active Directory domain.

 

DeviceInfo | where RegistryDeviceTag contains "DC=xyra,DC=local"

 

miriamwiesner_10-1607335344637.png

 

 

This concludes Part 2 of the blog series on how to use tagging effectively. Please join us for Part 3 where Steve Newby will guide you through scripting against the Defender for Endpoint API to apply tags based upon advanced hunting queries.

 

We welcome your feedback and questions on this or any of the other parts of this tagging blog and look forward to hearing from you.

 

Miriam Wiesner (@miriamxyra) and Steve Newby (@steve_newby)

Program Managers @ Microsoft Defender for Endpoint Product Group

10 Comments
Microsoft

Hi Miriam, is possible create a TAG automatically when a machine "Active" or "Inactive"?
Example: Onboarding the new Machine is set a TAG automatically "Active" or machine is classified as "Inactive" is set a TAG automatically "Inactive".

Hi @EltonSancho , 

 

A device is automatically tagged as inactive according to specific conditions described here.  Do you have another use case for marking a device as inactive ?

Microsoft

Very Useful information for many Customers. Thanks for the info.

Microsoft

Hi @miriamwiesner ,

 

can i suggest this method to simplify the tagging?

group policy preference "Registry", this is an example to tag the Domain Controllers

 

msftdario_0-1611561983617.png

 

 
 
 

msftdario_0-1611562637029.png

 

 

msftdario_1-1611562094913.png

 

this will be so much easy than deploy, manage and maintain the powershell script

Thought?

Regards

Dario

 

 

 
 
Microsoft

@msftdario , I would think the same,  GPO preference could be the preferred way to deliver the reg key change to domain devices .

Brass Contributor

@miriamwiesner Please note and be aware that this is about the registry method of device tagging. That is not supported anymore on newer Server OSes (Server 1803, 2019, 2022).
(I would love to get that back!!)

Copper Contributor

I updated the PowerShell script to be dynamic so that in organizations where users move location, the tag on the endpoint can be dynamically updated. Anyone interested can view the code Set-Tag . Deploying via GPO requires to add -ResetTag switch to ensure that when a users moves OU, the MDE Tag is updated at the same time

Copper Contributor
How can we create "device groups" based on Tags created by Registry Key?
 
When tagging with registry key method, the tag is assigned to device but on device inventory or device page is shown as a device group with the same format and colour.
When we try to create "Device Group" based on the new tag created by registry key the new device group is empty.
We can use the tag to filter on device inventory, but not to create new device groups.

Thanks
Iron Contributor

Pretty disappointing there's no easy powershell way to tag devices en-masse. The search in the GUI is also too basic - for example I should be able to just search for machines with "dev" in the name - but search only works for machines that start with, not contain the search term. So the most "effective" way for me to tag is to manually tag them, one by one :sad:

 

BTW another way of doing it is to use device groups, then filter your inventory by the groups you want to tag, then do a Select All and Manage Tags - although I'm not sure if this will clobber any existing tags. Fun!

Copper Contributor

What you have here isn't going to work. First running PS as a startup script isn't secure because you have to turn off PS security to get it to run. There are also security permissions around the POLICIES key and any Group Policy set is going to change the key. 

If there is a setting in the Policies Key then there should be an ADMX in Group Policy equivalent for it.
Put in a Microsoft Request to update the Windows 10 and 11 ADMX files to include the proper policy so you are not Registry hacking a policies key.

Worst comes to worst you can set it in a Registry Preference but make SURE to have "remove when no longer applied" or you will never be able to revert it.





Version history
Last update:
‎Jan 11 2021 09:52 AM
Updated by: