How to implement Defender for Identity and configure all prerequisites

Microsoft Defender for Identity MDI (previously called Azure Advanced Threat Protection or Azure ATP) is a Microsoft security solution that captures signals from Domain Controllers. MDI is a cloud-based security solution that leverages on-premises Active Directory signals for detecting identity attacks.

I often see environments where Defender for Identity is installed; however, not under the right conditions with all recommended audit events and permissions.

This blog is focussing on Domain Controllers; ADFS is out of scope. Defender for Identity response actions are explained earlier; Use Microsoft Defender for Identity Response Actions for on-premises AD accounts 

Blog information: Blog published: October 4, 2022 Blog latest updated: October 10, 2022

Introduction

Microsoft Defender for Identity works based on four security pillars:

• Prevent
• Detect
• Investigate
• Respond

Defender for Identity monitors the domain controllers by capturing and parsing network traffic and using the Windows events directly from the domain controllers. With the use of profiling, deterministic detection, machine learning, and behavioral algorithms Defender for Identity learns from the environment and enables the detection of anomalies.

Defender for identity security posture assessment can detect vulnerabilities such as,

• Exposing credentials in clear text
• Legacy protocols in use
• Unsecure Kerberos delegation
• Dormant accounts in sensitive groups
• Weaker cipher usage
• Print spooler service in Domain controllers
• Not managing local administrator accounts centrally (Microsoft LAPS)
• Lateral movement paths
• Unmonitored domain controllers
• Unsecure Account attributes
• Unsecure SID history attributes

Components

Defender for Identity consist of the following components:

• Microsoft 365 Defender portal: MDI is integrated into the Microsoft 365 Defender portal
• Defender for Identity sensor: Sensor is installed on Domain Controllers for monitoring all traffic
• Defender for Identity cloud services: Separate environment hosted in Azure. MDI cloud service runs on Azure infra and is connected with the security graph.

Defender for Identity viewed from a simplified view. Image source: Microsoft

The MDI Sensor contains a couple of core functionalities that are critical for getting MDI onboarded. The installed sensor is responsible for the following activity:

• Capture and inspect domain controller network traffic (local traffic of the domain controller)
• Receive Windows Events directly from the domain controllers
• Receive RADIUS accounting information from your VPN provider
• Retrieve data about users and computers from the Active Directory domain
• Perform resolution of network entities (users, groups, and computers)
• Transfer relevant data to the Defender for Identity cloud service

More MDI information can be found here: Microsoft Defender for Identity architecture & What is Microsoft Defender for Identity?

---

Preparation of the environment

Preparation before deploying any sensors is important. First, we need to match all prerequisites:

License

Licensing is user-based. Common mistake; purchase licenses based on the sensor count. Defender for Identity is user-based counted on the AzureAD users. The following licenses are available;

• Enterprise Mobility + Security E5/A5
• Microsoft 365 A5/ E5/ G5
• Microsoft 365 A5/ E5/ G5/ F5 Security license.

Accounts

• Directory Service account (gMSA recommended)

Network

• Sensors able to reach Defender for Identity Cloud service
• Specific ports allowed from Defender for Identity sensors in the environment
• Network Name Resolution requirements enabled

Audit

• Enable audit policies
• Enable audit policies for Event ID 8004
• Enable audit policies for Event ID 1644
• Enable object auditing
• Enabled optionally exchange auditing

---

Create Directory Service account (gMSA account)

Defender for Identity supports two types of Directory Service accounts (gMSA and regular user account) – it is heavily advised to use the more secure Group Managed Service Account in the environment. With the use of gMSA DSA Active Directory manages the creation and rotation of the account password.

For more information and multi-forest environments see; Microsoft Defender for Identity Directory Service account recommendations | Microsoft Docs

KDS root key

It is needed to create a KDS root key. When the KDS root key is already available, no further action is required for the KDS root key. The KDS root key is used to generate passwords for AD Managed Service Accounts.

When there is no KDS root key; it is needed to wait 10 hours before creating the gMSA-account.

Validation of the root key is possible using the command: Get-KDSRootKey/ Get-KDSConfiguration. For creating the root key use the following PowerShell command:

Add-KdsRootKey -EffectiveImmediately 

More information: Create the Key Distribution Services KDS Root Key | Microsoft Docs

Create gMSA account

For the gMSA account all domain controllers with the sensor must have managed password permission/right on the gMSA account. This can be created with a custom group/ single entries or default Domain Controller group. For allowing access the PrincipalsAllowedToRetrieveManagedPassword is needed which ensures that all Domain Controllers will be able to retrieve the password for the accounts.

The sensor with the name ( Azure Advanced Threat Protection Sensor) service runs as LocalService. Sometimes when the Log on as a service policy is configured – it is needed to add the gMSA account to the list of accounts that can log on as a service. NOTE: Only needed for Domain Controllers.

gMSA can be created with the following PowerShell command. Recommended is to use Kerberos encryption type AES256 and optionally -ManagedPasswordIntervalInDays parameter.

New-ADServiceAccount -Name MDIGMSA -DNSHostName MDIGMSA.m365securitylab.local –Description "Microsoft Defender for Identity service account" –KerberosEncryptionType AES256 –ManagedPasswordIntervalInDays 30

Get gMSA details:

Get-ADServiceAccount MDIGMSA -Properties * | fl DNSHostName, SamAccountName, KerberosEncryptionType, ManagedPasswordIntervalInDays, PrincipalsAllowedToRetrieveManagedPassword

Validation of the server has the required permission to retrieve the gMSA password can be validated using the following PowerShell command:

Test-ADServiceAccount -Identity 'MDIGMSA'

---

Enable audit events

Defender for Identity relies heavily on Windows Event log entries to enhance detections and provide additional information. It is needed to assign the recommended audit event policy to the Domain Controllers.

Recommended is to not use the built-in Domain Controllers policy and create a separate policy.

Windows Event collection

Go to : Computer Configuration > Policies > Windows Settings > Security Settings -> Advanced Audit Policy Configuration > Audit Policies

Configure the following table for success and failure:

Audit policy	Subcategory	Triggers event IDs
Account Logon	Audit Credential Validation	4776
Account Management	Audit Computer Account Management	4741, 4743
Account Management	Audit Distribution Group Management	4753, 4763
Account Management	Audit Security Group Management	4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758
Account Management	Audit User Account Management	4726
DS Access	Audit Directory Service Access	4662 – For this event. Object auditing is needed
DS Access	Audit Directory Service Changes	5136
System	Audit Security System Extension	7045

Example configuration for audit computer account management:

More information: Configure Windows Event collection

Event ID 8004

Go to: Computer Configuration > Policies > Windows Settings > Security Settings ->Local Policies -> Security Operation

Configure the following security policies:

Security policy setting	Value
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	Audit all
Network security: Restrict NTLM: Audit NTLM authentication in this domain	Enable all
Network security: Restrict NTLM: Audit Incoming NTLM Traffic	Enable auditing for all accounts

Event ID 1644

Event ID 1644 is recommended for LDAP search events. Logging EventID 1644 can result in server performance impact. Important; the resource limitation part of the MDI sensor is not stopping the event collection. Make sure there are enough memory/ CPU and disk resources available.

For Event 1644 is it needed to configure the following registry keys on the domain controllers:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"15 Field Engineering"=dword:00000005

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Expensive Search Results Threshold"=dword:00000001
"Inefficient Search Results Threshold"=dword:00000001
"Search Time Threshold (msecs)"=dword:00000001

Configure object auditing – 4662 events

For collecting 4662 events – it is needed to configure object auditing on the following objects:

• Descendant Group Objects
• Descendant User objects
• Descendant Computer Objects
• Descendant msDS-GroupManagedServiceAccount Objects
• Descendant msDS-ManagedServiceAccount Objects

