How to Set Up Microsoft Advanced Threat Analytics and Defender for Identity on Windows Server 2025

Identity-based attacks are among the most damaging threats facing modern organizations. Adversaries frequently target Active Directory to harvest credentials, move laterally across the network, and escalate privileges to domain-wide control. Microsoft Advanced Threat Analytics (ATA) was the on-premises solution designed to detect these behavioral threats. However, ATA reached end of mainstream support and has been superseded by Microsoft Defender for Identity — a cloud-powered, sensor-based solution integrated into the Microsoft 365 Defender portal. This tutorial covers both the legacy ATA architecture for context and the full deployment of Defender for Identity on Windows Server 2025 domain controllers, including sensor installation, workspace configuration, entity tagging, lateral movement monitoring, and SIEM integration with Microsoft Sentinel.

Prerequisites

  • Windows Server 2025 domain controllers (at least one) with .NET Framework 4.7 or later
  • Microsoft 365 E5 license or Microsoft Defender for Identity standalone license
  • Access to the Microsoft 365 Defender portal (security.microsoft.com)
  • Domain Admin or equivalent credentials to install sensors on domain controllers
  • Network connectivity from domain controllers to *.atp.azure.com on TCP 443
  • PowerShell 5.1 or later on domain controllers
  • Optional: Microsoft Sentinel workspace in Azure for SIEM integration

Step 1: Understanding ATA vs. Defender for Identity

Microsoft ATA was an on-premises appliance that mirrored Active Directory traffic and analyzed it locally using machine learning. It required a dedicated ATA Center server receiving port-mirrored or SPAN traffic from domain controllers. ATA reached end of mainstream support in January 2021 and is no longer recommended for new deployments.

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection / Azure ATP) replaces ATA entirely. Instead of port mirroring, lightweight sensors are installed directly on each domain controller. These sensors parse network traffic and Windows events locally, transmitting signals to the Microsoft cloud for analysis. Key advantages over ATA include:

  • No dedicated on-premises ATA Center server required
  • Automatic sensor updates managed by Microsoft
  • Deep integration with Microsoft 365 Defender, Entra ID Protection, and Defender for Endpoint
  • Lateral movement path (LMP) visualization across the entire environment
  • Pass-the-Hash, Pass-the-Ticket, Golden Ticket, and Kerberoasting detection built-in

If you are running a legacy ATA deployment on Windows Server 2025 infrastructure, you should plan migration to Defender for Identity immediately. Use the following PowerShell to audit ATA Center and gateway services before decommissioning:

# Check for legacy ATA Center or Gateway services
Get-Service -Name "Microsoft Advanced Threat Analytics*" -ErrorAction SilentlyContinue |
    Select-Object Name, Status, StartType

# Check ATA database size before migration
Get-WmiObject -Class Win32_LogicalDisk -Filter "DeviceID='C:'" |
    Select-Object Size, FreeSpace

Step 2: Create the Defender for Identity Workspace

Defender for Identity workspaces are provisioned through the Microsoft 365 Defender portal. You do not need to create a separate Azure resource — the workspace is tied to your Microsoft 365 tenant.

  1. Browse to https://security.microsoft.com and sign in with a Global Administrator account.
  2. Navigate to Settings → Identities.
  3. If no workspace exists, you will be prompted to create one. Select your geographic region (data residency location) and click Create workspace.
  4. After creation, the workspace displays your Access key — used during sensor installation.

Retrieve workspace details programmatically using the Defender for Identity API (requires appropriate permissions):

# Install the required module if not present
Install-Module -Name Az.SecurityInsights -Force -AllowClobber

# Connect to Microsoft 365 Defender API
$tenantId = "your-tenant-id"
$clientId = "your-app-registration-client-id"
$clientSecret = ConvertTo-SecureString "your-secret" -AsPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential($clientId, $clientSecret)
Connect-AzAccount -ServicePrincipal -TenantId $tenantId -Credential $credential

# Verify Defender for Identity license assignment
Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -like "*ATA*" -or $_.SkuPartNumber -like "*IDENTITY*" } |
    Select-Object SkuPartNumber, ConsumedUnits

Step 3: Install the Defender for Identity Sensor on Domain Controllers

The Defender for Identity sensor must be installed on every domain controller, including read-only domain controllers (RODCs). The sensor installer is downloaded directly from the workspace settings page.

# Download sensor installer (replace URL with the one from your workspace)
$installerUrl = "https://aka.ms/MDISetup"
$installerPath = "C:TempMDI_Sensor_Setup.exe"

Invoke-WebRequest -Uri $installerUrl -OutFile $installerPath

# Verify download integrity
Get-FileHash -Path $installerPath -Algorithm SHA256

Run the installer silently on the domain controller, providing the workspace access key:

# Silent installation with access key from the workspace portal
$accessKey = "PASTE_YOUR_ACCESS_KEY_HERE"

Start-Process -FilePath $installerPath -ArgumentList `
    "/quiet", `
    "NetFrameworkCommandLineArguments=`"/q`"", `
    "AccessKey=$accessKey" `
    -Wait -PassThru | Select-Object ExitCode

# Verify sensor service is running
Get-Service -Name "AATPSensor" | Select-Object Name, Status, StartType

# Verify sensor version
Get-ItemProperty "HKLM:SOFTWAREMicrosoftAzure Advanced Threat ProtectionSensor" |
    Select-Object Version

After installation, confirm the sensor appears in the portal under Settings → Identities → Sensors. Sensor status should show Running within a few minutes.

Step 4: Configure Entity Tagging for Sensitive Accounts and Computers

Entity tagging tells Defender for Identity which accounts and computers are high-value targets. Tagging a user or machine as Sensitive causes the system to generate higher-priority alerts and include these entities in lateral movement path analysis.

Configure sensitive entity tags in the portal under Settings → Identities → Entity tags. Common candidates include:

  • Domain Admins, Enterprise Admins, Schema Admins group members
  • Service accounts with broad AD permissions
  • Privileged Access Workstations (PAWs) and Tier-0 servers
  • KRBTGT account (automatically tagged)

You can also tag entities via PowerShell using the Microsoft Defender for Identity API:

# Example: Retrieve sensitive accounts for tagging review
Import-Module ActiveDirectory

# Find accounts with AdminCount = 1 (protected by AdminSDHolder)
Get-ADUser -Filter { AdminCount -eq 1 } -Properties AdminCount, SamAccountName, Enabled |
    Where-Object { $_.Enabled -eq $true } |
    Select-Object SamAccountName, DistinguishedName |
    Sort-Object SamAccountName

# Find service accounts with SPNs (Kerberoastable)
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
    Select-Object SamAccountName, ServicePrincipalName |
    Sort-Object SamAccountName

Step 5: Monitor Lateral Movement Alerts — Pass-the-Hash and Pass-the-Ticket

Defender for Identity detects credential-based attacks automatically. The most critical alerts to monitor include:

  • Pass-the-Hash (PtH): Detected when an NTLM hash is reused across systems. Correlates anomalous authentication patterns (Event ID 4624 Type 3) with known hash reuse behavior.
  • Pass-the-Ticket (PtT): Detected when a Kerberos TGT or service ticket is stolen and replayed from a different machine.
  • Golden Ticket: Detected by anomalous Kerberos ticket lifetimes or encryption types (RC4 when AES is expected) associated with forged tickets using the KRBTGT hash.
  • Lateral Movement Paths (LMPs): Visual graphs showing attack paths from non-sensitive to sensitive accounts via exposed credentials.
# PowerShell: Query recent suspicious authentication events on domain controllers
$startTime = (Get-Date).AddHours(-24)

Get-WinEvent -ComputerName (Get-ADDomainController -Filter *).Name -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = $startTime
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[8].Value -eq 3 -and $_.Properties[10].Value -eq "NTLM" } |
    Select-Object TimeCreated,
        @{N='Account'; E={ $_.Properties[5].Value }},
        @{N='SourceIP'; E={ $_.Properties[18].Value }},
        @{N='AuthPackage'; E={ $_.Properties[10].Value }} |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 50

Step 6: Integrate Defender for Identity with Microsoft Sentinel

Forwarding Defender for Identity alerts to Microsoft Sentinel enables long-term retention, correlation with other data sources, and automated response via playbooks.

# Connect to Azure and enable the Defender for Identity data connector in Sentinel
Connect-AzAccount -TenantId "your-tenant-id"

$resourceGroup = "rg-sentinel"
$workspaceName = "law-sentinel-prod"
$subscriptionId = "your-subscription-id"

# Enable Microsoft Defender for Identity connector via REST API
$apiVersion = "2021-03-01-preview"
$connectorId = "MicrosoftDefenderAdvancedThreatProtection"
$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup" +
       "/providers/Microsoft.OperationalInsights/workspaces/$workspaceName" +
       "/providers/Microsoft.SecurityInsights/dataConnectors/$connectorId" +
       "?api-version=$apiVersion"

$body = @{
    kind = "MicrosoftDefenderAdvancedThreatProtection"
    properties = @{
        tenantId = "your-tenant-id"
        dataTypes = @{
            alerts = @{ state = "Enabled" }
        }
    }
} | ConvertTo-Json -Depth 5

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token
$headers = @{ Authorization = "Bearer $token"; "Content-Type" = "application/json" }

Invoke-RestMethod -Method Put -Uri $uri -Headers $headers -Body $body

Once the connector is active, Defender for Identity alerts appear in Sentinel’s SecurityAlert table with ProductName == "Azure Advanced Threat Protection". Use KQL to build detection rules:

// Sentinel KQL: Detect Pass-the-Hash alerts from Defender for Identity
SecurityAlert
| where ProductName == "Azure Advanced Threat Protection"
| where AlertName contains "Pass-the-Hash"
| project TimeGenerated, AlertName, AlertSeverity, Entities, ExtendedProperties
| order by TimeGenerated desc

Step 7: Visualize Lateral Movement Paths

Lateral Movement Path (LMP) visualization is one of the most powerful features in Defender for Identity. Access LMPs by navigating to a sensitive entity profile in the portal and selecting the Lateral movement paths tab. The graph shows all intermediate accounts whose credentials are exposed on machines that connect to the sensitive entity.

To reduce lateral movement exposure, audit which accounts are logged into shared workstations or servers:

# Identify accounts with cached credentials on non-Tier-0 machines
# Query AD for computers outside privileged OUs
$privilegedOUs = @(
    "OU=Tier0,OU=Admin,DC=contoso,DC=com",
    "OU=DomainControllers,DC=contoso,DC=com"
)

Get-ADComputer -Filter { Enabled -eq $true } -Properties OperatingSystem, DistinguishedName |
    Where-Object {
        $dn = $_.DistinguishedName
        -not ($privilegedOUs | Where-Object { $dn -like "*$_*" })
    } |
    Select-Object Name, OperatingSystem, DistinguishedName |
    Export-Csv -Path "C:ReportsNonPrivilegedComputers.csv" -NoTypeInformation

Write-Host "Non-privileged computer list exported to C:ReportsNonPrivilegedComputers.csv"

Conclusion

Microsoft Defender for Identity provides enterprise-grade identity threat detection that far exceeds the capabilities of the legacy ATA platform. By deploying sensors on all Windows Server 2025 domain controllers, configuring sensitive entity tags, and integrating with Microsoft Sentinel, you gain continuous visibility into credential-based attacks, lateral movement, and privilege escalation attempts across your Active Directory environment. The behavioral analytics engine runs entirely in the Microsoft cloud, reducing on-premises infrastructure burden while providing near-real-time alerting on even the most sophisticated attack techniques such as Golden Ticket forgery and DCSync. Regular review of lateral movement paths and periodic KRBTGT password rotation are essential operational hygiene practices that complement the detection capabilities provided by this solution.