We have a hybrid AD/Entra-Azure environment so I am looking for an automation approach where we can disable an Active Directory account in response to an cloud service event for an Entra user account. The reason is: If we automate the account-disable in Entra/Azure our AD/Azure sync will over-write and re-enable the account.
Good afternoon Craig.
This shouldn’t be a big deal. You can use the Azure AD admin plugin to revoke the user sessions, you can then use the Active Directory LDAP plugin to disable the user on prem.
Is there a specific step you are stuck on?
Where I am stuck right now is configuring the distinguished name for the action. I understand what the DN attribute is in AD but can’t find any documentation in R7 for what needs to go in that box.
We are a hybrid environment as well. For both Entra and onprem AD we first pull the user and confirm we only get one, then the DN from that output is used as the input on the AD reset. And for Entra we use either the UPN or the pulled ID from the previous get.
You will first perform an LDAP query to find the user in your AD environment. The results of this will return the DN for the user. Your workflow already has some user information being passed to it from one of the previous steps. You pass that variable into an LDAP query search.
(sAMAccountName=<insert user variable>)
You will pass that DN from your search results to the disable user step. I don’t know what your actual options are available to you, if it is sAMAccountName, principalName, etc. You will almost always have to first do a lookup of the user though in AD before you can get their DN.
Thank you very much to both of you - very helpful once again. Building InsightConnect workflows is reminding me of the learning curve with Powerautomate.
Craig
Thanks, Brandon. Do you have an “Azure AD sync” action in your workflow immediately after your “AD Account Disable” action? I’m trying to teach myself how to do that next to minimize the amount of time the account is still in an enabled state in Azure.
no, and what we found was that even with the Azure revoke, changing the AD password twice (that doesn’t require a sync to replicate to Azure) and we have a group that prevents logons, that there is still about a 60 minute window where the user has access. And if they have a page or an email open, it will not kick them out so they can still see some information. We just document this
Thanks, Brandon. I am thinking if the workflow disables the AD account, then revokes sessions, then disables the Azure account the same thing is effectively achieved. From my quick research there understandably is not a way to call an AD Azure Sync from InsightConnect.
I stumbled across the fact that you get the “Disable User with Azure” and “Disable User with Active Directory” snippets by default when you install the Azure Admin and AD Admin plug-ins. I figured their had to be some base functionality for account disables and session revocations since those are some of the first SOARS sec ops staff want for incident response.
I am not sure what you mean Craig.
We have two Snippets that are available, you can activate them through the investigation panel in IDR.
They were built as part of the Active Response offering for our MDR service but are available for any customer to leverage if they have ICON and IDR.
Just about to start working on something similar. What we do have as a halfway measure is a conditional access policy that blocks all resources scoped to a cloud security group that ICON adds the impacted user to (after revoking session). The thought process being avoiding having to wait for a sync from on prem to occur.