Managing Auditing for an Installation

This chapter describes how to secure and manage the audit and monitoring service infrastructure after the initial deployment of IBM Security software on Windows computers. It includes tasks that are done by users assigned the Master Auditor role for an installation and users who are Microsoft SQL Server database administrators.

Securing an Installation

For production deployments, you can take the following steps to secure an audit and monitoring service installation:

Use the Installation group policy to specify which installation agents and collectors are part of. By enabling the Installation group policy you can prevent local administrators from configuring a computer to be part of an unauthorized installation.
Configure a trusted group of collectors to prevent a hacker from creating a rogue collector to collect data from agents.
Configure a trusted group of agents to prevent a hacker from performing a Denial of Service attack on the collector and database by flooding a collector with false audit data.
Encrypt all data sent from the collector to the database.

Before you can follow these steps to secure an installation, you must have access to an Active Directory user account with permission to create Active Directory security groups, enable group policies, and edit Group Policy Objects.

To secure an installation using Windows group policy:

Open the Group Policy Management console.
Expand the forest and domain to select the Default Domain Policy object.
Right-click, then click Edit to open Group Policy Management Editor.
Expand Computer Configuration > Policies > CentrifyDirectAudit Settings, then select Common Settings.
Double-click the Installation policy in the right pane.
On the Policy tab, select Enabled.
Click Browse to select the installation you want to secure, then click

OK.
Click OK to close the Installation properties.

Securing an Audit Store with Trusted Collectors and Agents

By default, audit stores are configured to trust all audited computers and collectors in the installation. Trusting all computers by default makes it easier to deploy and test audit and monitoring service in an evaluation or demonstration environment. For a production environment, however, you should secure the audit store by explicitly defining the computers the audit store can trust.

You can define two lists of trusted computers:

Audited computers that can be trusted.
Collector computers that can be trusted.

To secure an audit store:

Open the Audit Manager console.
Expand the installation and Audit Stores nodes.
Select the audit store you want to secure, right-click, then select Properties.
Click the Advanced tab.
Select Define trusted Collector list, then click Add.
Select a domain, click OK, then search for and select the collectors to trust and click OK to add the selected computers to the list.

Only the collectors you add to the trusted list are allowed to connect to the audit store database. All other collectors are considered untrusted and cannot write to the audit store database.
Select Define trusted Audited System list, then click Add.
Select a domain, click OK, then search for and select the audited computers to trust and click OK to add the selected computers to the list.

Only the audited computers you add to the trusted list are allowed to connect to the trusted collectors. All other computers are considered untrusted and cannot send audit data to trusted collectors.
Click OK to close the audit store properties dialog box.

The following example illustrates the configuration of trusted collectors and trusted audited computers.

In this example, the audit store trusts the computers represented by P, Q, and R. Those are the only computers that have been identified as trusted collectors in the audit store Properties list. The audit store has been configured to trust the audited computers represented by D, E, and F. As a result of this configuration:

Audited computers D, E, and F only send audit data to the trusted collectors

P, Q, and R.
Trusted collectors P, Q, and R only accept audit data from the trusted

audited computers D, E, and F.
The audit store database only accepts data for its trusted collectors P, Q,

and R, and therefore only stores audit data that originated on the trusted

audited computers D, E, and F.

Disabling a trusted list

After you have added trusted collectors and audited computers to these lists, you can disable either one or both lists at any time to remove the security restrictions. For example, if you decide to allow audit and monitoring service data from all audited computers, you can open the audit store properties, click the Advanced tab, and deselect the Define trusted Audited System list option. You don’t have to remove any computers from the list. The audit store continues to only accept data from trusted collectors.

Using security groups to define trusted computers

You can use Active Directory security groups to manage trusted computer accounts. For example, if you create a group for trusted audited computers and a group for trusted collectors, you can use those groups to define the list of trusted collectors and audited computers for the audit store. Any time you add a new computer to one of those groups, thereafter, it is automatically trusted, without requiring any update to the audit store properties.

Securing Network Traffic with Encryption

The last step in securing an installation is to secure the data collected and stored through encryption. The following summarizes how data is secured as it moves from component to component:

