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.
Thanks, Darrick, and I am probably still not understanding many things. I thought those snippets could be added to a custom workflow to automatically disable AD/Azure accounts when the workflow is attached to a detection as an automation. Maybe that is not the case - we just had a detection, the workflow ran without error - but the account in question was not disabled.
Apologies about the delayed response. I’ve been OOO since the 18th. Trying to get caught back up with all my missed replies.
The two Snippets you are talking about are custom and designed to take input from the investigation itself. They wouldn’t work to use from a Workflow.
The concept of the Snippet logic is good, you just need to tweak the logic a bit. I believe the Snippets are designed to ingest an Account RRN.
You could copy the steps the snippet has and create your own. It would need a bit of modification though.
If it were me and I wanted to get started learning to use InsightConnect I would make a single step workflow. The trigger should be the Rapid7 InsightIDR Investigation Trigger or the Alert Trigger. Activate it and let it run for a day or two until you have some investigations that have been captured by InsightConnect.
Next you can go and edit that workflow. Add a step, and then go rerun a job that was already captured. This will pass the investigation trigger payload through again as if it were a net new job. You can add and delete steps until you have it to your desired state. Rather than testing the disable actions or revoke user session actions, just use a get user details step to locate them, rather than impact them.
By leveraging real data and a real use case, it will help you to grasp the concept of the workflow builder. If you get stuck at any point please don’t hesitate to reach out.
No apologies needed, Darrick, and thank you very much for sticking with this thread and my learning curve. The good news is I finally got a 7 step workflow that gets triggered by an detection rule, disables the AD account, disables the Entra/Azure account, revokes sessions, and then sends an email to our internal Sec Ops team formatted with account and success/fail info. I dev’d it using a test account and running a test every time I added a step until it ran all the way through with success. Very basic and probably needs error checking logic but it’s a start.
Yes, now I get the snippets I referenced are intended to be used directly from a live investigation. Apologies for causing confusion to anyone - especially those new to ICONN workflows like I am.
I am glad you were able to get it working. The test accounts are key. I recommend to all my new customers to get a designated asset and user that they can work with. Doesn’t need a crazy license, just needs to be a valid user. This way they can safely build and test without impacting anyone.
Continue to post your questions. I meet with many customers each week, and while they might be silent in terms of posting, the Discuss posts are getting viewed. It is nice that everyone can learn from your questions.