Chat now with support
Chat with Support

Change Auditor - For Advanced Users 7.0.1 - Technical Insight Guide

Change Auditor Services Change Auditor licensing processes Change Auditor network communications Coordinator internal tasks Coordinator Registry Settings Change Auditor built-in fault tolerance Change Auditor protection Database Considerations Account exclusions best practices

Change Auditor built-in fault tolerance

Fault tolerance and high availability is native to Change Auditor. It is inherently built in and no additional configuration is required.

Each component in the Change Auditor architecture is designed with high availability (fault tolerance and failover) as a goal. There will always be only one SQL database and this database is typically hosted on a Microsoft SQL Server cluster.

More than one management service (coordinator) can be installed and they automatically work together and become redundant. No additional configuration is required. An agent can connect to multiple coordinators to process events and prepare them for Change Auditor 6.x agents prefer available coordinators within the same site, but if none are found, all available coordinators within the same installation are considered. If one or more (depending on agent type) non-site coordinators are connected, and one or more coordinators are later discovered within the agent site, the agents connect to the site-located coordinators and drop non-site coordinator connections. If this behavior is problematic for your environment, contact Quest Technical Support to discuss possible configuration options.or insertion into the SQL database. The need for multiple coordinators depend on the event volume, number of agents, and the hardware specifications of the coordinator. If one of these servers suffers a catastrophic failure, the other continues.

Also, the auditing agent has the inherent ability to cope with service or network outages. If for any reason an agent is unable to communicate with the other components, that agent continues auditing normally and stores audit data locally until communications are restored. This outage can exist for an extended period without issue. After communications resume, the agent begins forwarding its queued events in a controlled fashion.

If a coordinator is unavailable, agents stop forwarding events. This is by design. For redundancy, or if a coordinator is not able to handle the event load, two or more coordinators can be installed. Server agents submit events to all available coordinators and load balancing occurs automatically. However, workstation agents randomly connect to a single coordinator and submit events to that coordinator.

* 
NOTE: Change Auditor 6.x agents prefer available coordinators within the same site, but if none are found, all available coordinators within the same installation are considered. If one or more (depending on agent type) non-site coordinators are connected, and one or more coordinators are later discovered within the agent site, the agents connect to the site-located coordinators and drop non-site coordinator connections. If this behavior is problematic for your environment, contact Quest Technical Support to discuss possible configuration options.

Change Auditor protection

Change Auditor protection
Using multiple protection templates

This section explains how access permissions are evaluated when multiple protection templates are assigned to an object which may contain conflicting rules. The evaluation process used is for all types of protection templates (Active Directory, ADAM (AD LDS), Group Policy, File System, and Exchange Mailbox). However, there are some special considerations to keep in mind when using the Exchange Mailbox Protection feature, see How access rules are evaluated.

Protection templates can be one of two types:

•
Classic (allow) templates which deny access by default, allowing access to the protected object by the override accounts explicitly specified in the protection template.
•
Reverse (deny) templates which allow access by default, denying access to the protected object by the override accounts explicitly specified in the protection template.

Using multiple protection templates

Change Auditor protection

This section explains how access permissions are evaluated when multiple protection templates are assigned to an object which may contain conflicting rules. The evaluation process used is for all types of protection templates (Active Directory, ADAM (AD LDS), Group Policy, File System, and Exchange Mailbox). However, there are some special considerations to keep in mind when using the Exchange Mailbox Protection feature, see How access rules are evaluated.

Protection templates can be one of two types:

•
Classic (allow) templates which deny access by default, allowing access to the protected object by the override accounts explicitly specified in the protection template.
•
Reverse (deny) templates which allow access by default, denying access to the protected object by the override accounts explicitly specified in the protection template.

How access rules are evaluated

When a user attempts to access a protected object, each template is evaluated separately, and the ‘deny’ access rule takes precedence over any ‘allow’ access rule. This means, that if at least one protection template evaluates to ‘deny’, attempts to access the protected object is denied. The following table illustrates the overall results of conflicting access rules:

Table 19. How access rules are evaluated
Based on Settings in Template 1:
Based on Settings in Template 2:
Overall Result

User is allowed access

User is allowed access

User is allowed to access protected objects

User is allowed access

User is denied access

User is denied access to protected objects

User is denied access

User is allowed access

User is denied access to protected objects

User is denied access

User is denied access

User is denied access to protected objects

For Exchange Mailbox Protection templates, you can set the Mailbox owner can bypass protection option to allow the object’s owner to access his or her own mailbox, even if the protection template would normally deny access.

This override flag only affects the evaluation on a template where it is defined. It does not affect the evaluation of other protection templates.

* 
IMPORTANT: Care should be taken when defining multiple Exchange Mailbox Protection templates. For example, even though you cannot create a duplicate Exchange Mailbox protection template for the same object name, you could be including the same mailbox in multiple templates. That is, if you define templates for the Enterprise object, the top-level domain object, an OU container and several groups, this same mailbox could be a child or member of all these objects. The access to this mailbox is evaluated for each of the templates to which it belongs.
* 
NOTE: Exchange Mailbox protection is designed to provide protection coverage for a few high-value mailboxes. After monitoring has been enabled or changed, it may take several minutes to complete the configuration process necessary to enable the protection feature on the agent. Protecting a large number of mailboxes slows down the configuration process.
* 
NOTE: To control memory utilization, each Exchange Mailbox Protection template can have up to 20 users selected as ‘override accounts’ that can bypass the protection feature. This number applies to both allowed and denied user accounts and includes members of groups in the list.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating