Microsoft Defender for Identity frequently asked questions

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?.

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.

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.

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).

No. Defender for Identity monitors all devices in the network performing authentication and authorization requests against Active Directory, including non-Windows and mobile devices.

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.

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.

The final release of ATA is generally available. ATA will end Mainstream Support on January 12, 2021. Extended Support will continue until January 2026. For more information, read our blog.

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.

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.

For information about Defender for Identity licensing requirements, see Defender for Identity licensing guidance.

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.

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.

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.

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.

If you use both products, then to protect both the server and Active Directory, the two sensors must be installed.

Network protocols with encrypted traffic (for example, AtSvc and WMI) are not decrypted, but are analyzed by the sensors.

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.

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.

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.

Yes, you can use the Defender for Identity sensor to monitor domain controllers that are in any IaaS solution.

Defender for Identity supports multi-domain environments and multiple forests. For more information and trust requirements, see Multi-forest support.

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.

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()

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.

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.

The recommended and officially supported version of Npcap is version 1.00. Other versions are not supported.

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.

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.

No, only the Microsoft Defender for Identity sensor supports Npcap version 1.0.

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.

• You can obtain the NPCAP executables by downloading the latest deployment package of the MDI sensor.

   Note

  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:
  1. Uninstall WinPcap, if it was installed.
  2. Install Npcap with the following options: /loopback_support=no and /winpcap_mode=yes and /S for a silent install. Do NOT use the /admin_only option.
     • 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:
  1. Uninstall the sensor.
  2. Uninstall WinPcap.
  3. Install Npcap with the following options: loopback_support=no and winpcap_mode=yes. Do NOT use the /admin_only option.
     • 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.
  4. Reinstall the sensor.

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 .

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.

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.

Defender for Identity generates traffic from domain controllers to computers in the organization in one of three scenarios:

1. 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.

2. 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.
3. 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.

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.

Look at the most recent error in the current error log (Where Defender for Identity is installed under the “Logs” folder).

Source : Official Microsoft Brand
Editor by : BEST Antivirus KBS Team