Between an audited computer and the spooler that stores the data locally

when no collectors are available, audit data is not encrypted. Only the

local Administrator account can access the data by default.
Between the audited computer’s data collection service (wdad) and the

collector, data is secured using Generic Security Services Application

Program Interface (GSSAPI) with Kerberos encryption.
Between the collector and the audit store database, data can be secured

using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or AES

(Windows 2008) encryption if the database is configured to use SSL

connections.
Between the audit store and management databases, data can be secured using

Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or AES

(Windows 2008) encryption if the database is configured to use SSL

connections.
Between the management database and the Audit Manager console, data can be

secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003)

or AES (Windows 2008) encryption if the database is configured to use SSL

connections.

The following illustration summarizes the flow of data and how network traffic is secured from one component to the next.

Enabling Secure Socket Layer (SSL) communication

Although the database connections can be secured using SSL, you must configure SSL support for Microsoft SQL Server as part of SQL Server administration. You must also have valid certificates installed on clients and the database server. If you are not the database administrator, you should contact the database administrator to determine whether encryption has been enabled and appropriate certificates have been installed. For more information about enabling SSL encryption for SQL Server and installing the required certificates, see the following Microsoft support article:

http://support.microsoft.com/kb/316898

Enabling encryption for Microsoft SQL Server Express

If you use Microsoft SQL Server Express, encryption is turned off by default. To secure the data transferred to the database server, you should turn encryption on.

To enable encryption for each audit store and management database:

Log on to the computer hosting an audit store or management database with an

account that has database administrator authority.
Open SQL Server Configuration Manager.
Select the SQL Server Network Configuration node, right-click Protocols forDBINSTANCE, then select Properties.
On the Flags tab, select Yes for the Force Encryption option,

then click OK to save the setting.

Using a service account for Microsoft SQL Server

When you install Microsoft SQL Server, you specify whether to use Windows authentication or a mix of Windows and SQL Server authentication. You also specify the accounts that the database services should use. By default, system accounts are used. If SQL Server uses a domain user account instead of a system account, you should ensure that the account has permission to update the SQL Server computer object in Active Directory. If the account has permission to update the computer where SQL Server is running, SQL Server can publish its service principal name (SPN) automatically. Getting the correct service principal name is important because Windows authentication relies on the SPN to find services and DirectManage Audit uses Windows authentication for console-to-audit management database connections. If the SPN is not found, the connection between the console and audit management database fails.

The audit management database-to-audit store connection and the collector-to-audit store connection can use either Windows authentication or SQL Server authentication. If SQL Server authentication is used, it does not matter whether the SQL Server instance uses a system account or a service account. If you have configured SQL Server to use Windows authentication only, be sure that the Windows account is allowed to connect to the audit management database and to the audit store database.

Setting Administrative Permissions

When you create a new installation, you become the primary administrator for that installation. As the primary administrator and Master Auditor, you have full control over the entire installation and the ability to delegate administrative tasks to any other Active Directory user or group. When you grant administrative rights to designated users and groups, you make them “trustees” with permission to perform specific operations. You can set granular permissions to tightly control what specific users can do or grant broad authority over operations in an installation.

If you have a large or widely-distributed installation, you can also install additional Audit Manager and Audit Analyzer consoles for the users who have been delegated administrative tasks to use.

To delegate administrative tasks to other users:

Open Audit Manager.
Select the installation name, right-click, then click Properties.
Click the Security tab to delegate administrative tasks for the entire installation.
Click Add to add Active Directory users or groups to the list of trustees who granted any type of rights on this installation.
Select a user or group listed, then select the appropriate rights for that trustee, then click OK.

The following table lists the rights available.

