This article provides a list of frequently asked questions and answers about Microsoft Defender for Identity divided into the following categories:
What is Defender for Identity?
What can Defender for Identity detect?
Defender for Identity detects known malicious attacks and techniques, security issues, and risks against your network. For the full list of Defender for Identity detections, see What detections does Defender for Identity perform?.
What data does Defender for Identity collect?
Defender for Identity collects and stores information from your configured servers (domain controllers, member servers, etc.) in a database specific to the service for administration, tracking, and reporting purposes. Information collected includes network traffic to and from domain controllers (such as Kerberos authentication, NTLM authentication, DNS queries), security logs (such as Windows security events), Active Directory information (structure, subnets, sites), and entity information (such as names, email addresses, and phone numbers).
Microsoft uses this data to:
- Proactively identify indicators of attack (IOAs) in your organization
- Generate alerts if a possible attack was detected
- Provide your security operations with a view into entities related to threat signals from your network, enabling you to investigate and explore the presence of security threats on the network.
Microsoft does not mine your data for advertising or for any other purpose other than providing you the service.
How many Directory Service credentials does Defender for Identity support?
Defender for Identity currently supports adding up to 30 different Directory Service credentials to support Active Directory environments with untrusted forests. If you require more accounts, open a support ticket.
Does Defender for Identity only leverage traffic from Active Directory?
In addition to analyzing Active Directory traffic using deep packet inspection technology, Defender for Identity also collects relevant Windows Events from your domain controller and creates entity profiles based on information from Active Directory Domain Services. Defender for Identity also supports receiving RADIUS accounting of VPN logs from various vendors (Microsoft, Cisco, F5, and Checkpoint).
Does Defender for Identity monitor only domain-joined devices?
No. Defender for Identity monitors all devices in the network performing authentication and authorization requests against Active Directory, including non-Windows and mobile devices.
Does Defender for Identity monitor computer accounts as well as user accounts?
Yes. Since computer accounts (as well as any other entities) can be used to perform malicious activities, Defender for Identity monitors all computer accounts behavior and all other entities in the environment.
What is the difference between Advanced Threat Analytics (ATA) and Defender for Identity?
ATA is a standalone on-premises solution with multiple components, such as the ATA Center that requires dedicated hardware on-premises.
Defender for Identity is a cloud-based security solution that leverages your on-premises Active Directory (Azure AD) signals. The solution is highly scalable and is frequently updated.
In contrast to the ATA sensor, the Defender for Identity sensor also uses data sources such as Event Tracing for Windows (ETW) enabling Defender for Identity to deliver additional detections.
Defender for Identity’s frequent updates include the following features and capabilities:
- Support for multi-forest environments: Provides organizations visibility across AD forests.
- Identity Security Posture Assessments: Identifies common misconfigurations and exploitable components, as well as, providing remediation paths to reduce the attack surface.
- UEBA capabilities: Insights into individual user risk through user investigation priority scoring. The score can assist SecOps in their investigations and help analysts understand unusual activities for the user and the organization.
- Native integrations: Integrates with Microsoft Defender for Cloud Apps and Azure AD Identity Protection to provide a hybrid view of what’s taking place in both on-premises and hybrid environments.
- Contributes to Microsoft 365 Defender: Contributes alert and threat data to Microsoft 365 Defender. Microsoft 365 Defender leverages the Microsoft 365 security portfolio (identities, endpoints, data, and applications) to automatically analyze cross-domain threat data, building a complete picture of each attack in a single dashboard. With this breadth and depth of clarity, defenders can focus on critical threats and hunt for sophisticated breaches, trusting that Microsoft 365 Defender’s powerful automation stops attacks anywhere in the kill chain and returns the organization to a secure state.
Licensing and privacy
Where can I get a license for Microsoft Defender for Identity?
Defender for Identity is available as part of Enterprise Mobility + Security 5 suite (EMS E5), and as a standalone license. You can acquire a license directly from the Microsoft 365 portal or through the Cloud Solution Partner (CSP) licensing model.
Does Defender for Identity need only a single license or does it require a license for every user I want to protect?
For information about Defender for Identity licensing requirements, see Defender for Identity licensing guidance.
Is my data isolated from other customer data?
Yes, your data is isolated through access authentication and logical segregation based on customer identifiers. Each customer can only access data collected from their own organization and generic data that Microsoft provides.
Do I have the flexibility to select where to store my data?
No. When your Defender for Identity instance is created, it is stored automatically in the country data center closest to the geographical location of your AAD tenant. Once your Defender for Identity instance is created, Defender for Identity data cannot be moved to a different data center.
How does Microsoft prevent malicious insider activities and abuse of high privilege roles?
Microsoft developers and administrators have, by design, been given sufficient privileges to carry out their assigned duties to operate and evolve the service. Microsoft deploys combinations of preventive, detective, and reactive controls including the following mechanisms to help protect against unauthorized developer and/or administrative activity:
- Tight access control to sensitive data
- Combinations of controls that greatly enhance independent detection of malicious activity
- Multiple levels of monitoring, logging, and reporting
In addition, Microsoft conducts background verification checks on certain operations personnel, and limits access to applications, systems, and network infrastructure in proportion to the level of background verification. Operations personnel follow a formal process when they are required to access a customer’s account or related information in the performance of their duties.
How many Defender for Identity sensors do I need?
Every domain controller in the environment should be covered by a Defender for Identity sensor or standalone sensor. For more information, see Defender for Identity sensor sizing.
Do we need to install both the Defender for Identity sensor and the Defender for Endpoint sensor on domain controllers or Active Directory Federation Services (AD FS) servers?
If you use both products, then to protect both the server and Active Directory, the two sensors must be installed.
Does Defender for Identity work with encrypted traffic?
Network protocols with encrypted traffic (for example, AtSvc and WMI) are not decrypted, but are analyzed by the sensors.
Does Defender for Identity work with Kerberos Armoring?
Enabling Kerberos Armoring, also known as Flexible Authentication Secure Tunneling (FAST), is supported by Defender for Identity, with the exception of over-pass the hash detection, which does not work with Kerberos Armoring.
How do I monitor a virtual domain controller using Defender for Identity?
Most virtual domain controllers can be covered by the Defender for Identity sensor, to determine whether the Defender for Identity sensor is appropriate for your environment, see Defender for Identity Capacity Planning.
If a virtual domain controller can’t be covered by the Defender for Identity sensor, you can have either a virtual or physical Defender for Identity standalone sensor as described in Configure port mirroring. The easiest way is to have a virtual Defender for Identity standalone sensor on every host where a virtual domain controller exists. If your virtual domain controllers move between hosts, you need to perform one of the following steps:
- When the virtual domain controller moves to another host, preconfigure the Defender for Identity standalone sensor in that host to receive the traffic from the recently moved virtual domain controller.
- Make sure that you affiliate the virtual Defender for Identity standalone sensor with the virtual domain controller so that if it is moved, the Defender for Identity standalone sensor moves with it.
- There are some virtual switches that can send traffic between hosts.
How do I configure the Defender for Identity sensors to communicate with Defender for Identity cloud service when I have a proxy?
For your domain controllers to communicate with the cloud service, you must open: *.atp.azure.com port 443 in your firewall/proxy. For instructions on how to do this, see Configure your proxy or firewall to enable communication with Defender for Identity sensors.
Can Defender for Identity monitored domain controllers be virtualized on your IaaS solution?
Yes, you can use the Defender for Identity sensor to monitor domain controllers that are in any IaaS solution.
Can Defender for Identity support multi-domain and multi-forest?
Defender for Identity supports multi-domain environments and multiple forests. For more information and trust requirements, see Multi-forest support.
Can you see the overall health of the deployment?
Yes, you can view the overall health of the deployment as well as specific issues related to configuration, connectivity etc., and you are alerted as they occur with Defender for Identity health alerts.
How do I grant access to the AD FS database via TSQL or PowerShell?
Instead of using SQL Server Management Studio, you can grant access to the AD FS database either through TSQL or through PowerShell. For example, if you’re using the Windows Internal Database (WID) or an external SQL server, these commands can be helpful.
To grant access for the sensor to the AD FS database using TSQL:
USE [master] CREATE LOGIN [DOMAIN1\triservice] FROM WINDOWS WITH DEFAULT_DATABASE=[master] USE [AdfsConfigurationV4] CREATE USER [DOMAIN1\triservice] FOR LOGIN [DOMAIN1\triservice] ALTER ROLE [db_datareader] ADD MEMBER [DOMAIN1\triservice] GRANT CONNECT TO [DOMAIN1\triservice] GRANT SELECT TO [DOMAIN1\triservice] GO
To grant access for the sensor to the AD FS database using PowerShell:
$ConnectionString = 'server=\\.\pipe\MICROSOFT##WID\tsql\query;database=AdfsConfigurationV4;trusted_connection=true;' $SQLConnection= New-Object System.Data.SQLClient.SQLConnection($ConnectionString) $SQLConnection.Open() $SQLCommand = $SQLConnection.CreateCommand() $SQLCommand.CommandText = @" USE [master]; CREATE LOGIN [DOMAIN1\triservice] FROM WINDOWS WITH DEFAULT_DATABASE=[master]; USE [AdfsConfigurationV4]; CREATE USER [DOMAIN1\triservice] FOR LOGIN [DOMAIN1\triservice]; ALTER ROLE [db_datareader] ADD MEMBER [DOMAIN1\triservice]; GRANT CONNECT TO [DOMAIN1\triservice]; GRANT SELECT TO [DOMAIN1\triservice]; GO; "@ $SqlDataReader = $SQLCommand.ExecuteReader() $SQLConnection.Close()
- [DOMAIN1\triservice] — the directory services user of the workspace
- AdfsConfigurationV4 — the name of the AD FS database (may vary)
- server=.\pipe\MICROSOFT##WID\tsql\query — the connection string to the database if you are using WID
- If you don’t know your AD FS connection string, see To acquire the SQL connection string.
WinPcap and Npcap drivers
What recommendations about WinPcap and Npcap drivers are changing?
The Microsoft Defender for Identity team is currently recommending that all customers deploy the Npcap driver before deploying the sensor. This will ensure that Npcap driver will be used instead of the WinPcap driver.
Why are we moving away from WinPcap?
WinPcap is no longer supported and since it’s no longer being developed, the driver cannot be optimized any longer for the Defender for Identity sensor. Additionally, if there is an issue in the future with the WinPcap driver, there are no options for a fix.
Npcap is supported, while WinPcap is no longer a supported product.
What version of Npcap is supported?
The recommended and officially supported version of Npcap is version 1.00. Other versions are not supported.
What additional benefits will we get by using Npcap?
The Defender for Identity team has been working closely with the Npcap team over the last months to ensure optimal performance of the sensor. The Npcap driver will provide better performance and stability over the WinPcap driver.
I have more than 5 domain controllers in my organization. Do I need to purchase an Npcap license if I’m using Npcap on these domain controllers?
No, Npcap has an exemption to the usual limit of 5 installs. You can install it on unlimited systems where it is only used with the Defender for Identity sensor.
See the Npcap license agreement here, and search for Microsoft Defender for Identity.
Is Npcap also relevant for ATA?
No, only the Microsoft Defender for Identity sensor supports Npcap version 1.0.
I would like to script the deployment of Npcap, do I need to purchase the OEM version?
No, you don’t need to purchase the OEM version. Download the sensor installation package version 2.156 and above from the Defender for Identity console, which includes the OEM version of Npcap.
How do I download and install the Npcap driver?
- You can obtain the NPCAP executables by downloading the latest deployment package of the MDI sensor.
Copies of Npcap don’t count towards the five copy, five computer, or five user licensing limitation if they’re installed and used solely in conjunction with Defender for Identity. For more information, see Npcap licensing.
- If you haven’t yet installed the sensor:
- Uninstall WinPcap, if it was installed.
- Install Npcap with the following options: /loopback_support=no and /winpcap_mode=yes and /S for a silent install. Do NOT use the
- If using the GUI installer, deselect the loopback support and select WinPcap mode. Make sure the option Restrict Npcap driver’s access to Administrators only is deselected.
- If you already installed the sensor with WinPcap and need to update to use Npcap:
- Uninstall the sensor.
- Uninstall WinPcap.
- Install Npcap with the following options: loopback_support=no and winpcap_mode=yes. Do NOT use the
- Reinstall the sensor.
What kind of integration does Defender for Identity have with SIEMs?
Defender for Identity can be configured to send a Syslog alert, to any SIEM server using the CEF format, for health alerts and when a security alert is detected. See the SIEM log reference for more information .
Why are certain accounts considered sensitive?
This happens when an account is a member of groups that are designated as sensitive (for example: “Domain Admins”).
To understand why an account is sensitive you can review its group membership to understand which sensitive groups it belongs to (the group that it belongs to can also be sensitive due to another group, so the same process should be performed until you locate the highest level sensitive group). You can also manually tag accounts as sensitive.
Do you have to write your own rules and create a threshold/baseline?
With Defender for Identity, there is no need to create rules, thresholds, or baselines and then fine-tune. Defender for Identity analyzes the behaviors among users, devices, and resources, as well as their relationship to one another, and can detect suspicious activity and known attacks quickly. Three weeks after deployment, Defender for Identity starts to detect behavioral suspicious activities. On the other hand, Defender for Identity will start detecting known malicious attacks and security issues immediately after deployment.
Which traffic does Defender for Identity generate in the network from domain controllers, and why?
Defender for Identity generates traffic from domain controllers to computers in the organization in one of three scenarios:
- Network Name resolution Defender for Identity captures traffic and events, learning and profiling users and computer activities in the network. To learn and profile activities according to computers in the organization, Defender for Identity needs to resolve IPs to computer accounts. To resolve IPs to computer names Defender for Identity sensors request the IP address for the computer name behind the IP address.
Requests are made using one of four methods:
- NTLM over RPC (TCP Port 135)
- NetBIOS (UDP port 137)
- RDP (TCP port 3389)
- Query the DNS server using reverse DNS lookup of the IP address (UDP 53)
After getting the computer name, Defender for Identity sensors cross check the details in Active Directory to see if there is a correlated computer object with the same computer name. If a match is found, an association is made between the IP address and the matched computer object.
- Lateral Movement Path (LMP) To build potential LMPs to sensitive users, Defender for Identity requires information about the local administrators on computers. In this scenario, the Defender for Identity sensor uses SAM-R (TCP 445) to query the IP address identified in the network traffic, in order to determine the local administrators of the computer. To learn more about Defender for Identity and SAM-R, See Configure SAM-R required permissions.
- Querying Active Directory using LDAP for entity data Defender for Identity sensors query the domain controller from the domain where the entity belongs. It can be the same sensor, or another domain controller from that domain.
|LDAP||TCP and UDP||389||Domain controllers||Outbound|
|Secure LDAP (LDAPS)||TCP||636||Domain controllers||Outbound|
|LDAP to Global Catalog||TCP||3268||Domain controllers||Outbound|
|LDAPS to Global Catalog||TCP||3269||Domain controllers||Outbound|
Why don’t activities always show both the source user and computer?
Defender for Identity captures activities over many different protocols. In some cases, Defender for Identity doesn’t receive the data of the source user in the traffic. Defender for Identity attempts to correlate the session of the user to the activity, and when the attempt is successful, the source user of the activity is displayed. When user correlation attempts fail, only the source computer is displayed.
What should I do if the Defender for Identity sensor or standalone sensor doesn’t start?
Look at the most recent error in the current error log (Where Defender for Identity is installed under the “Logs” folder).