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.
S
Scott Brandt
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.
S
Santo'la McKenzie'la
This is a big problem for us and like others have said the impact for hybrid users outside our business hrs is massive
FortifyIT
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.
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!
C
Christopher Culligan
Rich Mozeleski I am guessing it might be the approach of identifying on-prem domain controllers for targeting to push lockout commands?
M
Matt Miles
Rich Mozeleski Another tool we have in place for larger clients continuously disables the account for a period of time, it looks like every 30 seconds it tries to disable it again. While this fills up the audit logs, it is a quick and dirty solution to the problem.
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
P
Peet McKinney
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.
Load More
→