Chatee ahora con Soporte
Chat con el soporte

Change Auditor 7.1.1 - Installation Guide

Installation Overview Install Change Auditor Add Users to Change Auditor Security Groups Connecting to the Clients Deploy Change Auditor Agents Upgrade Change Auditor Installation Notes and Best Practices Multi-Forest Deployments Foreign Forest Agent Deployment Workstation Agent Deployment Agent Comparison Install an agent to audit ADAM (AD LDS) on workgroup servers Active Roles Integration Quest GPOADmin Integration Windows Installer Command Line Options

Multi-forest deployment requirements

Multi-forest deployment requirements
Network connectivity between each monitored forest

Coordinators in all forests connect directly to the SQL Server that is hosting the Change Auditor audit database.

Coordinators must resolve the host name of the SQL server or must be configured to use the IP address of the SQL server.

At least one coordinator must be deployed in each forest

The coordinator is responsible for collecting and maintaining the topology information for each forest. This includes domains, sites, domain controllers, and member servers.

The coordinator is also responsible for many other periodic tasks such as:

•
Sending alerts by email, SMNP, or WMI
•
Sending agent configuration settings, auditing and protection templates
•
License enforcement
•
Agent status updates
•
Agent installation and upgrade
•
Auto deployment
•
Event statistics
•
Group membership expansion
Change Auditor groups are created in each forest

To connect to coordinators in other forests, users must be added to either the ‘ChangeAuditor Administrators — <InstallationName>’ OR ‘ChangeAuditor Operators — <InstallationName>’ in the forest where the coordinator is joined.

Credentials for the Microsoft SQL Server backend

Depending on whether the Active Directory forests have a trust in place, you need to configure Change Auditor to use the appropriate SQL credentials.

Scenario A — One or more of the forests do not have a valid trust in place

The coordinator that is not part of the same forest where the SQL server is joined to, must be configured to use a SQL user account or a Domain Account from the forest where the SQL server resides.

Scenario B — All forests have a valid trust in place

Each of the coordinators may be configured to use either authentication type. Both Windows or SQL user accounts may be used in each of the forests.

Installation example

The following diagram shows two separate forests where Change Auditor will be deployed. Forest A is deployed first and the Forest B is added.

Forest A installation
1
Install the coordinator on a member server in Forest A. In this example, Coordinator1.ForestA.com is used as the coordinator server.
•
While installing the first coordinator, make note of the “Installation name”. The same installation name is used to deploy the coordinator in Forest B (ForestB.net).
•
Also take note of the SQL Server host and credential information. This server and account will also be used in the second forest. The required information is as follows:
•
SQL Server host name or IP address AND Instance name if applicable
•
Database or Catalog name
•
User name, password, and domain if applicable
2
Install the client on either a workstation or member server. In this example, CAClient1.ForestA.com is used as the client computer.
3
Using the client, connect to the coordinator in Forest A to deploy Change Auditor agents on to the domain controllers and/or member servers in Forest A. See Deploy Change Auditor Agents for more details about deploying agents.
4
At this point, Change Auditor should be fully deployed to the first forest in the organization (ForestA.com in this example).
Forest B installation
5
Install the coordinator on a member server in Forest B. In this example, Coordinator2.ForestB.net is used as the coordinator server.
•
While installing the second coordinator, you must use the ‘Installation name’ that was selected in the first forest.
•
During the installation of the second coordinator, use the same SQL server and database name used in the first coordinator’s installation. The Windows or SQL user account may be different than the account used in the first installation.
•
Quest recommends that the same database access account used in the first forest is also used in the second forest. If a different user account for database access is used in the second coordinator's installation, the following permissions must be granted before the installation is started:
•
db_owner database role on the Change Auditor database
•
dbcreator server role
6
Install the client on either a workstation or member server. In this example, CAClient2.ForestB.net is used as the client computer.
7
Using any client, connect to the coordinator in Forest B to deploy agents on to the domain controllers and/or member servers in Forest B.
8
Change Auditor is now fully configured to collect audit data from both forests into a single database. Reports and alerts can be run from any client to return data related to one or all the deployed forests.
9
You can deploy more forests by following steps 5 through 9.

Configuration

This section discusses how Change Auditor configurations are handled in multi-forest environments, including:

•
Audit and protection configuration flow
•
Event flow
•
Reports and queries from the client

Audit and protection configuration flow

Audit and protection configurations are maintained using the client that is installed on either workstations or member servers. Configuration changes are stored in the SQL database by the coordinator service.

The following configurations can be shared across forests regardless of the forest trust level:

•
Active Directory Auditing — Object Class\Attributes
•
ADAM\AD (LDS) Auditing — Object Class\Attributes
•
Excluded Accounts templates
•
File System Auditing templates
•
Registry Auditing templates
•
Service Auditing templates
•
VMware Auditing templates
•
SQL Auditing templates
•
Audit Event configurations (for example, enabled or disabled, severity level)

The following configurations can be shared when a two-way trust exists:

•
Active Directory Protection templates
•
ADAM\AD (LDS) Protection templates
•
Exchange Protection templates
•
File System Protection templates
•
Group Policy Protection templates
* 
NOTE: A trust is required to view the Active Directory accounts in the other forest for protection account exclusions.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación