How to Deploy Microsoft Defender for Identity (MDI) to Detect Active Directory Golden Ticket Attacks

For decades, on-premises Windows Server Active Directory (AD) has been the central identity vault for the enterprise. It is also the primary target for advanced persistent threats (APTs). If a threat actor compromises a Domain Admin account, they can extract the krbtgt (Kerberos Ticket Granting Ticket) password hash. With this hash, they can forge a Golden Ticket—a mathematically valid Kerberos ticket that grants them absolute, stealthy, and persistent administrative access to every machine in the domain, bypassing password resets and MFA entirely.

Traditional endpoint antivirus cannot detect a Golden Ticket attack because the forged Kerberos ticket is cryptographically valid; the Domain Controller simply accepts it as legitimate traffic.

To detect and neutralize these hyper-advanced identity attacks, security architects must deploy Microsoft Defender for Identity (MDI). MDI operates by installing a microscopic network sensor directly onto the Domain Controllers. It deeply parses the Kerberos, NTLM, and RPC network traffic flowing into the DC, utilizing machine learning in the cloud to detect the subtle behavioral anomalies indicative of lateral movement, DCSync attacks, and forged Golden Tickets.

This guide explains how to architect and deploy the Microsoft Defender for Identity sensor.

Understanding the MDI Architecture

MDI (formerly known as Azure Advanced Threat Protection or AATP) relies on a hybrid architecture:

1. The Cloud Workspace: The analytical brain resides in the Microsoft 365 Defender portal. It builds a behavioral baseline of every user and service account in your AD environment.
2. The Sensor: A lightweight service (Azure ATP Sensor) installed directly on your on-premises Windows Server Domain Controllers. It captures network traffic via Npcap and reads Windows Event Logs locally, drastically reducing network bandwidth compared to port mirroring.
3. The Directory Services Account (DSA): A standard, non-privileged AD user account that the MDI sensor uses to query LDAP and resolve IP addresses back to computer names for contextual alerts.

Step 1: Creating the Directory Services Account (DSA)

The sensor needs a read-only AD account to pull group memberships and user metadata.

1. Open Active Directory Users and Computers (ADUC).
2. Create a standard user account (e.g., svc_mdi_dsa).
3. Set a highly complex, 32-character password and set Password never expires.
4. Crucial Security Rule: Ensure this account has absolutely no administrative privileges. It only needs standard read access to AD.

Step 2: Configuring the MDI Workspace

You must initialize the cloud environment to receive the sensor telemetry.

1. Navigate to the Microsoft Defender Portal (security.microsoft.com).
2. Go to Settings > Identities.
3. Click on Directory Service Accounts and add the credentials for the svc_mdi_dsa account you created in Step 1. (You can also use a Group Managed Service Account – gMSA for enhanced security).
4. Navigate to Sensors and click Add sensor.
5. Download the sensor setup executable (Azure ATP sensor Setup.exe).
6. Copy the Access Key displayed on the screen. The sensor requires this key to authenticate to the cloud workspace.

Step 3: Installing the Sensor on the Domain Controller

You must install the sensor on every Domain Controller in the environment. If you miss one DC, an attacker can route their Golden Ticket request to the unmonitored DC and evade detection entirely.

1. Log in to the Domain Controller as a Domain Admin.
2. Run the Azure ATP sensor Setup.exe executable.
3. The installer will automatically detect that it is running on a Domain Controller and select the Sensor deployment type.
4. When prompted, paste the Access Key copied from the Defender portal.
5. Complete the installation. The sensor will silently install the Npcap packet capture driver and register the background service.

Step 4: Configuring Windows Event Log Forwarding (Optional but Recommended)

While the sensor parses Kerberos network traffic in real-time, it relies on specific Windows Event Logs (such as Event ID 4776 for NTLM authentication) to enrich the data.

To ensure the sensor has access to all necessary data, verify that your Default Domain Controllers Policy (GPO) enforces the auditing of Account Logon Events, Account Management, and Object Access.

Step 5: Detecting the Golden Ticket Attack

Once deployed, MDI spends several weeks in a “Learning Phase” building a behavioral baseline (e.g., Administrator Bob normally logs in from Subnet A during business hours).

If an attacker steals the krbtgt hash and forges a Golden Ticket, the ticket is cryptographically valid, but its metadata is flawed. The MDI sensor intercepts the Kerberos TGS-REQ (Ticket Granting Service Request) on the Domain Controller. MDI’s cloud analytics engine instantly notices anomalies:

• The Ticket Granting Ticket (TGT) presented in the request has a lifetime of 10 years (attackers often forge tickets with absurdly long lifespans), whereas the AD default is 10 hours.
• The TGT is missing specific Privilege Attribute Certificate (PAC) signatures that modern AD environments enforce.
• The TGT was never actually requested via an initial AS-REQ (Authentication Service Request). It simply appeared out of thin air.

MDI immediately flags this in the Defender portal as a Suspected Golden Ticket usage (Pass the Ticket), alerting the SOC and automatically suspending the compromised user account via Entra ID integration before the attacker can exfiltrate data.

Conclusion

Relying solely on endpoint antivirus leaves the core identity infrastructure completely blind to cryptographic credential theft. By deploying Microsoft Defender for Identity sensors directly onto the Domain Controllers, security teams gain deep, packet-level visibility into the Kerberos authentication flow, neutralizing lateral movement and Golden Ticket attacks before they compromise the entire enterprise.