Microsoft Defender for Identity (MDI) is a critical component in the Defender security stack, designed to protect on-premises Active Directory (AD) environments from advanced attacks such as credential theft, lateral movement, and domain dominance. Before it carried the Defender name, this product had a long and interesting evolution. One that mirrors Microsoft’s broader journey into identity security analytics. MDI's story can be traced back to 2014 when Microsoft acquired an Israeli cybersecurity start-up called Aorato, whose flagship product, the Directory Services Application Firewall (DSAF), specialised in behavioural analysis of Active Directory traffic. Following the acquisition, Microsoft rebranded the technology as Advanced Threat Analytics (ATA) and released it publicly in 2015 as an on-premises threat detection platform. ATA became widely used for detecting Pass-the-Hash, Pass-the-Ticket, and reconnaissance activities within corporate networks.
In 2018 Microsoft introduced Azure Advanced Threat Protection (Azure ATP) which was the cloud-based successor to ATA. Azure ATP offered centralised management and cloud analytics while still deploying lightweight sensors on domain controllers. With the unification of Microsoft’s security branding under the Defender family, Azure ATP was rebranded in 2020 as Microsoft Defender for Identity. This marked the point where the product officially became part of the Microsoft Defender suite, integrated alongside Defender for Endpoint, Defender for Office 365.
MDI continues to evolve as a key telemetry source for Microsoft’s extended detection and response (XDR) strategy, leveraging cloud-scale analytics to detect identity-based threats across hybrid environments.
Planning Elements
Below are some of the planning aspects that you will need to address:
-
Capacity planning - Update 25-11-2023 ensure you run the TRI Sizing tool
-
Define deployment scope and objectives
-
Review prerequisites (infrastructure, network, permissions, licences)
-
Plan sensor deployment (sensor vs standalone sensor. Hint - not standalone!)
-
Confirm connectivity and cloud integration
-
Plan security and access controls
-
Establish monitoring and maintenance approach
-
Validate configuration and test detections - update 30-11-203 review the Test-MDI-Readiness script
-
Document configuration, permissions, and change control
Ensure that all of the EventID collection and auditing is enabled. This is a requirement for MDI.
Configure Windows Event collection Microsoft Defender for Identity | Microsoft Docs
Defender for Identity detection relies on specific Windows Event logs that the sensor parses from your domain controllers. For the correct events to be audited and included in the Windows Event log, your domain controllers require accurate Advanced Audit Policy settings. For more information about setting the correct policies, see, Advanced audit policy check. To make sure Windows Event 8004 is audited as needed by the service, review your NTLM audit settings.
SAM-R
Update May 2025 -- Note that due to a security issue, MDI no longer uses SAM-R.
The process to allow MDI to query remove SAM account database information is available here:
Implementation of this policy could affect offline address book generation on servers running Microsoft Exchange 2016 or Microsoft Exchange 2013.
Network access: Restrict clients allowed to make remote calls to SAM
In the article which discusses the feature, note that only Windows Server 2016 and newer can edit the policy in the UI.
The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later. This is the only option to configure this setting by using a user interface (UI). On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy Preferences. To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server 2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same registry key exists on every computer after the corresponding KB is installed.
Creating MDI Instance
When you navigate to the portal for the first time, you will be prompted to create your MDI instance. The portal is available at:
This is the first time visiting the portal for this tenant, so we are asked to create the MDO instance.
This starts the configuration wizard.
For reference the verbiage displayed:
New user investigation experience available! Using the new experience, view all of your familiar alerts and activities and explore your Investigation Priority Score, identity security posture management, advanced investigation and enhanced user pages for complete identity threat protection. Learn more
Creating MDI Directory Access Account
This is a standard user account that MDI will use to read objects from AD. It can be a gMSA account or a standard service account. Given that I'm tired of seeing service accounts with passwords that are 15+ years old, gMSA are the way to go!
We will create a AD group called "Defender-Identity-gMSA-Access". The servers that need to use the gMSA account will be added to the group, and the group will be allowed to retrieve the managed password. The example below creates a new gMSA credential called "gMSA-MID" and allows the aforementioned group to retrieve the managed password.
New-ADServiceAccount -Name "gMSA-MID" -principalsAllowedToRetrieveManagedPassword "Defender-Identity-gMSA-Access" -DnsHostName "gMSA-MID.Wingtiptoys.ca"
We should make sure that the Test-ADService account cmdlet is successful. If you did not all all servers to the group, tried to test on a server and then had to add it to the group then you may require a server restart to clear out Kerberos tickets or purge the system context by running
Klist.exe -Li 0x3e7 Purge
Test-ADServiceAccount gMSA-MID
This is an example that ended with success - the result $True was displayed.
Note that if we run the same command on a server that does NOT have access to the gMSA managed password then you should see this:
WARNING: Test failed for Managed Service Account gMSA-MID. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA operational log for more information.
Now that the gMSA has been created, let's continue on!
Get started
Once the MDI instance has been created we can continue the configuration. The wizard is at:
https://wingtiptoyscanada.atp.azure.com/timeline
Note: Integration with Cloud app security has been turned on, click here to Learn more)
In order for MDI to access AD we must provide directory access credentials. This is required to read objects in AD. this is a read only permission, no write permissions are required.
It is possible to use a gMSA. This is the recommended configuration as you will not have to manually rotate the secret for the account. Windows will do that automatically. There will be a bit more work to allow all DCs access to the gMSA but is so worth it.
Enter the credentials into the relevant box.
Recommended to setup a gMSA for this purpose, and if you are using a gMSA then ensure that the option was selected.
You can read more here: Connect Microsoft Defender for Identity to Active Directory quickstart | Microsoft Docs
Next up is to install the first sensor. But before we do that, let's pre-create the service account.
Installing Sensor On Windows 2012 R2 DC
Now that the tenant has been setup, we can start installing the sensors. The preferred option is to install the sensor directly onto the DC. Where there is a standalone option, this adds network complexity and has fewer detections since it does not have access to all of the data. Installing directly onto the DC means that we do not have to switch port mirroring etc. It does meant that the DC has to be correctly sized though!
After downloading the sensor package from the tenant we can run the installed.
We are installing direct onto the DC. This is why the other options are greyed out.
Note the installation folder:
C:\Program Files\Azure Advanced Threat Protection Sensor\
You will also need the access key - this is available from the same location that you downloaded the package from.
Paste in the sensor key value, and hit install.
After clicking install the binaries are copied to "C:\Program Files\Azure Advanced Threat Protection Sensor".
The sensor will start to show in the dashboard as it is being installed. Eventually it should reach a running and healthy state.
After install has completed, restart the server and ensure that the service has started. Note that it still has the Azure ATP name.
Installing To AD FS
Note that AD FS support was added in January 2021 so that Defender for Identity can help protect AD FS as part of the Sun Burst security issues/
For the release details, please see: Microsoft Defender for Identity expands support to AD FS servers
If we then copy the install package to the AD FS servers and run it, note that the sensor type is correctly detected. It also notes that the required audit settings have NOT been configured.
Also, running setup as a standard user generated this error in the AD FS Event Log. EventID 351 in AD FS/Admin
For the search engines:
There was an error getting synchronization properties.
Additional Data
Exception details:
System.ServiceModel.FaultException`1[Microsoft.IdentityServer.Protocols.PolicyStore.AuthorizationFault]: ADMIN0013: AuthorizationFault (Fault Detail is equal to Microsoft.IdentityServer.Protocols.PolicyStore.AuthorizationFault).
Troubleshooting
Known Issues
Refer to the Known Issues section of the documentation
Troubleshooting Microsoft Defender for Identity Known Issues
MDI Logging
The logging folder will also help troubleshoot issues. Note that the exact folder will be version specific.
%programfiles%\Azure Advanced Threat Protection Sensor\<version>\Logs\
Access to gMSA Credential
Ensure that all of the domain controllers have access to the gMSA credential. If not, then you will get something like this:
2021-02-09 00:39:47.6405 Error Enumerable System.InvalidOperationException: Sequence contains no elements
at TSource System.Linq.Enumerable.First<TSource>(IEnumerable<TSource> source)
at void Microsoft.Tri.Sensor.DomainNetworkCredentialsManager.UpdateConfigurations(ConfigurationCollection configurations)
Also ensure that the gMSA option is enabled in the MDI settings:
AD FS Sensor - Not Configured To Log Audit Events
You may receive this error on the AD FS servers.
To remediate that issue, ensure that these steps have been followed:
AD FS Troubleshooting - Auditing Events and Logging | Microsoft Docs
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
Assigned user right to Generate Security Events to the AD FS service account, and restarted the server.
Note that you may get this error if you do NOT run the installer as Administrator. That is because it does not have the permissions required to validate the settings. Running as Administrator, allows the installer to check – note that there is no longer a warning.
Cheers,
Rhoderick
