Remediating rules with inherited values

If you create an audit rule based on an object that inherits properties from a parent object, be aware that if you remediate the rule, the target server object will not inherit the parent object's properties.

Example: If you created a rule for a Registry entry and that registry entry inherited some values from a parent, when you remediate the rule on to a target server, none of the values inherited from its parent will be remediated and the rule will show in the audit results as a difference.

Additionally, if your audit checks ACLs for the File, Registry, or IIS Metabase rules, and the user and group ACL does not exist, then after the audit is run and after remediation, if user and group do not exist on a target, a temporary user and group will be created as an unknown name. The next time you run the audit, it will display as unknown—which does not identify the source user.

Additionally, if you create an IIS Metabase rule from a source server and the metabase object selected for the rule inherits its values from a parent Metabase object, differences will show after an audit is run.

Example: If you remediate once and then rerun the audit and if the source key was not inherited and the attribute has an IED when it was created on a target server, the object will be created, based on parent key inheritance. When you rerun the audit, the results will show the IED as a difference for the object's attribute.
If you have audit results with differences from audits that were created in SA 5.1 and you have upgraded to SA 6.x and higher, when you view those audit results in the upgraded version of the SA Client, the Differences column in the audit results list will incorrectly display the value of -1 differences. To view the actual number of results, open the Audit Result window to see all differences in the results.