Select this permission	To grant these rights to a trustee
Full Control	All operations on the selected installation.
Change Permissions	Add or remove users and groups as trustees for the installation. Modify permissions for trustees on the selected installation.
Modify Name	Modify display name for the selected installation.
Manage Management Database List	Add or remove management databases for the selected installation.
Manage Audit Store List	Add or remove audit stores for the selected installation.
Manage Collectors	Enable a trusted group of collectors for this audit store. Add a collector to the trusted group of collector in this audit store. Remove collector from the trusted collectors in this audit store. Remove disconnected collector records from this audit store.
Manage Audited Systems	Enable trusted group of audited computers for this audit store. Add a computer to the trusted group of audited computers in this audit store. Remove a computer from the trusted group of audited computers in this audit store. Remove disconnected audited computer records from this audit store.
Manage Audit Role	Add, modify, or remove audit roles in the selected installation. Assign users and groups to audit roles. Remove users and groups from roles.
Manage Queries	Add, modify, or remove queries in the selected installation.
Manage Publications	Add or remove publication locations for the selected installation.
Manage Licenses	Add or remove license keys for the selected installation.
Modify Notification	Enable or disable audit notification in the selected installation. Select the notification message. Select a banner image.
Modify Audit Options	Enable or disable the option to capture video of all user activity on audited computers. Control whether users are allowed to update the review status of their own sessions. Control whether users are allowed to delete their own sessions.
View	Enable to view audited computers and sessions.

Click OK to complete the delegation of administrative rights for the

selected installation.

You can also delegate administrative tasks for individual audit stores and management databases, and set permissions on audit roles. For information about delegating administrative tasks for audit stores, see Configuring permissions for an audit store. For information about delegating administrative tasks for management databases, see Configuring permissions for the management database.

For information about setting permissions on audit roles, see Managing audit roles and auditors.

Managing Audit Stores

An audit store defines a set of Active Directory sites or subnets and a collection of databases that contain audit data. Typically, an installation has one audit store with multiple databases. However, you can add audit stores if you are auditing computers in a large and widely distributed network or have multiple Active Directory sites with computers you want to audit.

Configuring the Scope of an Audit Store

In most organizations, a single audit store is used to map to an Active Directory site. However, there are situations where you might want to define the scope of an audit store based on subnets. For example:

If you have a subnet that Active Directory considers part of a site that is connected over a slow link you might want to configure a separate audit store and collectors that service audited computers in the remote subnet.
If you have very large Active Directory site, you might require multiple audit stores for load distribution. You can accomplish this by partitioning an Active Directory site into multiple audit stores based on subnets. Each subnet has its own audit store, set of collectors, and audited computers.

You can configure the scope of an audit store by adding or removing Active Directory sites or subnets.

To configure the scope for an audit store:

Open Audit Manager.
Expand the installation node, then expand Audit Stores and select a specific audit store name.
Right-click, then select Properties.
Click the Scope tab.
Click Add Site to select an Active Directory site from the list of sites found or click Add Subnet to type a specific subnet address and mask.

Configuring Permissions for an Audit Store

If you are the Master Auditor or have Change Permission rights, you can modify the rights granted to Active Directory users or groups. When you enable rights for designated users and groups, you make them “trustees” with permission to perform specific operations.

To configure permissions for managing the audit store:

Open Audit Manager.
Expand the installation node, then expand Audit Stores and select a specific audit store name.
Right-click, then select Properties.
Click the Security tab.
Click Add to add Active Directory users or groups to the list of trustees who granted any type of rights on this audit store.
Select a user or group listed, then select the appropriate rights for that trustee, then click OK.

The following table lists the rights available.

Select this permission	To grant these rights to a trustee
Full Control	All operations on the audit store.
Change Permissions	Modify permissions on this audit store.
Modify Name	Modify display name for this audit store.
Manage Scopes	Add a subnet or Active Directory site to the audit store. Remove a subnet or Active Directory site from the audit store.
Manage SQL Logins	Set the allowed incoming collectors for this audit store’s databases. Set the allowed incoming management databases for this audit store’s databases.
Manage Collectors	Enable a trusted group of collectors for this audit store. Add a collector to the trusted group of collector in this audit store. Remove collector from the trusted collectors in this audit store. Remove disconnected collector records from this audit store.
Manage Audited Systems	Enable trusted group of audited computers for this audit store. Add a computer to the trusted group of audited computers in this audit store. Remove a computer from the trusted group of audited computers in this audit store. Remove disconnected audited computer records from this audit store.
Manage Databases	Add audit store databases to this audit store. Attach audit store databases to this audit store. Detach an audit store database from this audit store. Change the active database in this audit store. Modify the display name of an audit store database.
Manage Database Trace	Enable or disable database trace. Export database trace.