Microsoft described the enablement for object auditing for all descendant objects. Use the Microsoft instructions for enabling the recommended set of permissions. Configure object auditing.

Additional configure Exchange auditing when Exchange is currently configured.

---

Additional Permissions

Defender for Identity requires additional permissions for allowing remote calls to SAM and permissions to the selected object’s container in AD.

Configure SAM-R

For lateral movement path detection, MDI relies on the SAM-R protocol configuration. The queries are performed with the SAM-R protocol.

Important: Apply the remote calls to SAM policy to all computers except domain controllers. The policy can break application that uses AuthZ interface. Source

It is needed to allow the Defender for Identity Directory service account for performing SAM-R. For configuring:

1. Go to: Computer Configuration > Policies > Windows Settings > Security Settings ->Local Policies -> Security Operation
2. Open the policy: Network access – Restrict clients allowed to make remote calls to SAM
3. Allow the earlier created gMSA account
4. Deploy the GPO to all computers except domain controllers

Deleted Objects container permissions

gMSA account should have read-only permissions on the Deleted Objects container in AD. This allows Defender for Identity to detect user deletions from your Active Directory.

When not already enabled; enable the recycle bin feature and grant the MDI service account read and list permissions.

For enabling:

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target (Get-ADDomain).DNSRoot -Confirm:$false

Adding permissions for the specific gmsaacountname:

dsacls "CN=Deleted Objects,$((Get-ADDomain).DistinguishedName)" /takeownership
dsacls "CN=Deleted Objects,$((Get-ADDomain).DistinguishedName)" /g "$((Get-ADDomain).NetBIOSName)\gmsaaccountname`$:LCRP"

---

Capacity planning & hardware optimization

NOTE: Run capacity planning before installing the Defender for Identity sensors and after configuring all events. The event set enables more load on the servers.

It is critical to enable enough capacity for Defender for Identity on the Domain Controllers. Microsoft released the Defender for Identity Sizing Tool for checking traffic information.

Run the TriSizingTool.exe for some time and check the results. The Busy Packets/sec value is needed. Map the actual Busy Packets/sec value with the Packets per second recommendation.

• Download the Defender for Identity Sizing tool here
• Check the recommended sensor sizing here

For 75-100k packages, the recommendation is 7.50 CPU/ Cores and 13.50 Memory/GB for only the sensor consumption.

More information: Plan capacity for Microsoft Defender for Identity

Hardware

For healthy sensors, the following is recommended:

• No hyper-threaded cores
• Enable the Power Option to High Performance

When running the sensor as a virtual machine, it is recommended to assign all memory to the machine at all times. Memory ballooning or Dynamic Memory is not recommended and can result in health issues.

For Hyper-V ensure that Enable Dynamic Memory isn’t enabled for the VM. For VMware ensure that the amount of memory configured and the reserved memory is the same or configure – reserve all guest memory

More information: Server specifications

IPv4 TSO offload

When using Defender for Identity on VMware virtual machines, sometimes the health alert “Some network traffic is not being analyzed” is visible. For resolving the issue in Vmware it is recommended to disable IPv4 TSO Offload.

Validate of LSO is enabled:

Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"

When the display value is reporting enabled for the Large Send offload it is recommended to disable LSO. (These actions might cause a brief loss of network connectivity and requires a reboot of the machine)

Disable LSO:

Disable-NetAdapterLso -Name {name of adapter}

---

Network

Defender for Identity requires some network requirements for portal connectivity and internal connectivity.

Important is correct connectivity for internal ports and localhost ports. Microsoft explains are required ports here; Defender for Identity Ports | Microsoft Docs.

Network Name Resolution (NNR)

Network Name Resolution (NNR) is one of the main components and critical for Defender for Identity. NNR is needed for resolving IP addresses to computer names. The sensor looks up the IP address using the following methods part of the NNR:

