A comprehensive guide to securing your on-premises identity infrastructure.

Identity is the new perimeter. In a modern cybersecurity landscape where 80% of breaches involve compromised credentials, protecting your on-premises Active Directory (AD) is non-negotiable. Microsoft Defender for Identity (MDI) is the cloud-based security solution that monitors your on-premises domain controllers to detect advanced threats, compromised identities, and malicious insider actions.

This guide walks you through a deep-dive deployment of Microsoft Defender for Identity, moving from prerequisites to a fully operational security layer.

---

Phase 1: Architecture & Prerequisites

Before you download a single agent, you must prepare your environment. MDI uses a Sensor installed directly on your Domain Controllers (DCs) which parses network traffic and forwards relevant signals to the Microsoft cloud.

1. Licensing & Access

Ensure you have one of the following licenses:

• Enterprise Mobility + Security E5 (EMS E5)
• Microsoft 365 E5
• A standalone Defender for Identity license

You will also need Global Administrator or Security Administrator rights in your tenant to create the initial instance.

2. Capacity Planning (Don’t skip this!)

The MDI sensor is lightweight, but it does consume resources.

• CPU/RAM: The sensor monitors your DC’s available resources. If the server runs low on CPU or RAM, the sensor will stop monitoring traffic to prevent crashing the DC.
• Sizing Tool: Download and run the Test-MdiReadiness.ps1 PowerShell script from the Microsoft Defender portal. It analyzes your DC’s traffic volume and recommends whether you need a standalone sensor (rare) or if the integrated sensor is sufficient.

3. Network Requirements

The sensor needs to talk to the cloud. Ensure your firewalls allow outbound traffic on TCP 443 to *.atp.azure.com.

• Internal Ports: The sensor also needs to communicate internally on ports like DNS (53), Kerberos (88), and SMB (445) to resolve network entities.

---

Phase 2: The Directory Service Account (DSA)

The MDI sensor needs a user account to query Active Directory. It uses this to look up user group memberships, password expiration dates, and other attributes.

Best Practice: Use a Group Managed Service Account (gMSA). A gMSA is more secure because Windows manages the password automatically—you never have to rotate it manually.

Steps to create a gMSA:

1. Create the KDS Root Key (if you haven’t already for your forest):PowerShellAdd-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
2. Create the gMSA Account:PowerShellNew-ADServiceAccount -Name "MDI-gMSA" -DNSHostName "MDI-gMSA.yourdomain.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"
3. Grant Permissions: The account essentially needs Read access to all objects in AD. If you have a “Deleted Objects” container, grant read access there too so MDI can detect deleted users.

---

Phase 3: Deployment Step-by-Step

Step 1: Create the Workspace

1. Go to the Microsoft Defender Portal.
2. Navigate to Settings > Identities > General > Sensor.
3. You will see a prompt to create your workspace. Click Create.
4. Once created, you will see an Access Key. Copy this key; you will need it for every sensor installation.

Step 2: Download the Sensor

In the same “Sensors” tab:

1. Click Add sensor.
2. Download the installer package. This is a zip file containing the setup .exe.

Step 3: Install on Domain Controllers

Copy the installer zip file to every Domain Controller (and ADFS server) in your environment.

1. Extract the zip file.
2. Right-click Azure ATP Sensor Setup.exe and Run as Administrator.
3. Wizard Steps:
   • Language: Select your language.
   • Type: The wizard will automatically detect if it is running on a Domain Controller.
   • Configuration: Paste the Access Key you copied from the portal.
4. Click Install.

Note: The installation typically does not require a reboot, but .NET Framework 4.7+ is a prerequisite. If your servers are outdated, the installer might trigger a reboot to update .NET.

---

Phase 4: Post-Deployment Configuration

Installing the sensor is only half the battle. You need to configure the environment to send the right data.

1. Configure Windows Audit Policies

For MDI to detect attacks like “Pass-the-Hash” or “Brute Force,” your DCs must log specific events. You need to configure the Advanced Audit Policy Configuration via Group Policy applied to all DCs.

• Account Logon: Audit Credential Validation (Success/Failure)
• Account Management: Audit User/Group Management (Success/Failure)
• Object Access: Audit File Share (Success/Failure) (Critical for SMB monitoring!)

2. Configure SAM-R Permissions

Many lateral movement attacks involve reconnaissance using the SAM-R protocol. To allow MDI to detect this, you must grant your DSA account permission to perform remote SAM calls.

• GPO Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Restrict clients allowed to make remote calls to SAM.
• Action: Add your MDI-gMSA account to this list.

3. Setup Honeytokens

A “Honeytoken” is a decoy account (e.g., “Admin_Backup”) that looks valuable but is never actually used.

1. In the Defender Portal, go to Settings > Identities > Entity tags > Honeytoken.
2. Add your decoy account.
3. Benefit: If anyone tries to log in with this account, MDI instantly triggers a high-severity alert. It’s a guaranteed sign of malicious activity.

---

Phase 5: Verification & Health Checks

After deployment, wait 15–30 minutes for the cloud service to sync.

1. Check Service Status: On the DC, open services.msc and verify that the “Azure Advanced Threat Protection sensor” service is Running.
2. Portal Verification: Go back to the Defender Portal > Settings > Identities > Sensors. Your DCs should now appear in the list with a status of “Running”.
3. Health Issues: Look for any alerts in the “Health issues” tab. Common errors include “Directory Services synchronization failure” (check your gMSA permissions) or “Auditing configuration mismatch” (check your GPOs).

Final Thoughts

Deploying Microsoft Defender for Identity provides immediate, high-fidelity visibility into your most critical asset: your user identities. By correlating these on-prem signals with cloud data from Entra ID (formerly Azure AD), you close the gap between your physical office and the cloud, making it exponentially harder for attackers to hide.