Hardening Defender for Identity: sensors and the gMSA service account

Microsoft Defender for Identity (MDI) runs a sensor on each domain controller, watching authentication and directory traffic for identity-based attacks that endpoint tooling can't see. Getting value from it depends on two operational choices that are easy to get wrong: standardizing the sensor generation across a mixed fleet, and running the sensor under a properly managed service account instead of the default.

01Classic vs modern sensor — standardize deliberately

The newer sensor is appealing, but coverage comes first.

Microsoft ships two sensor generations, and in a real fleet you'll often find both running — some DCs on the classic sensor, some on the modern one. That split is worth resolving on purpose:

	Classic sensor	Modern sensor
Maturity	Generally available, full coverage	Preview (Windows Server 2019+), not yet full security coverage
Deployment	Standalone installer + service	Deployed through the Defender portal
Integration	Standalone	Integrated with Defender for Endpoint
Footprint	Standalone binaries / services	Cleaner — no separate binaries/services

Coverage beats convenience — for now

The modern sensor's easier deployment, MDE integration, centralized management, and cleaner footprint are genuinely better — but while it's still in preview and doesn't yet provide full security coverage, the right call for production DCs is to standardize on the classic sensor and plan the switch to modern once it reaches general availability and feature parity. Don't trade detection coverage for a tidier deployment on your most security-critical servers.

02Why a gMSA beats the Local Service account

The default account works, but it's a blind spot.

By default the sensor can run as the built-in Local Service account. It functions — but Local Service is limited to the local server and offers very little control or visibility. A Group Managed Service Account (gMSA) is the better foundation:

Local Service	gMSA
Scoped to the local server only	Domain-managed, usable across all DCs
Little central control or visibility	Centrally managed in Active Directory
Password not managed as a domain secret	Password auto-rotated by AD every 30 days, no manual work

The automatic password rotation is the headline: AD maintains the gMSA's password and rotates it on a schedule with no human ever touching it, which removes a whole class of stale-credential and manual-rotation risk. It's both more secure and easier to administer than the default.

03The migration

Create the account, grant the right, switch one DC, then roll out.

# the migration, in order
1. Create + configure a gMSA for the MDI sensor service
2. Grant "Log on as a service" to the gMSA on all DCs
   → apply via a Group Policy update linked to the DC OU
3. Update the sensor service logon account on ONE DC first
   → Service properties → Log On → "This account" → CONTOSO\gmsa-mdi$
4. Validate sensor health on that DC in the Defender portal
5. Roll the change to the remaining DCs
6. One restart per DC (out of hours) to fully apply the logon rights
7. Monitor all sensors in the Defender portal post-change

Doing one DC first is the safety valve — you confirm the account, the "log on as a service" right, and sensor health all line up before touching the rest of the estate. The single restart per DC is what actually applies the new logon rights, so schedule it in a maintenance window and verify sensor health comes back green afterward.

04Verify the rotation is actually configured

Confirm the 30-day managed-password interval from AD itself.

# confirm the gMSA's managed-password rotation interval
Get-ADServiceAccount -Identity gmsa-mdi -Properties * `
  | Select-Object Name, msDS-ManagedPasswordInterval

How to read it

A returned msDS-ManagedPasswordInterval of 30 confirms AD is set to rotate the account's password every 30 days automatically — aligning with Microsoft's best practices for managed accounts. This is the proof that the "no manual rotation ever" property is genuinely in effect, not just assumed.

The takeaway

Defender for Identity is only as good as its deployment. On production DCs, standardize on the classic sensor until the modern one hits GA with full coverage — coverage beats a cleaner footprint. And move the sensor off Local Service onto a gMSA: domain-managed, centrally visible, with AD auto-rotating the password every 30 days. Migrate one DC first, grant "log on as a service" by GPO, restart each DC once out of hours, and verify the 30-day interval straight from Get-ADServiceAccount.