First published on MSDN on Jan 06, 2008
A few questions have come up of late that I thought might be of interest so am reposting, along with the answers, here.
1. Is it possible to configure a rule/monitor such that no override can be applied for a period of time, regardless of the permissions level of the operator? Is it possible to lock a rule so that no override can ever be applied?
There is no way to apply security on either rules or monitors – which are the only targets of overrides. Further, overrides themselves cannot be secured. The authoring console may offer some possibilities in this area when it releases – at least In terms of creating custom rules/monitors and specifying what properties of the rules/monitors are able to be overridden.
OpsMgr does offer various security groups that will restrict what the user is able to do - but there is no way to prevent administrators (or even authors) from modifying or introducing overrides if an overrides are available.
Another interesting concept is the idea of ENFORCED overrides. If you look at the overrides available on many objects you will note the far right hand column has an option to enforce the override. This is shown below for a state collection rule and a discovery rule.
Enabling the enforced flag for an override indicates that this override should take precedence over any other override of the same type configured on the same object. In other words, configuring an ENFORCED override ensures the it will always win against overrides that aren’t enforced. As such, the use of ENFORCED overrides could be of benefit for ensuring proper override application. Enforced overrides can only be configured by administrators and authors. Also note that enforced overrides are only designed to be used in non-sealed management packs. We can discuss any scenarios where setting an override on a sealed management pack would be needed.
While there is no way to secure an override such that it cannot be changed we could use some of the other features opsmgr offers to be able to track what changes have been made. None of these are the perfect solution but may be useful in the absence of a better option.
Reports
The Microsoft Generic Report Library contains a couple of reports that provide
detail useful for tracking down changes in the environment.
The Configuration Changes report that will track what configuration changes have
been made during a specified time period. Here is an example.
The overrides report, also in this section details all applied overrides
Event logs
Additionally, the event log is useful to track when a configuration change has taken
place. By pairing the opsmgr event log (look for event 29103) and the security event log
(make sure we enable object access monitoring), it is easy to track configuration changes based on time stamps – including which operator made the change.
I would agree that there is room for improvement with our auditing. I’d be happy to file a design change request on your behalf. Two potential requests come to mind from reviewing this question
1. Add a more direct method for change auditing in the OpsMgr system.
2. Add the ability to configure time based addition and deletion of overrides and the ability to configure a ‘locked’ override for a specified period of time.