Using SCOM to Monitor AD and Local Accounts and Groups
Updated: Jun 30, 2022
For those that have deployed SCOM without ACS or another monitoring service, but don't have a full-blown IDS\IPS. With a little effort it's possible to at least monitor and alert when critical groups and accounts.
As a free alternative, ELK (Elastic Search) or Security Onion.
The following example is SCOM being configured to alert when Domain Admins is updated.
On the Authoring Tab, Management Pack Objects, Rules, select 'NT Event Log (Alert)'
Create a new Management Pack if required, don't ever use the default MP
The 'Rule Name' should have an aspect that is unique and all subsequent rules to assist searching later on. Rules that monitor Groups or Accounts will be pre-fixed with 'GpMon'.
The 'Rule Target' in this case is 'Windows Domain Controllers', it's a domain group.
Change the 'Log Name' to 'Security'.
Add Event ID 4728 (A member was added to a security-enabled global group)
Update the Event Source to 'Contains' with a value of 'Domain Admins'.
Update the priorities to High and Critical.
Sit back grab a coffee (or 2) and wait whilst the rule is distributed to the Domain Controllers, this can take a while.
Test the rule by adding a group or account to Domain Admins, in the SCOM Monitoring tab, an alert will almost immediately appear with full details.
Now for the laborious bit, create further monitors for the following:
Schema and Enterprise Admins
Any delegation or role-up groups
SCCM Administrative groups
CA Administrative groups
That's the obvious groups covered, now to target all Windows Servers and Clients (if SCOM has been deployed to the clients)
Local accounts for creation, addition to local groups and password resets.
Applocker to alert on any unauthorised software being installed or accessed.
Finally here's what Microsoft recommens.
With a few hours of effort and you'll have better visibility of the system and any changes to those critical groups.