How to deploy Microsoft Defender for Identity

Are you planning on deploying Microsoft Defender for Identity (MDI), but you are not sure how to? No worries, this blog will walk you through the deployment steps.

What is Microsoft Defender for Identity

MDI Leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. Now that we got that out the way, let’s move on the fun stuff.


  • Licensing
    • One of the following license is required.
      • Enterprise Mobility + Security E5/A5
      • Microsoft 365 E5/A5/G5
      • Microsoft 365 E5/A5/G5 Security
  • Directory Service Account (DSA)
    When creating the DSA, you have three options. For more info click here
    • Group Managed Service Account (gMSA) (recommended) – This is the recommended DSA option due to its more secure deployment and management of passwords.
    • Regular user account in Active Directory – This option is easy to get started with but requires additional management overhead of passwords.
    • Local service account – This option is used out-of-the-box and deployed by default with the sensor, no additional configuration steps are required. This option has limitations such as no support for SAM-R queries and multi-forest scenarios.
  • Permissions
    • To create your Defender for Identity instance, you’ll need an Azure AD tenant with at least one global/security administrator
    • You need to be a global administrator or security administrator on the tenant to access the Identity section on the Microsoft 365 Defender portal and be able to create the workspace.
  • Browser
    • Access Defender for Identity using Microsoft Edge or any HTML 5 compliant web browser.
  • Firewall
  • Ports, Network Name Resolution, Sensor requirements, Server specifications, Time synchronization, Network adapter and Window Event logs requirements are found here.

Before we move forward we need to create the Defender for Identity workspace.

Create the defender for identity workspace

To create a Defender for Identity workspace, Navigate to and in the left menu, select Settings > Identities, and wait for the process to complete.

Validate access to the Defender cloud service

Before installing the sensor, confirm access to the defender cloud service from the domain controller. We will use PowerShell to validate access to the service URL. For commercial, use  https://*your-instance-name* and for GCC, use  https://*your-instance-name* We will need the workspace name.

Navigate to > Settings > Identities > under General click on About > then copy the Workspace Name. In my lab, the workspace name is Contoso.

Your cloud service URL for GCC would look like and for commercial. Since it is not best practice to browse on a domain controllers, we will use a short PowerShell command to validate access. Run the command below.

$HTTP_Request = [System.Net.WebRequest]::Create('')

A 503 error will validate access. If you get a different error, or prompted for a certificate, then there are issues accessing the service. Check for firewall or proxy settings.

Create the gMSA account

It requires a little more effort to use a gMSA account, so we will go through the steps to create the account. Adding the account after creation is the same as adding a regular active directory account.

Confirm the following before creating a gMSA account.

  • The forest schema needs to be at least Windows Server 2012
  • The master root key for AD has been deployed
  • And there is at least one Windows Server 2012 DC.

The Domain Controllers require a root key to begin generating gMSA passwords. The KDC root key creation requires domain admin or enterprise admin rights. For more information click here. Before creating a root key, check if one exist already.

To check, open PowerShell and run the command below

The results from the screenshot above confirms the existence of the root key. No result mean the key does not exist. Run one of the commands below to create the root key if it does not exist.

If only one DC, use this command to create the root key and set start time in the past:
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
For multiple DC’s, use the command below and allow time for replication:
Add-KdsRootKey -EffectiveImmediately

Run the PowerShell script below to create the gMSA account. The script creates an Activce directory group and all domain controllers are added to it. As a result any DC can retrieve the account password. Click here to learn more.

# Set the variables:
$gMSA_AccountName = ' service1'
$gMSA_HostsGroupName = 'gMSAGroup'
$gMSA_HostNames = 'srvEl4HDC' #, 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'

# Import the required PowerShell module:
Import-Module ActiveDirectory

# Create the group and add the members
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru -Verbose
$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
    ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
# Or, use the built-in 'Domain Controllers' group if the environment is a single forest, and will contain only domain controller sensors
# $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
# Create the gMSA:
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
-PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

To confirm the creation of the gMSA account, open PowerShell and run this command.

Get-ADServiceAccount -Identity service1   #service1 is the name of the gMSA account.

Install the gMSA account on each DC

Like I said, the gMSA account takes a little more effort than the active directory user account. After creating the gMSA account we need to install it on each DC’s. Run the command below to install, then wait 10 hours for the DC to request a new kerberos ticket, and registered its group membership.  If you do not want to wait, restart the DC.

Install-ADServiceAccount -Identity 'Service1'

Add the directory service account in Microsoft 365 Defender

To connect your sensors with your Active Directory domains, you’ll need to configure the Directory Service account in Microsoft 365 Defender.  You can use a group managed service account (gMSA) or a regular Active Directory service account.  For this example, we will use a standard read-only AD service account. The steps to add a gMSA account is identical to the steps below.

When using a regular AD account, it is recommended to use a service account instead of a user account. Creating a service account in AD is super easy, so we will move on to adding the account.

Navigate to > Settings > Identities > under General click on Directory service accounts then Add credentials. In my example, the account name is Blake and the domain name is

Click Add credentials to add a directory service account.  Enter the Account name, Domain and Password, then click Save. Simple and straightforward.

Download and install the sizing tool

Run the sizing tool before installing the sensor. The Sizing Tool measures the capacity needed for domain controllers, not ADFS servers. The following CPU and Random Access Memory (RAM) capacity refers to the sensor’s own consumption, not the domain controller capacity.

Download the sizing tool:
Click here to download the sizing tool. When the page opens, click on the highlighted link as shown in the image below.

Install the sizing tool:

  • Use your enterprise admin account to run the tool
  • If possible, run the tool on a Privileged Access Workstation (PAW). If a PAW is not available, run the tool on a member server or workstation.
  • The sizing tool will collect counters from each domain controller. Allow the tool to run for 24 hours.
  • Extract the files from Tri_Sizing_Tool_ZIP. Open command prompt as administration and run TriSizingTool.exe.

The sizing tool will create an excel file in the folder you ran the tool from. Locate and select the “Azure ATP Summary” sheet for any domain controller capacity recommendations.

Download the sensor

Navigate to > Settings > Identities > under General click on Sensors > then to the right, click on Add sensor

On the Add a new senor page, copy the Access key.  The key is only used to install the senor.  All communication after the sensor is installed will use certificates for authentication.

The download will start immediately after clicking on Download installer.  The name of the file is Azure ATP Sensor – it is not best practice to open a browser and download files on a domain controller.  Downloader the installer on a workstation, then copy the installer to the domain controller. The zip includes the following files.

Install the sensor

Microsoft Defender for Identity supports up to 350 sensors. If you need more, contact support. Before installing the sensor, confirm Microsoft .Net 4.7 or later is installed.  If not, the sensor package will install it, but the server might reboot.

Extract the zip file that was downloaded in the previous section and run Azure ATP Sensor Setup.exe as administrator. On the first page select your language and click Next.

The installer checks if the server is a DC.  If not, it installs the standalone sensor.  Click Next

On the Configure the sensor page, enter the installation path and access key, then click Install

If there are no errors or issues, the installer should report “Installation completed successfully”.

Open services on the DC and confirm the MDI service is running.

Navigate to the security portal and confirm the health of the senor.  Check the service status and the health status

If the status is not healthy, check if NTLM auditing is enabled. For step by step instructions, click here. After stepping through the instructions, the highlighted options below will be enabled.

The end. Happy hunting.


Leave a Reply