Microsoft announced recently the public availability of the native response actions in Defender for Identity. Security teams can now directly impact the on-premises AD account from one single experience part of the Defender security portal.

In this blog post, the new long-awaited response actions part of Defender for Identity will be explained. Currently limited based on two actions for on-premises accounts.


With the use of Defender for Identity Response Actions, it is possible to directly target on-premises Active Directory accounts during the investigation from a central location and quickly respond to compromised identities and stop directly further damage and attack persistence.  The ability to configure an action account for Microsoft Defender for Identity is supported by release 2.169.


The previous challenge was mostly based on on-premises identities. For cloud accounts it is quite easy to disable the user, mark it as compromised, prompt for multi-factor authentication, or reset the password. The issues start when the identity is part of the cloud and on-premises environment. Disabling users on the Azure Active Directory will be overwritten by the next sync.

Recently Microsoft announced the new response actions for Defender for Identity. Which makes it possible to directly assign actions directly on the on-premises accounts.

The following actions are newly announced and available for on-premises accounts:

  • Disable user: Disable the user temporarily
  • Reset user password: Prompt the user to change their password during the next logon

Response actions already available for AzureAD:

  • Confirm users as compromised
  • Require user to sign in again


The following prerequisites are needed before correctly using the managed action accounts.

  • Defender for Identity deployed
  • KDSRootKey configured
  • gMSA account
    • Sufficient permissions assigned for AD actions

Which Permissions 

It is not documented which permissions are required for performing the user action. Below is founded during the blog creation:

PermissionForce password resetActions Disable UserAction Enable user
Security Admin RoleYesYesYes
Security OperatorNot visible Not visible Not visible

Creating MDI managed action accounts

These actions will require setting up a managed action account. Recommended is to use a separate gMSA account. gMSA stands for group managed service account. It works similarly to a managed service account functionality and the password will be managed automatically by the Active Directory instance.

Before group managed service accounts can be created a KDS root key needs to be available in the Active Directory environment. If a KDS root key is not yet created, it is recommended to create it at least 24 hours before creating the gMSA accounts.

Creating KDS root key

For checking/ creating a KDS root key use the following commands. When the KDS Root Key is already available, no further action is required for the KDS root key.

Add-KdsRootKey -EffectiveImmediately 

Add gMSA account

Replace the values for the gMSA’s name (MDIgMSA) and the Active Directory domain (securelab.local)

New-ADServiceAccount -Name MDIgMSA2 -DNSHostName MDIgMSA.securelab.local –Description "Microsoft Defender for Identity Action Account" –KerberosEncryptionType AES256 –ManagedPasswordIntervalInDays 30

Don’t forget to assign AllowedPrincipals using the following parameter; -PrincipalsAllowedToRetrieveManagedPassword. Include all the machines where Defender for Identity is running. Ideally based on groups.

Validate gMSA account

Use Get-ADServiceAccount for validating the gMSA configuration. Replace the value for gMSA name (MDIgMSA)

Get-ADServiceAccount MDIgMSA -Properties * | fl DNSHostName, SamAccountName, KerberosEncryptionType, ManagedPasswordIntervalInDays, PrincipalsAllowedToRetrieveManagedPassword

Assign permissions

Microsoft gives guidance for creating/managing action accounts for Microsoft Defender for Identity. As already explained by Sander/ additional configuration is recommended. Another recommended blog is published by Christopher /

The following is advised:

  • Delegating permission in Active Directory to a group
  • Use unique gMSA only for Defender for Identity response actions
  • No permissions assigned at the domain root level. Use least privilege for the Managed action accounts.
  • Use PowerShell for configuration/ assigning permissions

Important Risk Note: When assigning the gMSA account at the domain root level – the gMSA account makes it possible to disable accounts. Use when possible minimal privilege and not delegate the complete domain root level including all sensitive accounts.

Based on my test environment the following situations are the case:

  • Only AdminCount1 = Action correctly performed
  • AdminCount 1 and ACL inheritance is enabled = Action correctly performed
  • AdminCount 1 and ACL inheritance is disabled = Action not performed

Following default AD groups are changing the inheritance part of the AdminCount 1: Account Operators, Backup Administrators, Cert Publishers, Administrators, Domain controllers, Enterprise dmins, Domain admins, Print operators, Schema admins and Server operators. With only the Domain Admin role assigned and inheritance enabled, MDI is allowed to disable the user.

Below image shows user Global Admin2 ( Part of Domain Admins) where inheritance is disabled and adminCount=1

The following AD permissions are required for the MDI action account:

Descendant User objects

  • Force password reset
    • Permissions: Reset password
    • Properties: Read pwdLastSet and Write pwdLastSet
  • Disable user
    • Properties; Read userAccountControl and Write userAccountControl

Source: Managed action accounts | Microsoft Docs

Add action account in MDI

Add the gMSA account in the Microsoft 365 Defender portal. For adding the gMSA account in MDI follow the steps below:

  1. Go to the Microsoft 365 Defender portal
  2. Navigate to Settings -> Identities
  3. Select in the identity blade; Manage action accounts
  4. Select Add credentials
  5. Fill in the gMSA account and Domain, and select Save.

For validating the configuration open the Microsoft.Tri.Sensor or Microsoft.Tri.Sensor.Updater Defender for Identity log file. Search for; EntityRemediatorConfiguration and UpdateConfigurationAsync.

Using the new feature

The new feature can only be used in the Defender Security Portal. In the MCAS or MDI portal there is no UI action visible. The following ways are possible for performing the user actions;

  • Defender Security portal
  • Advanced hunting
  • Custom detections part of M365D

Go to Defender Security Portal and use the Unified Search for opening the specific user page or open the user page directly from other blades (alert/ incidents). All the response actions are visible directly from the detailed user page.

Disable user flow

After clicking Disable User, a warning is visible followed by a confirmation of the action itself. The confirmation is only the status that the process has been initiated. It is no confirmation that the action is correctly performed against the AD user object.

Action can be validated as part of the Defender Action Center history. Below are two situations ( succeeded, failure). Important: User status is the actual result and not the result part of the action itself.



Disable user action can be validated in AD based on eventID 4725 and 4738. When the logs are ingested into Sentinel, you can use KQL to directly hunt for specific actions performed by Defender for Identity response accounts or use Advanced Hunting in M365 Defender.

Force Password Reset

After clicking Disable User, a warning is visible followed by a confirmation of the action itself. The confirmation is only the following state; user clicks on the action and the process has been initiated. It is no confirmation that the action is correctly performed.

Force Password Reset is only available for AD and Hybrid Users.

Validation is exactly as described above in the disabled user flow. Force Password reset will prompt the user to change their password on the next logon.

Important: When the property; “Password never expires” is enabled for the user, it gives no reset. The action shows as success in action center.

Succeeded changes in the attributes can be reviewed using EventID: 4738.


DirTeam: HOWTO: Programmatically add a Microsoft Defender for Identity Action Account to Active Directory

Christopher Brumm/ Medium: Response Actions in Microsoft Defender for Identity

Microsoft docs: Microsoft Defender for Identity action accounts

Microsoft Blog: Microsoft Defender for Identity Response Actions