Managing Audit Store Databases

During the initial deployment, your installation only has one audit store database. As you begin collecting audit data, however, that database can quickly increase in size and degrade performance. Over time, an installation typically requires several Microsoft SQL Server databases to store the data being captured and historical records of session activity, login and role change events, and other information. As part of managing an installation, you must manage these databases to prevent overloading any one database and to avoid corrupting or losing data that you want to keep.

One of the biggest challenges in preparing and managing Microsoft SQL Server databases for storing audit data is that it is difficult to estimate the level of activity and how much data will need to be stored. There are several factors to consider that affect how you configure Microsoft SQL Server databases for auditing data, including the recovery method, memory allocation, and your backup and archiving policies.

For more complete information about managing and configuring SQL Server, however, you should refer to your Microsoft SQL Server documentation.

Selecting a Recovery Model

Standard backup and restore procedures come in three recovery models:

Simple—The simple recovery model allows high-performance bulk copy operations, minimizes the disk space required, and requires the least administration. The simple recovery model does not provide transaction log backups, so you can only recover data to the point of the most recent full or differential backup. The default recovery model is simple, but is not appropriate in cases where the loss of recent changes is not acceptable.
Full—The full recovery model has no work-loss exposure, limits log loss to changes since the most recent log backup, and provides recovery to an arbitrary time point. However, the full recovery model uses much more disk space.
Bulk-logged—The bulk-logged recovery model provides higher performance and minimizes the log space used by disk-intensive operations, such as create index or bulk copy. With the bulk-logged recovery model, you can only recover data to the point of the most recent full or differential backup.

However, because most databases undergo periods of bulk loading or index creation, you can switch between bulk-logged and full recovery models to minimize the disk space used to log bulk operations.

When a database is created, it has the same recovery model as the model database. Although the simple recovery model is the default, the full and bulk-logged recovery models provide the greatest protection for data, and the full recovery model provides the most flexibility for recovering databases to an earlier point in time. To change the recovery model for a database, use the ALTER DATABASE statement with a RECOVERY clause.

Regardless of the recovery model you choose, you should keep in mind that backup, restore, and archive operations involve heavy disk I/O activity. You should schedule these operations to take place in off-peak hours. If you use the simple recovery model, you should set the backup schedule long enough to prevent backup operations from affecting production work, but short enough to prevent the loss of significant amounts of data.

Configuring the Maximum Memory for Audit Store Databases

Because Microsoft SQL Server uses physical memory to hold database information for fast query results, you should use a dedicated instance to store auditing data. Because SQL Server dynamically acquires memory whenever it needs it until it reaches the maximum server memory you have configured, you should set constraints on how much physical memory it should be allowed to consume.

The maximum server memory (max server memory) setting controls the maximum amount of physical memory that can be consumed by the Microsoft SQL Server buffer pool. The default value for this setting is such a high number that the default maximum server memory is virtually unlimited. Because of this default value, SQL Server will try to consume as much memory as possible to improve query performance by caching data in memory.

Processes that run outside SQL Server, such as operating system processes, thread stacks, socket connections and Common Language Runtime (CLR) stored procedures are not allowed to use the memory allocated to the Microsoft SQL Server buffer pool. Because those other processes can only use the remaining available memory, they might not have enough physical memory to perform their operations. In most casts, the lack of physical memory forces the operating system to read and write to disk frequently and reduces overall performance.

To prevent Microsoft SQL Server from consuming too much memory, you can use the following formula to determine the recommended maximum server memory:

Reserve 4GB from the first 16GB of RAM and then 1GB from each additional 8GB of RAM for the operating system and other applications.
Configure the remaining memory as the maximum server memory allocated for the Microsoft SQL Server buffer pool.

For example, if the computer hosting the Microsoft SQL Server instance has 32GB of total physical memory, you would reserve 4 GB (from first 16 GB) + 1GB (from next 8 GB) + 1 GB (from next 8 GB) for the operating system, then set the Maximum server memory for Microsoft SQL server to 26 GB (32 GB – 4 GB – 1 GB – 1 GB = 26).

