Wednesday, May 24, 2017

SCORCH 2016 - Protecting Active Directory Security Groups

So last year I did a fun segment for SCOM on How to Monitor Domain Administrators Group to detect unauthorized modifications to the Domain Admins, Schema Admins and Enterprise Admins groups in Active Directory. Now that we have SCORCH setup in our lab its time to take it to the next level. Once SCOM detects the change we can use SCORCH to disable the offending account, remove it from the security group and make a notation as to why the action was taken.

Modifying the Rule:
First thing we need to do is make a change to the rule we created in SCOM so SCORCH knows what to look for. In Authoring > Rules do a search for the rule you created. Right Click and select Properties. When the Properties window opens go to the Configuration Tab. Under Responses select Edit

In the Alert - Properties Click Custom alert fields

In Custom Alert Fields add DAModAdd to Custom field 1 and $Data/Params/Param[1]$ (the distinguished name of the user who was added to the group) to Custom field 2. This will tell SCORCH what and who to look for so it will kick off the Runbook when this alert is generated. Click OK to everything and you are done with SCOM for the moment.

Creating the Runbook:
This is what the Runbook looks like:
 
We are monitoring SCOM for a specific alert. It then pulls the user data from the alert and disables the account. Then we make a notation in the account as to why it was disabled. It is removed from the Domain Admins group and we then update the alert in SCOM. I also used two variables which I will get to in a moment.

Monitor Alert:
We are looking for DAModAdd from SCOM so we want CustomField1 Equals DAModAdd

Disable User:
For Disable User you need the distinguished name which we setup in the parameters of the SCOM Alert earlier.

Update User Properties:
The same custom field used again to identify the user to change. Then added Notes from Optional Properties. In the notes field I put (you can put whatever you like):
Unauthorized Group Access! User disabled by Orchestrator {Date}

Where date is the first variable I added. I invoked the NOW() wildcard in order to date stamp the account so you could tell when the account was disabled.

Remove User from Group:
Now we pull the user out of Domain Admins.

The second variable I created was {Domain Admins} as I plan to use it in later Runbooks.

Note: At the time of this writing there is a bug in the Active Directory Integration Pack. Administrators are reporting an error when trying to add or remove a user from an AD Group. The error "unknown exception caught" shows up in Runbook Tester and fails at this step. The only known fix that I was able to find is to either roll back to a previous version of the ADIP or use the PowerShell IP with the following syntax and variables described earlier:

Remove-ADGroupMember -Identity "{Domain Admins}" -Members "{CustomField2 from "Monitor Alert"}" -Confirm:$False

If someone finds a fix for this please feel free to share it in the comments. 

Update Alert:
Finally we update the SCOM alert. Some people like to just close the alert at this point but I would rather change the Resolution State and close it myself. I created a custom state called User Disabled. You can refer to Creating and Setting Resolution States for help with that.

Go ahead and run it in Runbook Tester. When it executes we should get a disabled user with this in the notes:

And an updated alert

As we did with the monitoring of Domain Admins, Schema Admins and Enterprise Admins you can do the same here. Just change the Custom field 1 to:

SAModAdd - User Added to Schema Admins
EAModAdd - User Added to Enterprise Admins

From there you can create the appropriate Runbooks.


More to come!

If you like this blog, give it a g+1

No comments:

Post a Comment