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.

My org is craving this feature big time!

I even asked Huntress support if this could be circumvented via the Huntress API, but unfortunately the API doesn't directly report on auto-isolation events.

If it could, my org could set up some automation to write an extension attribute flag to associated accounts. The flag could be the filter scope of an advanced sync rule to disallow ADSync the ability to sync over any sort of "enabled" flag. Not the best work-around due to timing delays, but hey, it's something.

The latest update (https://support.huntress.io/hc/en-us/articles/19352044191635-Managed-Microsoft-365-Identity-Isolation) stating "we are no longer attempting to disable the identities that are synced from on-premises AD" is extremely disappointing.

We historically used to be able to remove the sign-in enabled attribute from the entra ID connect process to allow Huntress to do the job. This is not even an option any longer

There must be other ways to achieve restricted access to a compromised account (i.e. CA policy mentioned below by Paul) rather than no longer attempting to protect these accounts. We have many customers still using domain controllers with Entra ID Connect which now feel largely unprotected.

I understand this is an issue with most services like 365 MDR. If AD Connect is in place, it will just unblock a blocked 365 account. Almost all of our clients use AD Connect. A potential workaround would be the creation of a conditional access policy for the exploited user account. A conditional access policy that denies access or one that is so strict the account is unable to gain access.