For more information about how to configure Microsoft SQL Server maximum memory setting and other memory options, see the following Microsoft article: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms178067(v=sql.105)

You should configure the maximum memory allowed for the Microsoft SQL Server instances hosting audit store databases and the management database. However, this setting is especially important to configure on the Microsoft SQL Server instance hosting the active audit store database.

Using Transact-SQL to Configure Minimum and Maximum Memory

You can control the minimum and maximum memory that the SQL Server buffer manager uses by issuing Transact-SQL commands. For example:

sp_configure ‘show advanced options’, 1
reconfigure
go
sp_configure ‘min server memory’, 60
reconfigure
go
sp_configure ‘max server memory’, 100
reconfigure
go

For more information about configuring SQL Server and setting minimum and maximum server memory using T-SQL, see https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-2017

Estimating Database Requirements Based on the Data you Collect

To determine how audit and monitoring service will affect database capacity, you should monitor a pilot deployment of 20 to 25 agents with representative activity to see how much data is produced daily. For example, some audited computers might have few interactive user sessions or only short periods of activity. Other audited computers might have many interactive user sessions or long sessions of activity on average.

During the pilot deployment, you want to the following information:

How many interactive user sessions occur daily on each computer?
How long do sessions last on average?
What are the activities being captured, and what is the average size of each session being captured?
How long do you need to store the captured data to balance performance and storage?
What is the data retention period for audited data?

From the information you collect in the pilot deployment and the data retention policy for your organization, you can estimate the database size using the following guideline:

alt

For example, if an average session generated 100 KB in the database and the installation had 250 agents, 10 sessions per agent, and a six-month retention period (about 130 working days), the storage requirement for the audit store database would be 36.9 GB:

250 agents x 10 sessions/agent each day x 100 KB/session x 130 days = 32,500,000 KB

The following table shows examples of the data storage requirement in an installation with Windows agents, typical levels of activity with an average of one session per day on each audited computer, and the recovery mode set to Simple:

Agents	Average session length	Average session size	Daily	Weekly	6 Months
100	20 minutes	806 KB - low activity	79 MB	394 MB	10 GB
50	25 minutes	11.56 MB - high activity	578 MB	2.81 GB	73.36 GB
100	20 minutes	9.05 MB - high activity	905 MB	4.42 GB	115 GB

In this example, an installation with 100 Windows agents with low activity would require approximately 10 GB for the audit store database to keep audit data for 6 months. An increase in the number of interactive sessions, session length, or average session size would increase the database storage required.

If SQL Server requires more space to accommodate the new data, it expands the database file immediately, which can cause degraded performance. To reduce the effect of database expansion on performance, allocate sufficient space to support database growth. In addition, monitor database space and when space is low, schedule a database expand operation for an off-peak time.

Adding New Audit Store Databases to an Installation

When you first set up an installation, you also create the first audit store and audit store database. By default, that first database is the active database. As you begin collecting audit data, you might want to add databases to the audit store to support a rolling data retention policy and to prevent any one database from becoming a bottleneck and degrading performance.

Only one database can be the active database in an audit store at any given time. The computer hosting the active database should be optimized for read/write performance. As you add databases, you can change the older database from active to attached. Attached databases are only used for querying stored information and can use lower cost storage options.

{b}Note: {/b}A single instance of Microsoft SQL Server can host multiple databases.

Audit store databases have the following characteristics:

A database can be active, attached, or detached.
Only one database can be actively receiving audit data from collectors.
A database cannot be detached while it is the active database.
A database that was previously the active database cannot again be the

active database.
If a detached database contains parts of sessions presented to the Audit Analyzer, a warning is displayed when the auditor replays those sessions.

Rotating the Active Database

Database rotation is a management policy to help you control the size of the audit store database and the performance of database operations. There are several reasons to do database rotation:

It is more difficult to manage one large database than multiple small databases.
Performance is better with multiple small databases.
Backing up, restoring, archiving, and deleting data all take significantly more time if you work with one large database.
Database operations take very little time when you work with multiple small databases.

For audit and monitoring service, you can implement a database rotation policy by having the collector write data to a new database after a certain period of time. For example, the collector in site A writes data to the database siteA-2014-11 in November, then write data to database siteA-2014-12 in December and to the database siteA-2015-01 in January. By rotating from one active database to another, each database stays more compact and manageable.

Creating a New Database for Rotation

You can rotate from one active database to another at any time using the Audit Manager console.

To create a new database for rotation:

Open Audit Manager.
Expand the installation node, then expand Audit Stores and a specific audit store name.
Select Databases, right-click, then select Add Audit Store Database to create a new database.
Select the Set as Active database option so collectors start writing to the newly created database.

It is possible to write a script to automate the database rotation process. For details, see the SDK documentation.

Database Archiving

To implement periodic archiving, add a new active database, leave one or more previous databases attached, and take the oldest database off-line for archiving.

Queries During Rotation and Archiving

If the database backup program supports online backup, the Audit Analyzer can still query the database while the backup is in progress. However, the backup program may block updates to the session review status. If the backup program does not support online backup, the database will be offline until the backup is complete.

Database Backups

You can back up a database whether it is attached to the audit store or detached from the audit store.

Allowed Incoming Accounts

You can specify the accounts that are allowed to access the audit store database. By configuring these accounts, you can control which collector computers can connect to the audit store database and which management databases have access to the data stored in the audit store database.

Your account must have Manage SQL Login permission to configure the incoming accounts.

To configure allowed accounts:

Open Audit Manager.
Expand the installation node, then expand Audit Stores and select a specific audit store name.
Select a database under the audit store, right-click, then select Properties.
Click the Advanced tab.
Click Add to add a collector or management database account.
Select an authentication type.
- If you select Windows authentication, you can browse to select a computer, user, or group to add.
- If you select SQL Server authentication, you can select an existing SQL Server login or create a new login.

Connections should use Windows authentication whenever possible. However, computers in an untrusted forest cannot connect to an audit management database using Windows authentication. To allow connections from an untrusted forest, add a SQL Server login account as the incoming account for the management database.

Managing the Management Database

The audit management database keeps track of where components are installed and information about the installation. To connect to the database or manage its properties, select a specific installation name in Audit Manager, right-click, then select Management Databases.

Configuring the Scope of the Management Database

The audit management database stores information about the set of Active Directory sites or subnets it supports. You can modify the scope of the management database if you are auditing computers in a large and widely distributed network or have multiple Active Directory sites with computers you want to audit.

To configure the scope for a management database:

Open Audit Manager.
Select the installation name, right-click, then select Management Database.
Click Properties, then click the Scope tab.
Click Add Site to select an Active Directory site from the list of sites found or click Add Subnet to type a specific subnet address and mask.

The Windows components for DirectAudit now support IPv6. The Add Subnet dialog for subnet-based scopes requires both IPv4 and IPv6 subnets in CIDR format (e.g., 192.168.16.0/24 or fe80::1234::/64). This approach simplifies the UI and accommodates IPv6, which lacks old-style subnet masks. A tooltip displays the required format when hovering over the input field.

Configuring Permissions for the Management Database

To configure audit store security:

Open Audit Manager.
Select the installation name, right-click, then select Management Database.
Click Properties.
Click the Security tab.
Click Add to add Active Directory users or groups to the list of trustees who granted any type of rights on this management database.
Select a user or group listed, then select the appropriate rights for that trustee, then click OK.

The following table lists the rights available.

Select this permission	To grant these rights to a trustee
Full Control	All operations on the management database.
Change Permissions	Modify permissions on the management database.
Modify Name	Modify display name for this management database.
Manage Scopes	Add a subnet or Active Directory site to the management database. Remove a subnet or Active Directory site from the management database.
Manage SQL Logins	Set the allowed incoming accounts for the management database. Database owner is by definition an allowed user. Set the outgoing account for the management database.
Remove Database	Remove this audit management database from the installation.
Manage Database Trace	Enable or disable database trace. Export database trace.

Managing Collectors

