Background
The response action of blocking a compromised account is important to have available. Regardless of solution one must be able to quick and easy be able to block an account. In MDI (part of Microsoft 365 Defender) it is possible since some time ago to configure an MDI Action Account, lately the option to run with the system account of the Domain Controller has been added to this feature and therefor you don’t have to configure the gMSA account.
Using system or a custom gMSA account
The choice is made based on organizational structure, Tiering/RBAC, MSSP partner. Basically, if you are required to delegate the permissions to only allow actions on accounts in certain OU’s, then you must use a custom gMSA accounts.
For example, if you have a MSSP partner monitoring your security and take actions to discovered threats, a so called MDR (Managed Detection and Response), you have an option to control to which accounts the MSSP can take actions.
The available actions are:
- Disable user in Active Directory: This will temporarily prevent a user from logging in to the on-premises network. This can help prevent compromised users from moving laterally and attempting to exfiltrate data or further compromise the network.
- Suspend user in Azure Active Directory: This will temporarily prevent a user from logging in to Azure Active Directory. This can help prevent compromised users from attempting to exfiltrate data and minimizes the time between Disable user in Active Directory and the sync of this status to the cloud.
- Reset user password – This will prompt the user to change their password on the next logon, ensuring that this account can’t be used for further impersonation attempts.
From an MSSP perspective, this feature is very useful since there wouldn’t require customer access (VPN or other kind of access) to respond to threats. Even though this feature is very popular for MSSPs, you will still want to have this option if you have your internal security operations to be able to respond from the portal you are currently working in.
Even though this feature is very popular for MSSPs
To learn how to create and configure the gMSA account you can start with this link
https://learn.microsoft.com/en-us/defender-for-identity/manage-action-accounts
Troubleshooting
(The troubleshooting path will be updated based on troubleshooting session done with customers)
There 2 primary sources for troubleshooting this, sensor logs and event logs. Preferably the logs are sent to SIEM solution (like Microsoft Sentinel).
Using Sentinel (or look in the event viewer, or if you have another SIEM solution in place).
SecurityEvent | where Account has "gMSA-MDIAction$"
Note the $ character in the account name, gMSA account is more like a computer account. It’s the type of msDS-GroupManagedServiceAccount.
If the account doesn’t have logons ending with a $ (like a computer account), then it’s not a gMSA account and start there by creating a one.
https://learn.microsoft.com/en-us/defender-for-identity/manage-action-accounts
This can also be checked on the logon event (this will trigger 4625, logon failed)
Verify that the AccountType is “Machine”
Successful sign-in:
Account is not allowed to logon as a service
If the gMSA Account is setup and configured correctly and there is still event 4625 being logged.
Check the Status property of the login event
0xc000015b indicates that the account is not allowed to login0xC000015B
STATUS_LOGON_TYPE_NOT_GRANTED, A user has requested a type of logon (for example, interactive or network) that has not been granted. An administrator has control over who can logon interactively and through the network.
More information about the Status property can be found here:
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
To address this issue you need to create a new or update existing policy to allow that account to logon as service on the target system (the DCs)
Successful events effecting the user you try to take action on
The following query will find events of enabling and disabling a user
SecurityEvent
| where EventID in(4738,4725,4722)
| where Account contains "gMSA-mdi-action$"
| where TargetAccount contains "test" //the user you want to take action on
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738
Hope this helps!
We will continue to update this post if we run into other related troubleshootings
//Happy Hunting