Morgan Holm

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.


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.


Morgan Holm

Active Directory is dead, long live Active Directory

If you were to look at topics being covered at Microsoft’s conferences, announcements, or social media one could easily assume that Active Directory (AD) is dead.  It is correct that many organizations are embracing SaaS solutions and are going through digital transformations.  While all of this is true, we are still at the beginning of the process that will take a long time to get the majority of workloads and organizations to become cloud only.  You only need to look at mainframe usage and that Windows XP still comprises ~ 1.6% of PC operating systems to understand that organizations resist changes and computing paradigm shifts can take decades, and some things won’t change.

There is no question that the move to cloud is well underway and is accelerating.  This means that a hybrid and multi cloud systems are the reality for most and will be for some time with AD as the primary identity store.  Many organizations use AD Connect to sync their on-prem users to Azure Active Directory (AAD) for Office / Microsoft 365 (M365).  All of this means that you still need to keep track of what is happening in AD to make sure is stays secure.  Recent cyber attacks, namely the Solarwinds breach got bad actors into on-prem systems where they moved laterally, elevated permissions to eventually gained access to M365 resources.


Cygna Auditor has the flexibility to gather events with or without an agent from both trusted and untrusted forests while also allowing you to control where and how long the audit data is kept.  Monitoring AD changes alone will not be sufficient to maintain security and availability in a hybrid system.  You will also need to closely keep track of activities of your cloud connected systems.  Even though AD has been around for a long time, your auditing solution doesn’t need to be dated as well.  We are running a limited time campaign for you to Switch to Cygna Auditor.  Ask us to see what a modern hybrid auditing solution can do for your organization.

Morgan Holm

Cygna Auditor SIEM Event Forwarding

Cygna Auditor can now forward events to SIEM systems in a standard syslog format or in a structured view to Splunk. Cygna Auditor events are presented in plain language which greatly simplifies the understanding and consumption of the audit information.  This enables operational and security teams to work efficiently and make decisions and react quickly.

Structured View

The structured view for Splunk normalizes the audit data in the SIEM views by the Detail (expandable list of the modification), Item (object/attribute that was changed), Source (system or platform of modification), Success (if the action succeeded or failed), What (the object/attribute that was changed) When (timestamp), Where (the system where the change was applied), Who (account that made the change).

structured event

In the following example, the expandable Detail node provides the GPO setting that was modified with both the old and new values.

Native Windows Event in SIEM

The following is a native GPO change event imported into a SIEM from the Windows Event Logs.  There is a substantial amount of text to sift through to try to understand what has occurred.  Since the friendly name of the GPO is not shown you would either have to know the GUID or do a search to find out which GPO was modified.  This also does not show you what has changed.  You would need to have a previously exported GPO report prior to the change and manually compare the settings with the current version.  Needless to say, this would be a very time-consuming task.

Cygna Auditor provides SIEM systems a data translation layer service that converts non-human readable raw log data into plain language values as they occur.

Configure Splunk for Structured Cygna Events

To send Cygna structured events to Splunk you will need to configure an HTTP Event Collector.  For more information on this topic please select the following Splunk documentation link or see the following example configuration.

The first thing you need to ensure the HTTP event collector is enabled in Splunk UI through:

  1. Settings -> Data Inputs
  2. HTTP Event Collector
  3. Global Settings

Make sure it is enabled and make note of the port #.

The second step is to create an Event Collector token:

  1. Settings -> Add Data
  2. Monitor
  3. HTTP Event Collector

For the Source Type under Input Settings step, make sure you pick  Select and then in the Select Source Type dropdown pick Structured  _json

Once the configuration is saved you will see a token value that will be required to configure the connection to Splunk from the Cygna server.

Configure Cygna Server to Send Structured Events to Splunk

 Enable Remote Logging

From the Cygna Server UI:

  1. Configuration -> System
  2. Select Remote Logging tab in the System Configuration window
  3. Change the type drop down to Splunk
  4. Enter the URL for the Splunk HTTP Collector with port#
  5. Enter the Splunk HTTP Event Collector Token Value
  6. Ensure the message format is set to JSON
  7. Save the configuration

Configure Which Events to Forward

Once both Cygna and Splunk have been configured to be able to send and receive events you can decide what events you want to send.  This is done through alert remote logging on the Cygna server.

Enable Event Forwarding

Cygna events can be forwarded to SIEM systems through the alerting feature in Cygna reports.  The alerts events can be sent via email notification or through remote logging to SIEM systems or both.

From the Cygna Server UI:

  1. Reports
  2. Alert settings

(a) For existing reports, select its menu icon (hamburger) and then Alerts and enable the toggle

(b) When creating a new report under the Manage alert settings tab choose Remote Logging and enable the toggle

Once the alert is saved any event matching the filtering criteria will be sent to the SIEM system defined in the Cygna Remote Logging configuration.

Morgan Holm

Delegation in Cygna Auditor


The Cygna Labs platform allows you to view and combine audit information from across your hybrid multi-cloud systems in a single web console. Depending on your organization’s administration model, regulatory compliance, or policies, you may need to limit user access and actions. Delegation should limit users to perform specific activities on only the information they are allowed to work with that is necessary to perform their jobs.

The Cygna Labs platform has implemented a role-based access control (RBAC) delegation model to control access and permissions to the base platform and product modules. Roles are defined by combining only the necessary sets of permissions needed to perform common tasks in organizational job functions. Groups and or users are then assigned to the roles allowing them to perform these tasks. There is also the ability to define scope for groups and or users assigned to the role to create a boundary for data and actions. This approach minimizes the need to create additional duplicate roles or reports that only differ in scope. The role defines the permissions for its members to perform the designated actions. The scope set to the user or group when assigning them to the role that defines where, or on what data, they can perform them on. If no scope is set on the users or groups assigned to the roles, they will be able to perform those actions against the complete dataset that is configured for the Cygna product module. Scope assignments are hierarchical (when applicable) and are inherited by all child items. Built-in reports will have fixed role permissions set out of the box but will also allow list and execute permissions to be set directly.

Common Permission Sets

  • Full Control (all permissions)
  • List (read)
  • Create (write)
  • Execute (open)


Role Based Access Control (RBAC)

Each module has the following basic RBAC roles defined with its own actions, data types and scope boundaries.  The delegation model accommodates for additional built-in roles to be added in the future and for user defined roles.  Built-in roles are not end user customizable.  However, custom roles can be created by owners from scratch or built-in roles can be cloned to speed up and simplify the configuration process.

  • Owner of module – Allows you to manage everything, including access to resources
    • Permissions:
      • Full control for the module
    • Manages:
      • Access and scope
      • Module settings
      • Module data
  • Contributor – Allows you to perform most actions except for core module configuration and granting access / scope to resources
    • Permissions:
      • List
      • Create
      • Execute
    • Actions on:
      • Module specific data
      • Module specific tasks
  • Reader – Allows you to view everything, but not make any changes
    • Permissions:
      • List
      • Execute
    • Actions on:
      • Module specific data
      • Module specific tasks

Example Delegation Scenario

NA Auditors group is added to the Active Directory – Reader role with a scope defined to the North America OU.  EU Auditors group is added to the Active Directory – Reader role with a scope defined to EMEA OU.  User (A) is a member of the NA Auditors group.  They would be able to see the list of Active Directory reports.  If they run the All Active Directory Changes report they would see all AD changes but only for their scoped OU of North America.  User (B) is a member of the EU Auditors group.  They would be able to see the list of Active Directory reports.  If they run the All Active Directory Changes report they would see all AD changes but only for their scoped OU of EMEA.

Scenario Delegation Configuration

Delegation is available under the Configuration view. Select the Delegation tile to configure.


There are two tiles under Delegation, Roles and Role Assignment.



The Roles tile contains the built-in roles and allows you to add + a new role or select the hamburger icon  to the right of an existing role to clone it.



To add a user or group to a role, select the Role Assignment tile under Delegation.  Once open, select the desired role for assignment from the Select a role drop-down list of available roles.  For the example scenario, select the Active Directory – Reader role.



To select the role assignment target type, select the Assign access to drop down list.  For the example scenario select Group.


The role assignment configuration options should currently look like the following.



To configure a scope for the role assignment, select the Add/Remove scope tab on the top before saving the role assignment.  The appropriate data source for the role is shown.  For the example scenario expand the desired Active Directory domain and select the North America OU and click on the Add scope button.



Once the scope has been added, click the Save button to finish the role assignment.  For the example scenario the same process would be followed for the second role assignment except the group selected would be the EU Auditors and the OU selected would be EMEA.  Now users that are members of those groups will be limited to audit data for their respective scoped OUs for both ADHOC searches and built-in reports.


Arno Therburg

4 Active Directory Activities You Need to Keep a Closer Eye on

Are you faced with the constant pressure to ramp up security, making sure new compliance regulations are being met, making sure availability to the systems are continuously improved? And doing this on a tighter budget, with fewer resources?

Here are 4 Active Directory activities that you need to keep a closer eye on, Cygna Auditor for Active Directory will help you do this. Read more…