Response Actions in Microsoft Defender for Identity

7 min readApr 5, 2022

A first look…

Last week Microsoft announced the general availability of Response Actions in MDI. This was preceded by the possibility to configure action accounts with release 2.169 in January.

Since this is a long-awaited feature of mine, I didn’t hesitate to look into it a bit — here is my report about it.

What does the feature do?

MDI has been more of a watcher in Active Directory in the past. Mainly logs from the domain controllers and traffic from network cards are analyzed and information from the AD and the member servers (SAM-R) is collected and analyzed. Even if an attack is detected, MDI does not intervene.

This should now change (a little) with the Response Actions: MDI is enabled to make changes to the AD.
Initially, this is limited to disabling user accounts and forcing a password change in the Active Directory — but the potential for further use cases is enormous.

What problem does this feature solve?

With Microsoft Defender, Microsoft provides us with an extended detection and response solution which, among other things, has the idea (together with Microsoft Sentinel) of providing a central portal for the security operations teams.

Many attacks are currently focused on the OnPrem environments and of course the Active Directory there — so it makes sense that the SecOps teams are able to act from a central location here as well.

Example: Credential Phishing

A practical example are credential phishing attacks. Although there are various very effective countermeasures (MFA, Safe Links, Windows Hello,…), it happens again and again that we are alerted, e.g. by alarms in Defender, that a user has clicked on a link that may have led to the user’s credentials being compromised.

Until now, it was only possible to mark this user as compromised in the AAD, thus setting the user risk to high and forcing the (hopefully) configured user risk policy to force the user to perform a password reset at the next logon to the AAD. Disabling a hybrid user was not even possible at this point and for AD-only accounts we had no recourse at all.

After setting up the new feature, it is now possible to force the user in Active Directory to change the password and to deactivate him if necessary. This is possible for AD-only, hybrid and also for AAD-only accounts (and guests).

Implementation

Microsoft has published a guide for the implementation which is a good foundation. If you have already used MDI, you should meet all the requirements for this feature. The only change is that Group Managed Service Accounts (gMSA) are now mandatory for this feature.

In the first production implementations I did, I didn’t assign permissions for the group-managed service account domain root level, but only on selected OUs and with groups, and preferred using Powershell over the GUI.

Note: You will need one account per forest!

The now created and authorized account is still stored in the MDI and after some waiting the feature is usable.

How can I use the feature?

As announced by MS, the new features can only be used in the Security Portal (that means not in the MCAS or MDI Portal).

For testing I use the following accounts:

Ernie is an AD only user
Big Bird is an AAD only user
Bert is a synchronized hybrid user
Google Guest is a guest user

The first thing to notice is that all users can be disabled, but only for the AD (and hybrid) users a password reset can be triggered at this point.

I have observed that in the beginning, especially in larger ADs, it can take a while for the feature to work.

What happens if I disable a user?

After clicking Disable Users, a warning is followed by a confirmation. But be careful: this confirmation only says that the process has been initiated — not that it has been performed successfully.

After a short time, these actions can be seen as jobs in the Action Center history:

Active Directory and Hybrid User:

If the user originates in AD, MDI will take action and try to disable the user account. If successful, this will result in events 4725: A user account was disabled and ID 4738: A user account was changed.

Here is a suitable XML Filter in Event Viewer:

Especially if you have many DCs it makes sense to collect the logs centrally. My tool of choice is Microsoft Sentinel:

Alternatively, the data is also available (not as detailed and with significantly more delay, but better prepared) in the Advanced Hunting of the Defender:

Azure Active Directory and Guest User:

If the user originates in AAD or is a Guest User, MDCA will take action and try to disable the user account. This results in two entries in the AAD Audit Log:

Of course, these logs can also be queried in Sentinel:

What happens if I force a password reset?

Currently the Force Password Reset Action is only available for AD and Hybrid users in the Security Portal. A reset also results in an event 4738 which can be displayed with the above filter:

In Sentinel, it is quite easy to filter using %%1794. (Apparently this is the code for <never>):

Anything else I need to know?

Be careful with Password Never Expires!

During testing I noticed that the password reset did not work for all users. The reason was the flag “Password never expires”, which prevents the flag “User must change password at next logon” from being set. If you try to set the flag via PowerShell you will get an appropriate error message:

Unfortunately, MDI does not report an error for this action. Means: there is a success both when triggering the action and in the Action Center. In addition, this is also only noticeable in the event logs by the missing event 4738 (see above). So you should really test this feature and check if you have user accounts with “Password never expires” in your environment.

Which Permissions do I need to use this feature?

I have not yet found any documentation on the permissions required — so here are my observations:

With the Security Admin role, the described feature is fully usable.
With the Security Operator role (and MDE RBAC enabled) you can see the users from AAD but not the AD-only users.
As a security operator you get Disable User displayed but then an error message.