You can view information about the collectors you have deployed in the Audit Manager console. For example, for each collector, you can see the location of the collector on the network, whether the collector is connected to or disconnected from the audit store, and how long a connected collector has been running since it was last restarted, the audit store to which the collector is assigned, and the active database to which the collector is currently sending audit data. You can also see the audited computers that currently connected to each collector and the audited computers that are not currently connected to this collector.

If you install the collector service on a computer but it has never connected to any agents or audit stores, it is not included in collector list on the Audit Manager console.

Monitoring Collector Status Locally

In addition to the information available in the Audit Manager console, the Windows computers on which you have installed a collector provide a local Collector Control Panel applet. The Collector Control Panel displays information about current connectivity and status for the local collector. You can use the control panel to configure the collector port number, installation, and authentication type if you want to make changes after the initial deployment. You can also use the control panel to start, stop, or restart the collector service, and to generate diagnostic information about the collector.

Log on to the computer on which you have installed a collector.
In the list of applications on the Windows Start menu, click Audit Collector Control Panel to open the audit collector control panel.
On the General tab, click Configure to change the port number, installation, or type of authentication to use when connecting to the audit store.

The General tab also displays current configuration and status for the local collector service. If you make changes, the new information is displayed after a short period of time.
Click Stop if you want to temporarily stop a running service, or Restart if you want to stop and immediately restart a running collector service.
Click the Troubleshooting tab, then click Diagnostics to generate diagnostic information about the installation the collector is part of, theActive Directory site or subnets associated with the audit store the collector connects to, the collector status, and other information. For example:

After you generate diagnostic information, you can right-click to select all of the text. With the text selected, right-click, and select Copy to copy and paste the diagnostic report into a text file.
Click Options to specify the level of detail to include in the log file or to turn off logging.

The default log level reports informational messages, warnings, and errors. You can click View Log to see information in the current log file.
Click Close to return to the agent configuration panel.

Removing Collectors

If you want to remove a collector, you can use the Programs and Features > Uninstall a program control panel or the setup program you used to install the collector.

If you run the setup program, select the collector from the list of components, then click Next. Because a collector is installed, the wizard prompts you the Change, Repair or Remove the collector. Click Remove.

Managing Audited Computers and Agents

You can see information about audited computers and the audit and monitoring service status of Agents for Windows using the Audit Manager console. For example, for each audited computer, you can see the computer name and IP address, whether the audited agent is currently connected or disconnected, and how long the agent has been running since it was last restarted. You can also see the collector to which the agent is sending data and the audit store and audit store database where the audit data is stored.

Monitoring Agent Status Locally

In addition to the information available in the Audit Manager console, the Windows computers on which you have installed a Agent for Windows with audit and monitoring service enabled include a local agent configuration panel applet. The agent configuration panel displays information about current connectivity and status for the local agent. You can use the agent configuration panel to configure the color depth, offline storage, or installation if you want to make changes after the initial deployment. You can also use the agent configuration panel to generate diagnostic information about the agent.

To use the agent configuration panel:

Log on to the computer on which you have installed a Agent for Windows with audit and monitoring service enabled.
In the list of applications on the Windows Start menu, click Agent Configuration to open the agent configuration panel.
Click Auditing and Monitoring Service.
Click Settings.
On the General tab, click Configure to change the color depth, offline storage file location and maximum size, and the installation to use for the local agent.

Note:The offline storage location should be an empty folder. If you select a folder that contains any files other than the spooled audit data, those files may be moved or lost.

The General tab also displays current configuration and status for the local agent. If you make changes to the configuration, the new information is displayed after a short period of time. If the agent cannot connect to any collector, it spools audit data to the offline data location. When it finds a collector, the agent sends the spooled data to it. The offline storage space is not reclaimed until all of the spooled data has been sent to a collector.
Click the Troubleshooting tab, then click Diagnostics to generate diagnostic information about the installation the agent is part of, the collector the agent sends data to, the size of offline storage, and other information. For example:

After you generate diagnostic information, you can right-click to select all of the text. With the text selected, right-click, and select Copy to copy and paste the diagnostic report into a text file.
Click Options to specify the level of detail to include in the log file or to turn off logging.