• NTLM over RPC (TCP Port 135)
• NetBIOS (UDP port 137)
• RDP (TCP port 3389) – only the first packet of Client hello
• Queries the DNS server using reverse DNS lookup of the IP address (UDP 53)

Protocol	Method	Transport	Port	From	To
NTLM over RPC	Primary	TCP	Port 135	Defender for Identity sensor	All devices on network
NetBIOS	Primary	UDP	137	Defender for Identity sensor	All devices on network
RDP	Primary	TCP	3389, only the first packet of Client hello	Defender for Identity sensor	All devices on network
DNS	Secondary	TCP and UDP	53	Defender for Identity sensor	DNS Servers

Microsoft recommends using all of the available methods; when not possible – use the DNS Lookup method and at least one of the other methods.

The secondary DNS lookup of the IP address is only performed when there is no response from any of the primary methods or there is a conflict in the response received from two or more primary methods.

NNR data is crucial for detecting the following threats:

• Suspected identity theft (pass-the-ticket)
• Suspected DCSync attack (replication of directory services)
• Network mapping reconnaissance (DNS)

More information: What is Network Name Resolution?

---

Onboard Defender for Identity instance

The Defender for Identity cloud service, available within the U.S., Europe, and Asia, runs on Azure infrastructure. To use the cloud services; go to security.microsoft.com -> Settings -> Identities or go to security.microsoft.com/settings/identities

When opening the identities section for the first time it will create the Defender for Identity instance.

Create Directory account connection

• Go to Directory Sensor accounts
• Click Add Credentials
• Fill in the account name(gMSA account) and domain. Enable the checkbox; Group managed service account when using gMSA. For the domain, it is important to use the full FQDN of the domain where the gMSA account is located.

More information: https://learn.microsoft.com/en-us/defender-for-identity/directory-service-accounts

Onboard Sensor

After connecting the Directory service account it is possible to onboard the first Sensor. Open the Sensors view and click on Add sensor. Download the installer package and copy the Access key.

Important: The access key is only needed during the sensor installation and can be regenerated without any impact. When completed the sensor onboarding – it is recommended to reset the access key by clicking “Regenerate key”

Now we can use the downloaded “Azure ATP Sensor setup.exe” for installing the sensor on the Domain Controller. MDI requires .NET Framework 4.7 or later. When there is no .NET Framework 4.7 installed it will be part of the installation which may require a reboot.

Defender for Identity requires the Npcap driver, for new installation Npcap is part of the installation.

Important to allow network communication from the domain controllers to the Defender for Identity service IPs.

Check of the AATPSensor and AATPSensorUpdater services are running.

---

Configure Defender for Identity sensor

After onboarding, the sensor is visible in the security.microsoft.com portal. Additional configuration is possible. For each sensor the following options are available:

• Enable delayed updated
• Configure additional network adapters
• Configure description

Delayed update

Defender for Identity releases rapidly new updates and features. When used in production it can be advised to configure a sort of deployment ring for the initial test and larger gradual update process. With the delayed update it is possible to delay the updates automatically.

Sensors not selected for the delayed update are updated automatically. When enabled Delayed update there is a delay of 72 hours.

Description

Add optional a description for the Defender for Identity sensor:

---

Validate

Validate MDI prerequisites

With the use of the test-MDIReadiness.ps1 script it is possible to detect misconfigured environments. The script will check for Object Auditing, Exchange Auditing, ADFS Auditing, Advanced Audit Policy Configuration/ NTLM auditing/ Power scheme/ Root certificates. Part of the result is the JSON file and HTML file.

The script can be downloaded from GitHub

Validate sensor/ installation

For validating Defender for Identity sensors check the following items:

• Check that the service; Azure Advanced Threat Protection sensor is correctly running
• Validate in the portal of the Defender for Identity sensor is correctly reporting

The following logs can be used for the Sensor validation. Default Location: C:\Program Files\Azure Advanced Threat Protection Sensor\version number\Logs

