Auditing Policies – Cygna Auditor for Active Directory

Cygna Auditor for Active Directory auditing policies have two main purposes, to protect objects from being changed or to exclude specified activities from being captured.  These auditing policies are applicable at the domain level in Active Directory (AD) when using agent-based auditing.  Once a policy is configured via the wizard, the agents in that domain will automatically pick up the configuration within a two-minute period and start enforcing the policies.  If no policies or exclusions are configured with agent-based auditing, no objects will be protected, and all events will be captured.

Protection

With Cygna Auditor for Active Directory configured with agent-based auditing you can see all changes to AD.  It is also possible to configure an alert so that you can be notified when a specific change occurs to verify it is valid and does not pose a security risk.  Even though you can follow what is happening in near real time you are still in a reactionary mode.  Protection is designed to prevent unwanted changes to critical objects from even happening in the first place.  With protection there are only specific actions and objects that rules may apply to.  These restrictions are required to not impact the necessary modifications needed by AD to function properly.  Actions on supported objects that can have protection rules are:

• Deletes
• Modify events for GPOs
• Modify or other events for group, contact, printQueue, volume, organizationalUnit, and container object types

A common use is to implement protection auditing policies to prevent changes to critical AD objects such as Enterprise Admins or Domain Admins groups.  Membership in either of these groups gives privileged access to AD and therefore many other systems that leverage AD as their identity provider.  This makes them the target of bad actors looking to elevate privileges to accomplish their nefarious goals.

The place to configure a protection audit policy can be found on the Configuration tab / Active Directory tile / Auditing Policies tile.  Existing policies can also be edited from the manage domain (gear icon) Domain Auditing Policies tab for each domain listed under the Domains tile as well. To launch the wizard to create a new audit policy, select the plus icon in the upper right-hand corner of the Auditing Policies page.

General Page

The General page of the wizard allows you to set the following:

• enable / disable the policy
• specify the domain the policy will apply to from the drop-down list
• name the policy
• description field

The following example is a protection policy for the Enterprise Admins group.

 

Who Page

The Who page allows you to specify which user accounts the policy does or does not apply to.  If you leave the Who drop-down set as Apply rules to all user accounts, then the policy applies to all.  To select specific users, change the drop-down to Apply rules to the selected user accounts.  If you specify to include one or more users, then the policy only applies to them, and all other users will be inherently exempt.  If you specify to exclude one or more users, then the policy will apply to everyone except them.

For the Enterprise Admin group membership protection example, you can choose to protect that group from membership changes no matter which user is attempting to make the modification (even if they have the native AD permissions to do so) by leaving this setting as Apply rules to all user accounts.  If you want to prevent everyone except a particular user, for example Frank Whitten, you would change the drop-down to Apply rules to the selected user accounts and then add that account and set it as exclude.  That policy would then prevent all users, except Frank from being able to modify group membership on the Enterprise Admins group.  Note that Frank would still require the appropriate native AD permissions to make the change.  The search active directory field allows you to find the desired accounts to include or exclude if so desired.

What Page

The What page of the wizard allows you to define what actions, object classes and attributes the policy will apply to.

• What (actions)

  • Create, Modify, Remove, Move, Rename and Restore check boxes

• Object type

  • Match all or only specified object classes

• Attribute

  • Match all or only specified attributes

For the Enterprise Admins group membership protection example, all actions except create are defined for the member attribute of the group object class.

Where Page

The Where page allows you to specify which objects you want the policy to apply to.  The policy can be set to Apply rule to all objects or to Apply rule to selected objects.  If you change the drop-down to Apply rule to selected objects, then you have two different ways to locate and select the objects.  The Search Active Directory selection provides an auto complete text field that will start returning selectable results in a list below after the first three characters are entered.  This allows for quick selection of one or a few objects or containers. The other option is to select the Browse Active Directory drop-down that allows to see the hierarchical view of containers for the domain. If you specify to include one or more objects, then the policy only applies to them, and all other objects will be inherently exempt.  If you specify to exclude one or more objects, then the policy will apply to all objects except the ones set as exclude.  If a container is selected, then you can choose how the rule will be inherited.  The rule can apply only to the container object itself, child objects or both the container and child objects.

For the Enterprise Admins group membership protection example, select the Apply rule to selected objects and search for and select the Enterprise Admins group.  Since we only want the rule to apply to that group and no others, select the include drop-down.  There is no option for inheritance as this object is not a container.

Actions Page

The Actions page defines what the policy will do when an event that matches the criteria specified on the Who, What, and Where pages is encountered.

In the Auditing section, the Enabled auditing toggle is used to set if audit events that match the criteria of the policy will be captured by the agent writing to the database.  Keep in mind that the default behavior is to capture all audit events so this would be used to turn off auditing, this is covered in more detail in the next section.

The Protection Enforcement section is where the protection policy settings are set as follows:

• Enable protection

  • If enabled, this will prevent the change form occurring usually returning an Object not found error to the user attempting to make the modification

• Write a Protection Policy Event to the Microsoft Event Log

  • If enabled, whenever an event matches a protection policy, an event will be written to the Microsoft event log on the domain controller where the change was attempted. This can then be utilized by systems management or security solutions that monitor event logs to trigger an organization’s internal process.

• Write a Protection Policy Event to Cygna Auditor for AD audit log

  • If enabled this will write a prevention event to the Cygna Auditor for AD log

Once the policy is configured as desired save it and it will take effect in around two minutes.

Auditing Exclusions

The default behavior of Cygna Auditor for AD when using the agent based collection method is that every AD change gets captured regardless of how native auditing is configured.  Some organizations may not want to capture some specific events to minimize the volume of events being captured or simply do not have an interest in capturing certain kinds of events.  If an audit exclusion policy is configured the events do not get written to the SQL database.

If database size or volume of events are an issue, another approach organizations can utilize is the purge feature which would capture the events and then deleted them on a scheduled basis.  This would provide a configurable window of time to review events and if the database is backed up a potential to restore and examine the events if warranted. The purge feature will be covered in more detail another blog.

A common use of this feature is the ability to exclude changes made by a service account for an application such as an identity management solution.  Many of these solutions already track all their own activities and could also make a significant number of changes when syncing with Active Directory.  The policy is configured through the same wizard as the protection policy shown above by selecting the Configuration tab / Active Directory tile / Auditing Policies tile.

General Page

In the General page of the wizard provide an appropriate name and description for the policy.

Who Page

For the Who page, change the scope to Apply rules to the selected user accounts.  For this example, the IDM Service account is selected and set to include so that the rule only applies to events made by that service account.

What Page

For this particular use case on the What page check all the actions (Create, Modify, Remove, Move, Rename, Restore) as we want this audit exclusion to apply to all actions, object types and attributes that are being modified by the IDM service account.

Where Page

In the Where page we want the exclusion to apply to whole domain, so no configuration is required.

Actions Page

For the Actions page we want to turn the toggle off for Enabled auditing as we do not want events captured for the IDM service account.

Save the policy and it will take effect in around two minutes.

Once an audit policy has been completed it will appear on the Auditing Policies page.