Why Your MDI Alerts Are Noisy (And How to Fix Them)

Microsoft Defender for Identity is one of the most powerful tools for detecting on-premises Active Directory attacks — but out of the box, it's also one of the noisiest. If you've deployed MDI sensors and found yourself drowning in alerts about suspicious LDAP queries, encryption downgrades, and "abnormal behavior" from service accounts that have behaved identically for years, you're not alone.

The problem isn't that MDI is broken. The problem is that most environments have legacy systems, service accounts, and operational patterns that trigger MDI's detection logic even though they're perfectly legitimate. Left untuned, this creates alert fatigue, and alert fatigue means real attacks get missed.

In this post, I'll walk through the most common sources of MDI noise, how to investigate them properly, and how to tune them without creating dangerous blind spots.

Prerequisites

Before you start tuning, you need:

• Microsoft Defender for Identity deployed with sensors on domain controllers

• Access to Microsoft Defender XDR (security.microsoft.com) or Microsoft Sentinel with MDI connector enabled

• Security Administrator or Security Operator role in Defender XDR

• At least 7 days of baseline data from MDI to identify patterns

• A list of known service accounts and their expected behavior

Step 1 – Identify Your Noisiest Alerts

Start by understanding which alerts are firing most frequently. In Defender XDR, go to Incidents & alerts > Alerts and filter by:

• Service source: Microsoft Defender for Identity

• Status: New or In progress

• Time range: Last 7 days

Sort by Alert count and look for patterns. In my experience, the top offenders are usually:

• Suspicious LDAP queries (often from monitoring tools, backup agents, or privilege management systems)

• Account enumeration (LDAP queries from vulnerability scanners or asset management)

• Encryption downgrade attacks (legacy systems still using RC4 or DES Kerberos encryption)

• Suspected DCSync attacks (backup software or federation services legitimately replicating directory data)

