Defender for Identity: the sensor you’ve been avoiding just got easy

Most of us treat the domain controller like furniture. It’s been in the corner for fifteen years, it works, and nobody wants to touch it.

But that DC sees everything. Every logon. Every Kerberos ticket. Every “let me just check if this service account still works” at 2am from a machine that has no business asking.

You’re sitting on the single richest source of attack signal in the whole environment, and most small-business tenants aren’t reading a word of it.

That’s not a tooling gap. That’s a switch nobody flipped.

And I get why. For years, turning on Microsoft Defender for Identity meant a download, an installer on every DC, a group managed service account, audit GPOs, and a packet-capture driver. Real work. So it sat on the “later” pile.

Later just arrived. The new sensor changes the maths completely.

What is the Defender for Identity sensor, really?

Forget the marketing. Defender for Identity is a sensor that lives on your domain controllers and watches the authentication traffic they already handle.

It’s looking for the things your antivirus will never see — lateral movement, Kerberoasting, DCSync, someone quietly enumerating your admins. The DC is the witness. The sensor just takes its statement.

Here’s what changed. The version 3 sensor — the “unified” one that went generally available late last year — doesn’t ship as its own agent anymore. It rides inside Defender for Endpoint. If Defender for Endpoint is already onboarded on your DC, the identity sensor is a few clicks in the portal. No installer. No service account. No Npcap.

One caveat before you get excited, and it’s the one MSPs trip on: this isn’t in Business Premium. You need Microsoft 365 E5, E5 Security, EMS E5, or the standalone Defender for Identity licence. Check the SKU before you promise a client anything.

Step-by-Step: turning the sensor on

Assuming Defender for Endpoint is already running on a Windows Server 2019-or-later DC that’s kept current on updates, here’s the path. Everything happens in the Microsoft Defender portal — no remoting onto the box.

Open the activation surface

Go to security.microsoft.com, then Settings > Identities. First time in, it provisions your workspace in a few seconds.

Activate the sensor

Open the Sensors (or Activation) page. Every DC that’s already onboarded to Defender for Endpoint and meets the bar shows up as eligible. Tick it, activate, done. No download, no reboot, no downtime on the DC.

Defender portal → Settings → Identities → Sensors
  [x] DC01  (eligible — Defender for Endpoint onboarded)  → Activate
  [x] DC02  (eligible — Defender for Endpoint onboarded)  → Activate

Notice what’s missing? No installer to copy. No service account to create and babysit. No access key pasted into a setup wizard. If you’ve done this the old way, that absence is the whole story.

Mind the stragglers

Version 3 only covers domain controllers on Server 2019 and later. Got an old 2016 DC, or a standalone AD FS, AD CS, or Entra Connect box? Those still need the classic v2 sensor with its installer. Mixed estates are fine — both versions report to the same workspace.

Set a honeytoken

This is the cheap win everyone skips. Under Settings > Identities > Entity tags > Honeytoken, tag a dormant account as a honeytoken. Give it a tasty name — svc-backup-admin, sql_sa_old — and never use it. Because nothing legitimate ever touches it, any authentication against it is, by definition, someone poking where they shouldn’t. High signal, almost no noise.

Why this actually changes behaviour

The sensor needs time to learn what normal looks like — figure on a few weeks per DC before the behavioural alerts settle. Don’t treat every early alert as gospel. Watch, tune, then trust.

“So I just switch it on and start blocking?”

No. You switch it on and start watching. Audit before you trust. The honeytoken is the exception — that one’s high-confidence from minute one.

Here’s the real win, and it’s a business one. Identity attacks don’t announce themselves on the endpoint. They look like a valid logon, because they are one — with stolen credentials. The DC is the one place that sees the pattern. Turn the sensor on and you’ve gone from “we’d never know” to “we’d get paged.”

For an MSP, that’s a renewal conversation, not a checkbox. “We’re watching your domain controllers for credential attacks” is something a client understands and pays for.

Defender for Identity isn’t there to add another console to your morning. It’s there so the most important server in the building finally has someone listening.

You’ve already got the witness. Go take the statement.