When Raven and I are out in my backyard, she's always on high alert, her keen senses picking up on every subtle change in her environment. Just like Raven, Microsoft Defender for Identity (MDI) is constantly on the lookout, sniffing out potential threats to your network. Whether it's an unusual login attempt or a suspicious movement within your system, MDI is there to detect and alert you to any signs of trouble.
Raven's ability to sense danger is akin to MDI's advanced threat detection capabilities. She can differentiate between a harmless passerby and a potential predator, much like how MDI distinguishes between normal user behavior and potential security breaches. This vigilant monitoring ensures that any threat is identified and addressed before it can cause harm, keeping your network as safe as Raven keeps our home.
Just as I trust Raven to protect us from unseen dangers, you can rely on MDI to safeguard your network from cyber threats. With its continuous monitoring and real-time alerts, MDI acts as your loyal guardian, always ready to spring into action at the first sign of trouble. The following blog will help you roll out MDI, whether you are new to MDI or a seasoned expert. So, as you enjoy the peace of mind that comes with having Raven by your side, you can also rest easy knowing that MDI is tirelessly working to keep your digital environment secure.
Introduction to Microsoft Defender for Identity (MDI)
Microsoft Defender for Identity (MDI) is a security solution designed to help protect your organization from advanced threats, compromised identities, and insider actions. By leveraging on-premises Active Directory signals, MDI provides comprehensive monitoring and analysis to detect suspicious activities and potential security breaches. This tool is essential for maintaining the integrity and security of your network infrastructure.
Deploying MDI involves several critical steps, starting with a thorough performance and sizing review to ensure your Domain Controllers (DCs) can handle the additional load. The MDI agent collects and analyzes data from your DCs, which requires adequate processing power and network capacity. Proper planning and execution of this deployment will help you maximize the effectiveness of MDI in safeguarding your environment.
This guide will walk you through the entire deployment process, from initial preparation to the final configuration. Whether you are an experienced administrator or new to MDI, this document provides the necessary information and resources to successfully deploy and manage Microsoft Defender for Identity in your organization.
MDI Documentation
Microsoft Defender for Identity documentation - Microsoft Defender for Identity | Microsoft Learn
Monitored Activities
Monitored activities - Microsoft Defender for Identity | Microsoft Learn
Security alert name and mapping with MITRE
Integration with the XDR Portal
Note 1: MDI data is available for advanced hunting using KQL queries within the XDR portal.
Note 2: The name of this product started out as Advanced Threat Analytics (ATA). The ATA reference may pop up, but it is now MDI.
Deploying MDI
This guide is designed to assist administrators who are deploying Microsoft Defender for Identity for the first time, using the new Defender for Identity PowerShell Module.
Performance and Sizing Review
Before deploying, it's crucial to ensure that your Domain Controllers (DCs) can handle the load imposed by the Defender for Identity (MDI) agent. To assist with this, Microsoft provides a load/performance testing tool. This sizing tool can be executed on either a desktop or a DC and must be run by a domain administrator.
You can find the MDI sizing tool at the following locations:
GitHub - microsoft/Microsoft-Defender-for-Identity-Sizing-Tool
Plan capacity for deployment - Microsoft Defender for Identity | Microsoft Learn
The tool should be run 24 hours to capture data from all DCs globally. It only needs to be executed on a single device, and the results will be compiled into a single .xlsx file.
To run the sizing tool against a single domain, extract the tool and use the following command in a command prompt, after navigating to the directory where the tool is located:
C:\temp\TriSizingTool.exe -UseCurrent=UserDomain
The screen grabs below are from a simple domain within my lab environment, providing a sample of what the output file looks like (with 2 tabs). The tool only ran for a couple of hours, so the sample size is smaller than recommended.
ATA Summary tab
Azure ATP Summary tab
Please walk through the findings and identify any recommendations within the two tabs. Make adjustments where necessary.
Enabling Defender for Identity within the XDR Portal
The first time an administrator browses to the “Identities” section:
They will get an error on the Dashboard
- Browse to System > Settings
- Identities
This will bring up a screen notifying the administrator the environment is now being configured.
Once complete, you should see a Defender for Identity configuration page.
Prerequisites
Once the hardware is confirmed to be sufficient, configuration changes need to be made. Initially, deploying Microsoft Defender for Identity (MDI) required multiple configuration changes, which increased the risk of human error. However, the recent release of a PowerShell module for MDI has greatly simplified this process.
Manual configuration of the Active Directory Domain Services (AD DS) environment involves numerous steps. As the complexity of these steps increases, so does the potential for human error. Utilizing the PowerShell module can help mitigate these risks by streamlining the configuration process.
Prerequisites - Microsoft Defender for Identity | Microsoft Learn
Configure audit policies for Windows event logs - Microsoft Defender for Identity | Microsoft Learn
MDI PowerShell Module
Introducing the new PowerShell Module for Microsoft Defender for Identity
PowerShell Gallery | DefenderForIdentity 1.0.0.2
DefenderForIdentity Module | Microsoft Learn
Note: To use the MDI PowerShell module, it must be run on a server or Domain Controller with both the Active Directory and Group Policy modules installed. This new module simplifies the configuration of auditing and permissions within your environment, automating the entire process for the administrator. The steps outlined in this process are designed for a single domain.
Install-Module DefenderforIdentity
After downloading and installing the PowerShell module, the administrator should import it using the following command:
Import-Module DefenderForIdentity
Once the module is imported, the administrator can test the AD DS environment for MDI readiness.
From an administrator PowerShell command line, run:
- New-MDIConfigurationReport -Path C:\Temp -OpenHtmlReport
Note: If you are prompted for the Identity name, this is the Identity to be used to run the installed sensor.
This will generate an HTML report.
Now that a report has been generated, there are a number of PowerShell commands for the DefenderForIdentity module. This list can be found from the link above, or you can just run a get-command for a list.
Get-Command -module DefenderForIdentity
Service Account Creation and Installation
Even though the example above reports that changes need to be made, it doesn't account for the user or service account that will be used. Using a user account with elevated permissions is discouraged. Instead, a group Managed Service Account (gMSA) with limited permissions is recommended. The only permissions needed are:
- Read Only for Active Directory
- Read Only for Deleted Objects Container
In the first example, I ran a test against my Domain Administrator account. Notice that there are two "False" returns; ideally, everything should be set to "True" when running the specific test for the identity.
Test-MdiDSA -Identity pbbergs -verbose -detailed
While it's possible to set up a group Managed Service Account (gMSA) manually, using the DefenderForIdentity PowerShell cmdlet ensures that all configuration settings are completed correctly. This cmdlet also creates a group that grants Domain Controllers the ability to access the gMSA password.
- New-MDIDSA -Identity “gMSA-MDI” -GmsaGroupName “gMSA-MDI-Grp” -Verbose
Once I set up a new gMSA account, I re-ran the Identity test. As shown below, the gMSA account is not overly privileged and passes the test.
Note: If you plan on using Active Directory Federation Services (ADFS) or Active Directory Certificate Services (ADCS), the security group created in the previous step will need to include the ADFS and/or ADCS servers.
Next, the gMSA identity needs to be added to the Identity blade within the XDR portal.
- Security.microsoft.com > Settings > Identities > General > Directory Service Accounts
- Click on “+ Add Credentials”
- Complete the Information to update the new Identity
- Click “Save”
The portal is now ready to accept Domain Controllers, ADFS and/or ADCS servers.
Validate the Network Infrastructure
Before deploying the sensor, it's important to complete tests to ensure that the sensors can communicate with Azure and its logging engine. To facilitate this, we can use the new PowerShell cmdlet from the MDI PowerShell module, Test-MDISensorApiConnection.
Test-MDISensorApiConnection (DefenderForIdentity) | Microsoft Learn
Before running the PowerShell command, you will need to know the “WorkspaceName” since this is used within the parameter “-SensorApiURL”. It is built via the following:
"https://<your_workspace_name>sensorapi.atp.azure.com"
To find “your_workspace_name”
- XDR portal > Settings > Identities > General > About
If the device has the MDI sensor installed, then the -BypassConfiguration is not needed.
The parameter then is concatenated to the result of:
https://mngenvmcap99999sensorapi.atp.azure.com
To complete the validation test
- Bring up an administrative PowerShell command box
o Enter Test-MDISensorApiConnection -Verbose -SensorApiUrl https://mngenvmcap99999sensorapi.atp.azure.com -BypassConfiguration
The result should return a value of “True” if the device has access to Azure.
If the device has the MDI sensor installed, then the -BypassConfiguration is not needed.
Configuration Changes to Prepare for the Deployment of the MDI Sensor
With the MDI sensor now installed let’s do a test of the auditing settings of the domain. This can be completed by running:
- Test-MDIConfiguration -Mode Domain -Configuration NTLMAuditing
If we look at the Active Directory Group policy GUI, we can see that there are no policies in place for MDI at this time within the domain.
We could manually go in and build the policies needed -or- we could use the Set-MDIConfiguration and let the PowerShell cmdlet do the work for us.
There are other configuration settings that can also be configured which include:
- ADFSAuditing
- AdvancedAuditPolicyCAs
- AdvancedAuditPolicyDCs
- CAAuditing
- ConfigurationContainerAuditing
- DomainObjectAuditing
- NTLMAuditing
- ProcessorPerformance
- All (The complete list from the above bullets)
Configuring the Power Option to High Performance
One of the MDI PowerShell Module options (If used) can change the Domain Controller’s Power Option to “High Performance” via GPO. This is recommended for optimal performance when running the MDI sensor.
Updating the Auditing Configuration of the Active Directory Environment
Instead of changing these configurations one at a time, the “All” setting can be used which will configure the environment and build the GPOs as needed.
- Set-MDIConfiguration -Mode Domain -Configuration All -Identity gMSA-MDI -verbose
Note: In my environment I don’t have Exchange, ADFS or Certificate Services installed.
Taking another look at the Group policy shows that there is now a complete set of policies in place for auditing.
Notice that the system isn’t aware of whether or not a CA is installed so it added a CA policy to the base of the domain. If you aren’t using a CA these can be left as is or the link removed from the root of the domain.
Configuring Detection for Lateral Movement
The “Microsoft Defender for Identity – Remote SAM Access” isn’t linked to the root of the domain by default, this is an administrator’s choice. This helps with the discovery of potential lateral account movement.
As you read the Note below, this is no longer an issue with the newest version of the MDI sensor.
One of the requirements for using this Group Policy Object (GPO) is to not grant the “Network access: Restrict clients allowed to make remote calls to SAM” setting to the “Domain Controllers” Organizational Unit (OU).
When the PowerShell command Set-MDIConfiguration -Mode Domain -Configuration All -Identity gMSA-MDI -Verbose was run, it created and configured the GPO named “Microsoft Defender for Identity – Remote SAM Access.” This GPO is designed to be linked to the root of the domain and to “Deny”, “Apply group policy” on the “Domain Controllers” group.
To detect Lateral Account Movement paths within your domain, link this GPO to the domain root. In the example below, the GPO has been linked to the domain root.
If the “Access this computer from the network” setting has been configured, an additional step is required to grant the gMSA access. Ensure the gMSA account is allowed to access computers from the network by following these steps:
- Open the Group Policy that has configured the network setting.
- Add the gMSA account to the policy to allow it access.
- Computer Configuration > Policies > Windows Settings > Local Policies > User Right Assignment
- Include the gMSA account
- Select “Access this computer from the network”
Looking at the links within the Group Policy Management console, you can see there is the “…Remote SAM access” GPO linked at the domain root, but not for the “Domain Controllers” OU.
Running the following cmdlet will show that ADFS fails, causing the entire test to fail. This failure occurs because ADFS requires manual linking of the GPO to the appropriate OU. If you aren’t using ADFS, you can skip this step. However, ensure that the 'Microsoft Defender for Identity – Remote SAM Access' GPO is correctly configured and linked. Once this is done, the Remote SAM Access test should pass successfully.
- Test-MDIConfiguration -Mode Domain -Identity gMSA-MDI -Configuration All -Verbose
In my instance, it indicates that Entra Connect is not set up to be monitored. However, this is irrelevant since I am not using it in my environment. Therefore, the Domain Controllers' (DCs) sensors are now ready for deployment.
I want to run my HTML report one more time to have a hard copy for later use if needed. This report will verify that everything is ready for completion and can be saved for historical purposes.
- New-MDIConfigurationReport -Path C:\temp -OpenHtmlReport
Note: If you are prompted for the Identity, this is the Identity to be used to run the installed sensor.
As can be seen this warns about Entra Connect not being monitored, but we already knew that.
Installing the Sensor
Installing the Sensor with the GUI
For this example, the installation of the sensor will be done manually via the GUI. In a corporate environment, this process can be automated using a Device Management tool.
Browse to:
- Security.microsoft.com > Settings > Identities > General > Sensors
- Click on “+ Add sensor”
A new box will pop up, this will provide the agent installation software and “Access key”.
- Click on “Download installer” and save to a location that can be accessed by the DC(s)
- Copy the “Access key” and place it in a secure location that is also accessible by the DC(s)
- Login to the DC that you want to install the MDI agent on to
- Start up an administrative command shell and browse to the MDI agent location
- Execute “Azure ATP Sensor Setup.exe”
An installation window should pop up
- Select your “Language”
- Select “Next”
- Verify that the sensor is installed on the correct service type
- Select “Next”
- Copy and paste the “Access key” (Copied earlier when downloading the Sensor binary)
- Click “Install”
Installation should begin
- Click “Finish”
The sensor has now been successfully installed. Repeat this process for any other Domain Controllers (DCs), ADFS, or ADCS servers. Be sure to update the security group with the server names related to ADFS and ADCS.
In the next screen grab, you will notice that I now have two DCs being monitored. The first was installed yesterday, and the second was installed a few minutes ago. If you look at the “Health status,” you can see that the most recent installation is going through a review process and initially reports as “Not healthy.” If everything is functioning correctly on the device (DC, ADFS, or ADCS), the health status should change to “Healthy” within a few minutes. In my case, it took approximately 5 minutes.
Installing the Sensor from a Deployment Tool
There is the ability to install via a management tool the Sensor which includes the ability to be in “Silent” mode. Complete details and parameter options can be found at:
https://learn.microsoft.com/en-us/defender-for-identity/deploy/install-sensor#commands-for-running-a-silent-installation
PowerShell syntax:
.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
Proxy Configuration
If your enterprise uses a proxy, the MDI Sensor can be configured to utilize this appliance. Although I don't have a proxy environment available, I can still walk you through the steps to configure your MDI Sensor to use it. As of this writing, there isn't a Group Policy setting to control the MDI Proxy Configuration, so we will use PowerShell. If deploying the sensor via a management tool, the sensor configuration can be added as an additional step in its deployment.
Let’s verify that there isn’t currently any proxy configuration at this time.
- Get-MDISensorProxyConfiguration -Verbose
As can be seen, there is no configuration set up.
Now we can configure the Sensor to:
## Insert a proxy server into the Sensor deployment
$proxyServer = http://proxy.contoso.com:8080
$Credential = "FakeCredentials"
Set-MDISensorProxyConfiguration -ProxyUrl $proxyServer -ProxyCredential $Credential -Verbose
The Sensor tried to connect to the proxy and failed, but we can still verify the configuration worked.
- Get-MDISensorProxyConfiguration -Verbose
Note: For readability the window was reduced in size
If you ever need to clear the Proxy settings
- Clear-MDISensorProxyConfiguration -Verbose
Once again, let’s look at its Proxy configuration
- Get-MDISensorProxyConfiguration -Verbose
It is once again clean from any Proxy configuration settings.
Post Deployment Configuration
Threshold Configuration for Alerts
Threshold configuration in Microsoft Defender for Identity (MDI) allows administrators to customize the sensitivity of specific alerts to better align with their organization's security needs. By adjusting alert thresholds, you can control the volume of alerts generated, reducing false positives and focusing on more critical threats. The thresholds can be set to High, Medium, or Low, with High being the default setting that minimizes false positives. Medium and Low settings increase the number of alerts, which can be useful during comprehensive testing or in environments with higher security requirements. These configurations help ensure that MDI provides relevant and actionable alerts, enhancing the overall security posture of the organization.
To configure the available alerts:
- Settings > Identity > General > Adjust alerts thresholds
Entity Tags
Entity tags in Microsoft Defender for Identity (MDI) are crucial for enhancing the security and monitoring capabilities within an organization. These tags help categorize and prioritize different entities, such as users, devices, and servers, based on their sensitivity and role within the network. By appropriately tagging entities, MDI can more effectively detect and respond to potential threats, ensuring that high-value assets receive the necessary attention and protection. The primary types of entity tags include Sensitive, Honeytoken, and Exchange server tags, each serving a unique purpose in the overall security strategy.
Sensitive Tags
Sensitive tags are used to identify high-value assets that require heightened security measures. These tags are automatically applied to entities that are part of critical Active Directory groups, such as Administrators, Domain Admins, and Schema Admins. Additionally, administrators can manually tag other users, devices, or groups as sensitive to ensure they receive appropriate monitoring and protection
Honeytoken tags
Honeytoken tags are a strategic tool used to detect malicious activity by setting traps for attackers. Honeytoken accounts are typically dormant and have no legitimate activity associated with them. Any authentication attempt involving a honeytoken account triggers an alert, allowing security teams to quickly identify and respond to potential threats. These tags are particularly useful for identifying lateral movement and other suspicious behaviors within the network.
Exchange server tags
Exchange server tags are automatically applied to devices running Microsoft Exchange Server, recognizing them as high-value targets due to their critical role in email communication and data storage. By tagging these servers, MDI ensures they are closely monitored for any signs of compromise or unauthorized access. Administrators can also manually tag other devices as Exchange servers if needed.
Actions and Exclusions
The "Actions" and "Exclusions" settings are essential components for customizing the security response and detection framework. The "Actions" setting enables administrators to define automated responses to identified threats, ensuring timely and consistent mitigation efforts. Meanwhile, the "Exclusions" setting allows for the exclusion of specific entities from detection rules, helping to minimize false positives and streamline threat management.
Actions
The "Actions" setting in Microsoft Defender for Identity is pivotal for automating the response to security threats. By configuring automated responses, administrators can ensure that predefined actions are taken immediately when a threat is detected. This can include actions such as isolating a compromised device, disabling a user account, or triggering an alert to the security team. Automated responses help in minimizing the time between detection and mitigation, thereby reducing the potential impact of security incidents. This proactive approach is essential for maintaining a secure and resilient identity infrastructure.
Exclusions
The "Exclusions" setting allows administrators to exclude specific entities, such as IP addresses, devices, or user accounts, from certain detection rules. This is particularly useful for reducing false positives that can arise from legitimate activities being flagged as suspicious. For example, security scanners or certain administrative tasks might trigger alerts that are not indicative of a real threat. By configuring exclusions, these benign activities can be ignored, allowing the security team to focus on genuine threats. Exclusions can be set globally or by specific detection rules, providing flexibility in managing the security landscape.
Notifications
Health Issue Notifications
Users can be notified of health issues. This is configured in the settings page.
- Portal > Settings > Notifications > Health issues notifications > Add recipient email
Alert Notifications
Administrators can be notified of Alerts. This is configured in the settings page.
- Portal > Settings > Notifications > Alert notifications > Add recipient email
Summary of Microsoft Defender for Identity Deployment
Deploying Microsoft Defender for Identity (MDI) involves several critical steps, from verifying hardware capabilities to configuring the environment and installing sensors. By following this comprehensive guide, administrators can ensure a smooth and efficient deployment process. The use of the MDI PowerShell module significantly reduces the complexity and risk of human error, streamlining the configuration of auditing and permissions within the Active Directory Domain Services (AD DS) environment.
The initial phase of the deployment focuses on performance and sizing reviews to confirm that your Domain Controllers (DCs) can handle the load imposed by the MDI agent. This step is crucial to ensure that the deployment does not negatively impact the performance of your network. The MDI sizing tool provides valuable insights and helps administrators make informed decisions about their infrastructure.
Once the hardware is verified, the configuration phase begins. The PowerShell module for MDI simplifies this process by automating many of the necessary steps, reducing the potential for human error. This includes setting up a group Managed Service Account (gMSA) with the appropriate permissions, ensuring that the account is not overly privileged and meets the security requirements.
The installation of the MDI sensors is the next critical step. This guide covers both manual installation via the GUI and automated deployment using a Device Management tool. Ensuring that the sensors are correctly installed and configured is essential for effective monitoring and threat detection. The guide also addresses the configuration of proxy settings if your enterprise uses a proxy, providing a comprehensive approach to deployment.
The value of deploying MDI lies in its ability to provide robust security monitoring and threat detection. By leveraging on-premises Active Directory signals, MDI helps protect your organization from advanced threats, compromised identities, and insider actions. The automated processes and detailed configuration steps outlined in this guide ensure that your environment is well-prepared to handle potential security breaches, ultimately enhancing the overall security posture of your organization.
In summary, the deployment of Microsoft Defender for Identity is a critical step in safeguarding your network infrastructure. By following this guide, administrators can ensure a thorough and efficient deployment, leveraging the power of MDI to detect and respond to security threats effectively. The streamlined processes and automation provided by the PowerShell module make this deployment accessible and manageable, even for those new to MDI.
In conclusion, just as Raven's vigilant presence in our backyard ensures our safety, Microsoft Defender for Identity (MDI) provides robust protection for your network. By continuously monitoring and analyzing activities, MDI helps you stay ahead of potential threats, ensuring your digital environment remains secure. Whether you're new to MDI or a seasoned expert, implementing this powerful tool can significantly enhance your organization's security posture.
Additionally, it's important to note that if you own a Microsoft 365 E5, A5, F5 Security, or G5 license, you already have access to MDI. This means you can leverage its advanced threat detection capabilities without any additional cost. So, take advantage of this valuable resource and ensure your network is as well-guarded as my home is with Raven on patrol.
Note:
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Thanks to David Loder for proof reading and edit checks for this blog.
Updated Feb 10, 2025
Version 1.0
paulberg
Microsoft
Microsoft