• Abnormal protocol usage (NTLM from systems that can't do Kerberos)

Document which alerts are firing, which accounts are involved, and the frequency.

Step 2 – Investigate Before You Exclude

Never blindly exclude an alert. Even if you're confident it's a false positive, validate it first. For each noisy alert:

1. Identify the source account — is it a service account, user, or computer?

2. Identify the source device — hostname, IP, and role (DC, app server, scanner, etc.)

3. Review the activity timeline — does this happen daily at the same time? Only during maintenance windows?

4. Confirm legitimacy with the application owner — don't assume, verify.

In Defender XDR, click into the alert and check the Evidence tab. You'll see:

• Source account

• Source device

• Queried attributes (for LDAP alerts)

• Kerberos ticket details (for encryption alerts)

For deeper hunting, use Advanced Hunting in Defender XDR with KQL:

IdentityDirectoryEvents
| where Timestamp > ago(7d)
| where ActionType == "LDAP query"
| where AccountUpn == "svc-backup@contoso.com"
| summarize Count=count(), 
            DestinationDevices=make_set(DestinationDeviceName), 
            QueriedAttributes=make_set(AdditionalFields.SearchFilter)
            by bin(Timestamp, 1d), AccountUpn
| order by Timestamp desc

This shows you whether the service account queries the same attributes daily (legitimate pattern) or randomly probes sensitive attributes (suspicious).

Step 3 – Tune Service Account Alerts

The most common source of noise is service accounts doing legitimate but suspicious-looking things. Examples:

• Backup agents querying all user objects

• Monitoring tools enumerating group memberships

• Privilege management systems checking adminCount attributes

Option A: Mark the Account as a Sensitive Account Exclusion

If the account is a known service account performing expected LDAP queries, you can exclude it from specific alert types.

In Defender XDR, go to:

1. Settings > Identities

2. Entity tags > Sensitive accounts

3. Add the service account to the exclusion list for the specific alert type

This is safer than a global exclusion because it's scoped to one alert category.

Option B: Use Sentinel Analytics Rule Tuning

If you're ingesting MDI data into Sentinel, you can create custom analytics rules with exclusion logic:

let ServiceAccounts = dynamic(["svc-backup@contoso.com", "svc-monitor@contoso.com"]);
IdentityDirectoryEvents
| where Timestamp > ago(1h)
| where ActionType == "LDAP query"
| where AccountUpn !in (ServiceAccounts)
| where AdditionalFields.SearchFilter contains "adminCount" 
    or AdditionalFields.SearchFilter contains "servicePrincipalName"
| project Timestamp, AccountUpn, DestinationDeviceName, AdditionalFields

This creates a clean separation: service accounts are excluded, but the same activity from user accounts still triggers an alert.

Step 4 – Handle Legacy Encryption Downgrade Alerts

MDI flags Kerberos encryption downgrade attacks when it sees RC4 or DES encryption instead of AES. This is a real attack technique (Skeleton Key, Golden Ticket), but it's also triggered by:

• Legacy applications that only support RC4

• Old network devices (firewalls, load balancers) authenticating via Kerberos

• Third-party systems with hardcoded encryption settings

Investigate the Source

Run this query in Advanced Hunting:

IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| extend EncryptionType = tostring(AdditionalFields.TicketEncryptionType)
| where EncryptionType in ("RC4", "DES")
| summarize Count=count() by DeviceName, AccountUpn, EncryptionType
| order by Count desc

If you see the same device using RC4 every day, that's a known legacy system. If you see a workstation suddenly switching from AES to RC4, that's suspicious.

Exclusion Path

For confirmed legacy systems:

1. Document the exception (device name, reason, ticket number)

2. Request remediation from the app owner (upgrade to AES if possible)

3. If remediation isn't possible, exclude the specific device in MDI settings under Detection exclusions

Do not exclude the alert globally. Scope it to the specific device or service account.

Step 5 – Create Targeted Exclusions in MDI

For alerts you've validated as false positives, you can create exclusions directly in MDI:

1. Go to Defender XDR > Settings > Identities

2. Select Exclusions

3. Choose the alert type (e.g., "Suspicious LDAP query")

4. Add the specific account, IP, or device to exclude

Critical rule: Always scope exclusions as narrowly as possible. Excluding "all LDAP queries from svc-backup@contoso.com" is acceptable. Excluding "all LDAP queries from all service accounts" is dangerous.

Troubleshooting

Problem: I excluded an account, but alerts are still firing.

• Cause: The exclusion is scoped to one alert type, but the account is triggering multiple types.

• Fix: Review all active alerts for that account and add exclusions for each relevant type.

Problem: I can't tell if an LDAP query is legitimate.

• Cause: Missing context on what attributes are being queried.

• Fix: Use the KQL query in Step 2 to extract AdditionalFields.SearchFilter and compare against known baselines.

Problem: After tuning, I'm worried I've excluded a real attack.

• Cause: Over-exclusion or lack of ongoing validation.

• Fix: Schedule quarterly reviews of exclusions. Use Sentinel workbooks to track excluded accounts and their activity trends.

Hardening Considerations

Tuning alerts is about reducing noise, not ignoring risk. As you tune:

• Enforce AES encryption across your domain (disable RC4 via GPO)

• Migrate service accounts to gMSA (group Managed Service Accounts) to reduce static credential risk

• Enable Advanced Audit Policy on DCs to capture additional telemetry for MDI

• Review MDI security posture recommendations in Defender XDR under Secure Score

• Monitor excluded accounts separately — create a Sentinel watchlist and alert on unexpected changes in behavior even if they're excluded from standard MDI alerts

Final Thoughts

Look, I get it — tuning alerts feels like busy work when you've got a backlog of incidents and three other projects on your plate. But here's the reality: if your team is ignoring 90% of MDI alerts because they're noise, you're not actually running a detection program. You're just paying for expensive log storage.

I've seen this play out too many times. A SOC gets MDI deployed, alerts start flooding in, analysts mark everything as false positive for a few weeks, and then they just… stop looking. Six months later, an attacker uses DCSync to pull password hashes, and the alert sits unread in a queue of 500 other "suspicious" activities.

The goal here isn't to silence everything until you have zero alerts. It's to get to a place where when MDI fires an alert, people actually investigate it. That means doing the work upfront — validating service accounts, understanding your legacy systems, scoping exclusions properly, and documenting why you made each decision.

Start small. Pick your top five noisiest alerts this week and work through them methodically. Don't rush it, and definitely don't create broad exclusions just to make the dashboard look clean. Every exclusion is a potential blind spot, so treat them seriously.

And once you've got things tuned? That's when MDI becomes genuinely useful. You'll start catching reconnaissance activity, lateral movement, and credential abuse that would've been invisible otherwise.

In a future post, I'll dig into advanced hunting for lateral movement chains using MDI telemetry — because once your alerts are actually actionable, the real fun is in proactive threat hunting.