One of the drawbacks to the current design of the Security Monitoring Management Pack that I felt needed to be improved the reliance on some pre-canned GPOs that I provided for documentation. The main issue at hand is that I have a lot more turned on in these GPOs for auditing purposes than what is actually being monitored by the management pack. This was in large part due to needing to turn on auditing settings to see what types of events are generated and mining them for useful information that is worth generating alerts. This leads to a bit of a documentation mess in that I’ll reference in my documentation for individual rules/monitors if something needs to be turned on, but that also requires a lot of reading/surfing for the management pack users, especially if they do not want to simply use the GPOs I provide… until now.
The first step was creating an audit policy monitor type to look at a server’s individual audit settings. I’ve documented that here.
With the help of Ian Smith and Kevin Justin, we were able to build out a distributed application that will allow users to see which required audit settings are set. We will also be incorporating some new views into the MP to make it easy for users to see which settings needs to be adjusted. I’ll address the new views in a future post. For now, we will cover the distributed application.
The DA will be broken down by domain (there will be a distributed application for each domain in your forest). Each domain is further broken into two separate groups: Domain Controllers and Member Servers. The reason is fairly straight forward. Domain controllers, by default, are isolated in their own OU and typically have different auditing settings configured. Member Servers are a bit more complicated, as in theory they can have different audit settings. I’ll cover this in a bit more detail in a bit.
For now, let’s look at DCs. As you can see from the screen shot below, new monitors have been created for each audit configuration setting. For domain controllers, these are on by default. It’s also worth noting that these monitors do not generate alerts. This was done to avoid unnecessary alerting. If too much state change is an issue in your environment, you may want to consider turning off any that you have no plans of fixing. The individual monitors roll up to a dependency monitor (which uses a worst of algorithm), so if any audit setting is not configured correctly on one domain controller, the dependency monitor should be yellow (see screenshot below). Since DCs are all in the same OU, I would expect to see all of your DCs either yellow or green, though I suppose if there’s an issue with GPO application, it’s possible for this not to be the case. In the screen shot below, you’ll see that the command line process auditing setting is not set correctly on my DC, and as such, the MP is not fully monitoring domain controllers on this lab. This particular monitor, for the record, looks at a registry key, though most of these will look at auditpol.exe results.
Member servers function in a similar capacity, though there are a few caveats. Member server monitoring is OFF by default. This is because these monitors would effectively be targeted against every server in the environment. This could potentially generate a lot of state change related items in your production environment and potentially cause performance issues with SCOM, not to mention clouding up Health Explorer with a whole bunch of servers where one audit setting is not set correctly. There is one exception to this. Member server auditing is enabled by default for your management servers. This is done via override within the Security Monitoring MP. As such, when you look your member server monitoring, you’ll see data from the management servers. If your have one audit policy per domain, as most environments typically do, then you’re done. You really don’t need to configure anything else. However, if by chance you have audit settings set at the OU level and have multiple OUs per monitored servers, you may want to consider turning on these monitors for one server in each OU that has a different audit policy. You’ll have to do this on a monitor by monitor basis, so I’d recommend creating a SCOM group containing the Windows Computer Object for a single server from each OU and enabling the monitor for that group. In a smaller environment, you could consider simply turning this on for all Windows Computer Objects, but I don’t recommend that. Member server monitoring will look something like this out of the box:
You will see an enabled monitor for your management server, and everything else will be not monitored. If your audit policies are determined at the domain level, you’re done. This view will show you if your audit settings are set correctly for DCs and member servers. A DA will also enumerate for each domain that you are monitoring. However, if you have customized your audit settings and set them by OU, then you may want to consider additional configuration. You should ignore the not monitored domain controllers, since they are covered under the domain controllers audit settings discussed above. Unfortunately, that is present due more to how targeted classes roll up in SCOM. With that said, if you are setting audit policies at the OU level, you may find it necessary to turn on these monitors for additional servers. In the example below, I turned on one of the monitors for my SQL server:
This can be done via override. Now it’s worth noting that you should really do this for each audit setting. That can be a bit tedious, and you may find the need to add more servers as new OUs are created. My recommendation would be to create a SCOM group in your unsealed overrides MP and simply do a one time override for the group for each of these monitors. At that point, you can simply add servers to the group.
Now to the downside. The biggest issue that I see with this is the need for Agent Proxy to be turned on. I’ve mentioned in previous articles that this is some sort of security feature, though I’ve yet to see any documentation as to what it’s mitigating against. My best guess would be a compromised agent potentially being used to submit bogus discovery data, though I’m not aware of any such threats associated with this or what an attacker would gain by utilizing this. Most of my customers simply turn this on for every agent by default. As it is, you most likely have this on for domain controllers if you use the AD Management Pack along with a number of member servers as it’s required in the SQL and SharePoint Management Packs. If this is a big deal for you, then you probably don’t want to turn on the discoveries, as that will trigger an agent proxy alert for whatever you turn on.
One other slight caveat is that I may choose to rewrite this to target Windows OS instead of Windows Computer. That’s not that big a deal, and I’ll update this article accordingly.