Introduction
In today’s digital landscape, protecting your organization’s identity infrastructure is more critical than ever. Microsoft Defender for Identity is a robust cloud-based security solution designed to safeguard your on-premises Active Directory (AD) environment. By leveraging advanced analytics and real-time monitoring, it detects and responds to identity-based threats such as credential theft and lateral movement attempts. This guide will walk you through the setup, configuration, and optimization of Microsoft Defender for Identity, ensuring your AD environment is secure and resilient against modern cyber threats.
What is Microsoft Defender for Identity?
Microsoft Defender for Identity is a cloud-based security solution that provides advanced protection for your on-premises Active Directory (AD) environment. It detects and analyzes identity-based attacks, such as credential theft and lateral movement attempts, and helps you respond quickly by correlating AD signals with cloud analytics.
Key Features
- Real-time Monitoring: Detect suspicious activities, such as Pass-the-Hash, Pass-the-Ticket, and other credential theft techniques.
- Behavioral Analytics: Use machine learning to understand the typical behavior of users and entities and flag anomalies.
- Cloud Integration: Integrates with Microsoft 365 Defender for a unified security management experience.
Prerequisites for Microsoft Defender for Identity Setup
Licensing
License Type | Description |
---|---|
Enterprise Mobility + Security E5 (EMS E5/A5) | Comprehensive security suite for enterprise environments. |
Microsoft 365 E5 (Microsoft E5/A5/G5) | Includes advanced security, compliance, and collaboration tools. |
Microsoft 365 E5/A5/G5/F5 Security | Focused on security and compliance features. |
Microsoft 365 F5 Security + Compliance | Requires Microsoft 365 F1/F3 or Office 365 F3 and EMS E3. |
Standalone Defender for Identity License | Specific license for Defender for Identity. |
Permissions
Permission Type | Description |
---|---|
Security Administrator | Required to create and manage the Defender for Identity workspace. |
Directory Service Account | Read access to all objects in the monitored domains. |
Supported Operating Systems
Operating System | Description |
---|---|
Windows Server 2012 R2 | Minimum supported version. |
Windows Server 2016 | Recommended for better performance and features. |
Windows Server 2019 | Latest supported version with enhanced security features. |
Sensor Requirements
Requirement | Description |
---|---|
RAM | Minimum 4 GB |
CPU | At least one core |
Network | Stable connectivity for communication between sensors and the cloud. |
Connectivity Requirements
Port | Description |
---|---|
443 | Communication with the Microsoft Defender for Identity cloud. |
389 | LDAP communication. |
636 | LDAPS communication. |
53 | DNS communication (TCP/UDP) |
88 | Kerberos authentication (TCP/UDP) |
135 | RPC endpoint mapper (TCP) |
445 | SMB (TCP) |
Pre-Checks and New Defender for Identity Module
Before starting the installation, ensure that your environment meets all prerequisites. Microsoft provides a PowerShell module to help automate the configuration processes for domains, domain controllers, and other sensor servers.
Installing the DefenderForIdentity Module:
Install-Module -Name DefenderForIdentity
Importing the Module:
Import-Module DefenderForIdentity
Testing Configuration:
Test-MDIConfiguration -Mode LocalMachine -Configuration All
(this is just to check the configuration – a False will be given as you don’t have anything installed at this point, but we’ll continue this in step 6)
Step-by-Step Installation of Defender for Identity
Step 1: Create a gMSA for the Sensor
Defender for Identity requires a Group Managed Service Account (gMSA). This account ensures the necessary access permissions for monitoring AD activity.
# Create KDS root key for the gMSA (if not existing)
Add-KdsRootKey -EffectiveImmediately
# Create the universal group (if needed)
New-ADGroup -Name "MdiSvcAccountGroup" -GroupScope Universal -GroupCategory Security
# Create the gMSA account, specifying the group as PrincipalsAllowedToRetrieveManagedPassword
New-ADServiceAccount -Name "MdiSvcAccount" -DNSHostName "yourdomain.com" -KerberosEncryptionType AES256 -PrincipalsAllowedToRetrieveManagedPassword "MdiSvcAccountGroup" -ManagedPasswordIntervalInDays 30
# Add the gMSA to the group
Add-ADGroupMember -Identity "MdiSvcAccountGroup" -Members "MdiSvcAccount$"
# Verify the gMSA account
Test-ADServiceAccount -Identity "MdiSvcAccount"
Step 2: Add the gMSA in the Defender for Identity Portal
- Go to the Microsoft 365 Defender portal
- Navigate to Settings > Identities > Directory services accounts
- Enter the account name and domain, then select Save
Step 3: Download and Install the Defender for Identity Sensor
- Download the sensor installer from the Microsoft Defender portal through Settings > Identities > Sensor > Add Sensor
- Install the sensor on your domain controllers. This can be done either through the GUI or silently using PowerShell
GUI Installation:
- Run the installer
- Follow the on-screen steps to choose the installation path
- Enter the access key provided in the portal
Silent Installation:
Use this PowerShell script to automate the installation:
.\Azure ATP sensor Setup.exe /quiet AccessKey="YOUR-ACCESS-KEY"
Step 4: Validate Sensor Installation
After installation, ensure the sensor is communicating with the Defender for Identity cloud service:
- Open the Microsoft 365 Defender portal and navigate to Settings > Identities
- Verify the sensor’s status, ensuring it shows as “Connected” or “Running”
Post-Configuration Setup
Step 5: Validating Defender for Identity configuration
To continue on the early steps you’ve taken on the MDI powershell script, you can now use it to check if the installation is succesful and/or you need to have (more) logging enabled as mentioned in step 6 or 7 (prefer step 7 – as it can directly set all the configuration FOR you).
Running the script:
New-MDIConfigurationReport -Path "C:\Reports" -OpenHtmlReport
Lot of failed checks? Move over to step 6 or 7
Step 6: Configuring Audit Policies (semi-manual way)
Defender for Identity requires specific audit policies to be enabled on domain controllers. You can apply these settings using Group Policy Objects (GPOs) or PowerShell.
https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection
Required Audit Events:
Audit Policy | Event ID | Description |
---|---|---|
Logon Success/Failure | 4624 | A successful logon event |
Logon Success/Failure | 4625 | A failed logon event |
Account Logon Success/Failure | 4776 | The computer attempted to validate credentials |
Logoff Success | 4634 | The user has logged off |
Special Logon | 4672 | A privileged user has logged on |
Process Creation | 4688 | A process has been created |
Directory Service Access | 4662 | Permissions were requested for an object in AD |
Account Creation | 4720 | A user account was created |
Account Deletion | 4726 | A user account was deleted |
Privilege Use | 4673 | A privilege service was called |
Privilege Use | 4674 | A privilege operation was performed |
PowerShell commands to apply Audit Policies:
# Enforce logon auditing
auditpol /set /subcategory:"Logon/Logoff" /success:enable /failure:enable
# Enable account logon auditing
auditpol /set /subcategory:"Account Logon" /success:enable /failure:enable
Step 7: Automate the configuration with PowerShell
Microsoft provides a PowerShell script to automate the configuration of audit policies and other settings, which you’ve used above. You can use this script to automatically all the correct ACL’s and logging.
Running the Configuration Script:
Set-MDIConfiguration -Mode Domain -Configuration AdfsAuditing
Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyCAs
Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyDCs
Set-MDIConfiguration -Mode Domain -Configuration CAAuditing
Set-MDIConfiguration -Mode Domain -Configuration ConfigurationContainerAuditing
Set-MDIConfiguration -Mode Domain -Configuration DomainObjectAuditing
Set-MDIConfiguration -Mode Domain -Configuration NTLMAuditing
Set-MDIConfiguration -Mode Domain -Configuration ProcessorPerformance
Step 8: Re-check the configuration
New-MDIConfigurationReport -Path "C:\Reports" -OpenHtmlReport
Testing the Environment
Simulating Attacks
To verify that Microsoft Defender for Identity is properly configured, simulate common attacks like Pass-the-Hash or Brute-force. Use the Mimikatz tool to extract NTLM hashes and attempt unauthorized access.
Simulating Pass-the-Ticket Attack:
- Use a tool like Mimikatz to extract a Kerberos ticket from a compromised host.
- Inject the ticket into another session to simulate lateral movement.
Validating Detection:
Check the Defender for Identity portal for alerts related to the simulated attack. The detection process should identify the Pass-the-Ticket activity and flag the suspicious behavior.
Additional Configurations: AD FS, AD CS, and Entra Connect
Although Defender for Identity’s primary focus is monitoring Active Directory, it also supports integrating AD FS, AD CS, and Entra Connect for comprehensive identity protection.
AD FS Integration
To monitor AD FS (Active Directory Federation Services) for suspicious authentication events:
- Install the Defender for Identity sensor on the AD FS server.
- Enable verbose auditing on AD FS using PowerShell:
Set-AdfsProperties -AuditLevel Verbose
- Configure read permissions for the AD FS database:
SQL
-- Grant read permissions to the Directory Service Account
GRANT SELECT ON [AdfsConfiguration] TO [domain\gMSA$];
AD CS Integration
Configure AD CS (Active Directory Certificate Services) to monitor certificate-based authentications:
- Enable auditing on the AD CS server:
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
- Install the Defender for Identity sensor on the AD CS server.
Entra Connect Sensor
To monitor Microsoft Entra Connect, ensure that:
- Entra Connect version 2.0 or higher is installed.
- Install the Entra Connect Sensor on the Entra Connect server to capture authentication events between on-prem AD and Azure AD.
Event IDs to Monitor
Defender for Identity relies on key event IDs to detect suspicious behavior. Here’s a list of the most critical ones:
Component | Event ID | Description |
---|---|---|
Kerberos TGT Request | 4768 | Ticket-granting ticket (TGT) request received |
AD FS Authentication | 1200 | AD FS authentication |
Defender for Identity learning period
Microsoft Defender for Identity (MDI) uses a learning period to understand the typical behavior patterns within your network. This period is crucial for fine-tuning the detection capabilities, ensuring that alerts are both accurate and relevant. By establishing a baseline of normal activities, MDI can more effectively identify anomalies and potential security threats.
Source Type | Learning Period |
---|---|
Active Directory (AD) | 30 days |
Network Traffic | 30 days |
User and Entity Behavior | 30 days |
NTLM Authentication | 30 days |
Kerberos Authentication | 30 days |
Defender for Identity security posture recommendations
Microsoft released impressive updates to the Microsoft Defender for Identity posture recommendations, check out my previous blog post and make sure to walk through the findings:
Conclusion
Microsoft Defender for Identity offers comprehensive protection for on-premises Active Directory environments, leveraging advanced threat detection and behavioral analytics. This guide provides a clear, step-by-step process for deploying and configuring the solution, along with testing mechanisms to ensure proper functionality. By integrating it with AD FS, AD CS, and Entra Connect, organizations can achieve complete identity security monitoring across their hybrid environments.