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.
Introduction
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.
Challenge
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
Prerequisites
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:
| Permission | Force password reset | Actions Disable User | Action Enable user |
|---|---|---|---|
| Security Admin Role | Yes | Yes | Yes |
| Security Operator | Not 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.
Get-KDSRootKey
Add-KdsRootKey -EffectiveImmediately
Get-KDSRootKey 
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 30Don’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, PrincipalsAllowedToRetrieveManagedPasswordAssign permissions
Microsoft gives guidance for creating/managing action accounts for Microsoft Defender for Identity. As already explained by Sander/ Dirteam.com additional configuration is recommended. Another recommended blog is published by Christopher / Medium.com.
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:
- Go to the Microsoft 365 Defender portal
- Navigate to Settings -> Identities
- Select in the identity blade; Manage action accounts
- Select Add credentials
- 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.
Succeeded
Failure
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.
Sources
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