Log	Description
Microsoft.Tri.Sensor.log	All logs related to the Defender for Identity sensor.
Microsoft.Tri.Sensor-Errors.log	This log contains just the errors that are caught by the Defender for Identity sensor.
Microsoft.Tri.Sensor.Updater.log	This log is used for the sensor updater process, which is responsible for updating the Defender for Identity sensor
Microsoft.Tri.Sensor.Updater-Errors.log	This log contains just the errors that are caught by the Defender for Identity sensor updater.

Validate data

Validation of data is possible with the use of the security.microsoft.com portal. Use the search user or activity log (filtered for app Active Directory).

The old Defender for Identity portal; https://portal.atp.azure.com/ can be still used for checking devices and other events. Search for users/ computers or other objects:

Health alerts

Check the health alerts. After some time Defender for Identity reports possible health alerts based on the actual configuration. Examples of health alerts;

• All domain controllers are unreachable by a sensor
• All/Some of the capture network adapters on a sensor are not available
• Directory services user credentials are incorrect
• Low success rate of active name resolution
• No traffic received from domain controller
• Read-only user password to expire shortly
• Read-only user password expired
• Sensor outdated
• Sensor reached a memory resource limit
• Sensor service failed to start
• Sensor stopped communicating
• Some domain controllers are unreachable by a sensor
• Some Windows events are not being analyzed
• Some network traffic could not be analyzed
• Some ETW events are not being analyzed
• Sensor with Windows Server 2008 R2: Will be unsupported soon
• Sensor with Windows Server 2008 R2: Unsupported
• Sensor has issues with packet capturing component

For viewing the health alerts go to: Security.Microsoft.com -> Settings -> Identities -> Health issues.

Recommended is to configure the Health issues notification for receiving any new health alerts. Open Health issues notification for the configuration and add the recipient email.

---

MDI Learning period

Defender for Identity requires a machine learning period. Important to give MDI some time for learning and detection of known behaviors and learning patterns.

MDI uses the following learning period timeframe in days:

Detection	Learning period in days
Network mapping reconnaissance (DNS)	8 days
Security principal reconnaissance (LDAP)	15 days
User and group membership reconnaissance (SAMR)	28 days
Suspected brute force attack	7 days
Suspected Golden Ticket usage	5 days
Suspicious additions to sensitive groups	28 days starting from the first event
Data exfilitration over SMB	15 days
Suspicious VPN connection	30 days from the first VPN connection, and at least 5 VPN connections in the last 30 days, per user.

---

Simulating alerts

For validating of Defender for Identity is correctly working there are some Attack simulations/playbooks explained.

Network mapping reconnaissance (DNS)

Run the following command prompt on a workstation part of the domain:

nslookup 
server m365securitylab.local
ls -d m365securitylab.local

Result: Alert with the title; Network mapping reconnaissance (DNS)

User and IP address reconnaissance

Download netsess and run the following command prompt on a workstation part of the domain:

NetSess.exe m365securitylab.local

Result: Alert with the title; User and IP address reconnaissance (SMB)

User and group membership reconnaissance (SAMR)

Run the following command line on a workstation part of the domain:

net user /domain 
net group /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain 
net group "Schema Admins" /domain

Result: Alert with the title; User and group membership reconnaissance (SAMR)

Malicious request of Data Protection API (DPAPI) master key

Run the following command line on a workstation part of the domain:

mimikatz # privilege::debug
mimikatz # lsadump::backupkeys /system:m365securitylab.local /export 

Result: Alert with the title; Malicious request of Data Protection API (DPAPI) master key

More attack simulations can be found here: Attack simulations for Microsoft Defender for Identity

Microsoft explains more in-depth attacks in available playbooks for Reconnaissance, Lateral movement, and Domain dominance.

View the available alert overview here: Microsoft Defender for Identity Security Alerts

---

Sources

Microsoft: What is Defender for identity

Microsoft: Microsoft Defender for Identity Security Alerts