Just coming back to this critical need to note that other MDR's seem handle this with an agent on the DC's, considering the Huntress agent is on most of our DC's disabling an account there is pretty straight forward. ¯\_(ツ)_/¯. Hope this moves to "in progress" soon.

Using the Huntress agent on the domain controller associated with that customer organization would be a great way to handle this and would not have M365 licensing implications if the customer tenant isn't licensed for conditional access.

Please at least go back to locking the user account in M365 initially, and at least even revoking all M365 session/access/refresh tokens, even though the user will eventually be re-activated by the AD Connect agent after that point. Something is better than nothing while we wait for a better solution.

This is a big problem for us and like others have said the impact for hybrid users outside our business hrs is massive

just let it read if the MSP did the remediation steps, if yes, then it can be enabled. If no remediation has been approved, just keep disabling.

IMHO the simplest way for Huntress Team to tackle this problem is to utilize the Huntress Agent installed on the domain controller. If an MDR event is triggered that requires isolation, the MDR component would talk to the Huntress Agent installed on the DC and disable the account from there. Option B as others have mentioned is to find some other way to block off that user's access from the 365 side, e.g. a "block all" compromised users Conditional Access Policy.

I wonder with the Defender integration they could leverage Defender for Identity's capability to disable on-prem AD accounts...

Obviously this would require additional licensing on the client side.

This is a huge deal for us as a majority of our customer base as an MSP is running in hybrid environments. I encourage the Huntress team to come up with a way to support identity isolation in hybrid environments. We are looking into some other internal automation to replace this feature but spending time and effort to plug a gap with Huntress’ service is not something I’ve had to do before.

Wanting to add to this, hoping to bring it back on top. It's a crucial function that absolutely should be included in the product as it otherwise leaves a gaping hole in security. Example, 2am, user get's compromised, we are sleeping, Huntress revokes MFA, revokes 365 sessions, disables account in 365. 47 minutes later, the account is re-enabled, we are still sleeping, bad actor potentially has access to the account again. We don't see it until we are up 3 hours later and 3 hours is enough time to do serious damage.

It would be great if the Huntress Agent deployed on the DC's could be used to disable the user account. That would fix this issue. 365 revoke sessions, MFA, disable account, Huntress agent on DC sets the AD account as disabled.

This would be a great, and crucial, function to get implemented.