Microsoft Defender for Identity requires an on-premises Active Directory environment

Welcome to Planning for Microsoft Defender for Identity. In this lesson, we’ll take a look at some of the key requirements and prerequisites that you must meet before deploying and using Microsoft Defender for Identity.

To create a Defender for Identity instance, it shouldn’t be a surprise that you'll need an Azure AD tenant with at least one global admin or one security admin. As far as the on-prem Active Directory goes, each Defender for Identity instance supports a multiple Active Directory forest boundary. I should also mention, however, that Defender for Identity requires a Forest Functional Level of Windows 2003 and above. In most environments, I can’t see this being an issue – but – I just wanted to mention it.

To deploy and use Defender for Identity, you need to own either an Enterprise Mobility + Security E5 license, a license for Microsoft 365 E5, A5,or G5, or a Microsoft 365 E5, A5, or G5 Security license. You can get these directly via the Microsoft 365 portal, or you can get them via the CSP licensing model. Standalone Defender for Identity licenses are also available.

Before deploying Defender for Identity, you should identify the AD domain controllers that you plan to install sensors on. These DCs will need to have internet connectivity so that the sensors can talk to the Defender for Identity Cloud Service. Since the Defender for Identity sensor supports the use of a proxy, if you use a proxy for internet access, that should work.

You’ll also need either a standard AD user account or a group managed service account, or gMSA. These accounts need read access to all objects in the monitored domains. A standard AD user account is required for sensors running on Windows Server 2008 R2 SP1 DCs. A group Managed Service Account can be used for DCs running Windows Server 2012 or above. If you use a gMSA, all installed sensors must have permissions to retrieve the gMSA account's password.

The table on your screen shows which accounts can be used with which operating systems.

While Microsoft recommends using a gMSA account for Windows Server 2012 and above, it should be noted that if you have some sensors running on Windows Server 2008 R2 and others running on Windows Server 2012 or above, you must use at least one standard AD user account in addition to the recommended gMSA account.

I should also mention that if you try to install the Defender for Identity sensor on a server with a NIC Teaming adapter, you'll receive an installation error. I don’t want to get down a rathole on the requirements for using NIC teaming with Defender for Identity sensors, but if you wish to read about those requirements, visit the you see on your screen.

Whichever account you use for your sensors, it should have read-only access to the Deleted Objects container in AD, because this allows Defender for Identity to detect user deletions from Active Directory. 

To access the Defender for Identity portal, you need to use a browser that supports TLS 1.2. This includes browsers like Microsoft Edge, IE 11 and later, and Google Chrome 30 and later. You’ll also need a minimum screen width resolution of 1700 pixels to use the portal. In order to communicate with the Defender for Identity cloud service from the portal, you must also ensure port 443 is open in your firewall or proxy to *.atp.azure.com.

Network Name Resolution, or NNR, is a key part of Defender for Identity’s functionality. Because Defender for Identity has to be able to resolve IP addresses to computer names, its sensors look up IP addresses using several methods, including NTLM over RPC, which requires TCP Port 135 to be open, and NetBIOS, which requires UDP port 137 to be open. It also uses RDP on port 3389 for the first packet of Client Hello. And Defender for Identity queries the DNS server using reverse DNS lookup of the IP address over UDP port 53.

For the first three methods to work, those ports need to be opened inbound from the Defender for Identity sensors to the devices on your network. That said, Microsoft recommends using all four methods, when possible. If you can’t allow all four methods, Microsoft recommends using the DNS lookup method plus at least one of the other three methods.

The Defender for Identity sensors can be installed on domain controllers or ADFS servers, per the table on your screen.

Before installing on Windows Server 2019, you must first install KB4487044 or a newer cumulative update. 

I should also mention that the domain controllers you install the sensors on can even be read-only domain controllers.

During the installation of the sensor, .NET Framework 4.7 is installed as part of the process if it isn’t already installed.

As far as disk space goes, you’ll need a minimum of 5 GB of disk space to install the sensor – and while 5GB is the minimum required, Microsoft recommends at least 10 GB.

The Defender for Identity sensor also requires a minimum of 2 CPU cores and 6 GB of RAM on whatever DC its installed on. The Power Option for the server running the Defender for Identity sensor should also be set to High Performance. I should mention, however, that when running the sensor on a virtual machine, all memory for the VM must be allocated to the virtual machine at all times.

It’s also important to note that the servers and DCs with the sensors installed must have their time synchronized to within five minutes of each other. In most organizations, this shouldn’t be a problem, since Active Directory already requires this to function properly.

As far as port requirements go, the table on your screen shows the protocols, transports, ports, and directions that are required for the sensors to operate properly.

By default, localhost to localhost traffic is allowed unless a custom firewall policy blocks it.
One of these ports is required, but Microsoft recommends opening all of them.

To ensure Defender for Identity can audit the needed events, you need to ensure such events are included in the Windows Event log on the DCs being monitored. This is typically achieved via Advanced Audit Policy settings on those DCs. Additionally, you need to ensure that Windows Event 8004 is audited, since this is also needed by the Defender for Identity service. You can ensure this event is audited by configuring NTLM audit settings for the DCs being monitored.

When running sensors on ADFS servers, you need to configure the auditing level on those servers to Verbose. 

And lastly, in order to build a lateral movement path graph, the Defender for Identity sensor uses the Directory service user account to query endpoints in the organization for local admins, using SAM-R, which is otherwise known as network logon. That being the case, you need to configure SAM-R permissions as well.

Since Microsoft recommends the deployment of the Defender for Identity Sensor to achieve full coverage of your environment, we didn’t really look the at Defender for Identity Standalone Sensor. But, in the interest of completeness, I just want to quickly mention it.

The Defender for Identity standalone sensor does not support the collection of Event Tracing for Windows log entries that provide the data for multiple detections.

The Defender for Identity Standalone Sensor can be installed on Windows Server 2012 R2 or on Windows Server 2016, including Server Core. The server you install it on can be either a domain member OR it can belong to a workgroup. The standalone sensor can monitor Domain Controllers with a Domain Functional Level of Windows 2003 and above.

To learn more about the Defender for Identity Standalone Sensor, and its requirements, visit the that you see on your screen.

Does Defender for identity need only a single license or does it require a license for every user I want to protect?

Which Microsoft 365 Defender solution can detect an Active Directory domain compromise?

Does Defender for endpoint require Azure AD?

Which ports need to be open in order for Defender for identity to make use of network name resolution nnr?