AD Connect and MDR for Microsoft 365
under review
M
Michael Abt
So its great that Huntress can disable a user but the issue is that when it sync's back to the on prem server if that user is not locked will re-enable the users account and remove the block. This is an issue because we want the account to be locked until we can look into it but if its not locked on the server the user just has to wait until the sync and then they are re-enabled.
J
Joel DeTeves
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.
A
Anthony Rankine
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.
Rich Mozeleski
under review
We're looking at developing a solution for this now. More to follow soon!
H
Hans'la Schmidt'la
Rich Mozeleski I am guessing it might be the approach of identifying on-prem domain controllers for targeting to push lockout commands?
M
Mason Walker
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.
A
Adam Ruffolo
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.
Patrick Sofo [Security Product Manager]
Merged in a post:
Disable Accounts in on Prem AD when Disabled in Entra
V
Veronica'la Blanda'la
Currently if an account is disabled in Entra by Huntress, it is not disabled in the on-prem AD. If Entra Connect (Née Azure Connect) is configured, the user is automatically re-enabled. Please use the Huntress Agent deployed on DC's (or some heretofore unknown sorcery) to disable the account both on M365 and in AD.
DJChupa13
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.
B
Ben Smith
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.
P
Paul Hogan
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.
W
Wilson'la Runolfsson'la
Paul Hogan: CA policy is the perfect way to do this, I've heard Huntress discuss doing this but haven't seen any word on implementation