The default log level reports informational messages, warnings, and errors. You can click View Log to see information in the current log file.
Click Close to return to the agent configuration panel.

Setting the Color Depth for Captured Sessions

Because audit and monitoring service captures user activity as video, you can configure the color depth of the sessions to control the size of data that must be transferred over the network and stored in the database. A higher color depth also increases the CPU overhead on audited computers but improves resolution when the session is played back. A lower color depth decreases the amount of data sent across the network and stored in the database. In most cases, the recommended color depth is medium (16 bit). The CPU and storage estimates in this guide are based on a medium (16 bit) color depth.

To change the color depth for captured sessions:

Log on to the computer where the Agent for Windows is installed.
In the list of applications on the Windows Start menu, click Agent Configuration to open the agent configuration panel.
Click Auditing and Monitoring Service.
Click Settings.
On the General tab, click Configure
Select the maximum color quality for recorded sessions, then click Next.
Follow the prompts displayed to change any other configuration settings.

Removing an Audited Computer

If an audited computer has been removed from the installation, the audited computer will continue to be listed on the Audit Manager console as Disconnected. To remove the decommissioned audited computer, select Delete from its context menu.

Adding an Installation

Although a single installation is the most common deployment scenario, you can configure multiple installations. For example, you can use separate installations to provide concurrent production and test-bed deployments or to support multiple administrative domains within your organization.

To create a new installation:

Open Audit Manager.
Select the root node, right-click, then select New Installation.
Follow the prompts displayed.

The steps are the same as the first installation. For more information, see Creating a new installation.
Choose the appropriate installation for each collector using the Collector Configuration wizard.
Choose the appropriate installation for each agent using the Agent Configuration wizard.

Delegating Administrative Tasks for a New Installation

The account you use to create a new installation is the default administrator and Master Auditor with full control over the entire installation and the ability to delegate administration tasks to other Active Directory users or groups. You can grant permission to perform administrative tasks to other users by opening the Properties for each component, then clicking the Security tab.

Opening an Installation in a New Console

If you create multiple installations at the same site, you can select the installation name, right-click, then select New Window From Here to keep consoles for different installations separate from each other. Creating a new window for each installation can help you avoid performing operations on one installation that you intended to perform on another.

Closing an Installation

The Audit Manager console allows you to manage multiple installations. To remove the current installation from the console, but not physically remove the database or the information published to Active Directory, you can select the installation name, right-click, then select Close.

Publishing Installation Information

DirectManage Audit publishes installation information to a service connection point (SCP) object in Active Directory so that audited computers and collectors can look up the information. If the published locations for multiple SCPs in the same installation are not the same, or if collectors cannot read from at least one of the published locations, the collectors are unable to determine which audit store is the best match for the sites and subnets, and so they do not attempt to connect to an audit store.

Permission to publish to Active Directory

Only administrators who have been delegated permission to modify various attributes of the installation can publish those attributes to Active Directory.

If you do not have Active Directory permission to modify the installation, the updates are kept in the audit management database, and a message is issued to notify you that the installation information could not be updated in Active Directory.

Synchronizing Installation Information

If you have an Active Directory account with permission to publish information about the installation, you can update the service connection point.

To publish the service connection point for an installation:

Open Audit Manager.
Select the installation name, right-click, then click Properties.
Click the Publication tab, then click Synchronize to publish the information.

In a multi-forest or DMZ environment, this tab lists multiple Active Directory locations to which to publish.
Click OK to close the installation properties.

Removing or Deleting an Installation

Before you can remove or delete an installation, you must do the following:

Run the setup program to remove all agents and collectors and collector service connection points (SCPs).
Detach and remove all audit store databases.
Open the Installation Properties and click the Publications tab to make sure only one installation service connection point (SCP) is listed.

{b}Note: {/b}To remove service connection points on other sites, contact an administrator with publication permission on those sites.

To remove or delete an installation, select the installation in the Audit Manager console, right-click, then select Remove to open the Remove installation dialog box.

Click Remove to remove the installation but not delete the management database from the SQL Server instance.
Click Delete to remove the installation and delete the management database from the installation of SQL Server.

Note:All the publications published to Active Directory are removed when you remove or delete an installation.