Blog Post

Microsoft Defender for Endpoint Blog
4 MIN READ

How to use tagging effectively (Part 2)

miriamwiesner's avatar
miriamwiesner
Icon for Microsoft rankMicrosoft
Jan 11, 2021

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.

 

 

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.

 

 

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

 

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.

 

 

 

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

 

 

 

 

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

 

 

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.

 

 

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

 

 

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"

 

 

 

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

Updated Jan 11, 2021
Version 1.0
  • lforbes-work's avatar
    lforbes-work
    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.





  • SpitFire-666's avatar
    SpitFire-666
    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!

  • davidpmartin's avatar
    davidpmartin
    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
  • 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

  • AndrePKI's avatar
    AndrePKI
    Iron 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!!)

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

  • Hi miriamwiesner ,

     

    can i suggest this method to simplify the tagging?

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

     

     

     
     
     

     

     

     

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

    Thought?

    Regards

    Dario

     

     

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

  • 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 ?

  • 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".