Closed snarve closed 3 weeks ago
One final todo item for this:
FilterEvents
function from the utils file. It will be superseded by the FilterEventsOU
and FilterEventsGroup
functions.Method for implementing this (as used in https://github.com/cisagov/ScubaGoggles/pull/204).
SettingChangeEvents
events rule to be also save the group name. NOTE: #204 changes this rule in the utils file. So unless your product has a custom SettingChangeEvents
rule (Sites and Common Controls), skip this step.FilterEvents
function. Split into two functions, FilterEventsOU
and FilterEventsGroup
which identify setting changes that apply to OUs and groups, respectively. NOTE: #204 changes this rule in the utils file. So unless your product has a custom SettingChangeEvents
rule (Sites and Common Controls), skip this step.NonCompliantOUsX_x
rule to use the new FilterEventsOU
functionNonCompliantOUsX_x
rule. Name it `NonCompliantGroupsX_x"utils.GroupsWithEvents
instead of OUsFilterEventsGroup
function{"NonCompliantOUs": NonCompliantOUsX_x, "NonCompliantGroups": NonCompliantGroupsX_x}
The report details should look like this:
"ReportDetails": concat(" ", [
utils.ReportDetailsOUs(NonCompliantOUsX_x),
utils.ReportDetailsGroups(NonCompliantGroupsX_x)
]),
Note that the report details will need to be modified again soon for the detailed report epic. If you want to see what the report details would look like with both the group filtering and detailed report enhancements, see GWS.CALENDAR.1.1.
The status should look like this:
Conditions := {count(NonCompliantOUs2_1) == 0, count(NonCompliantGroups2_1) == 0}
Status := (false in Conditions) == false
🐛 Summary
User groups can override settings/policies implemented at OU level. Current implementation does not have support to handle this use case and thus some inherited group level policies may report a false positive in the report.
Each baseline policy needs to be updated to handle this use case.
Next steps:
Related issues: