Deploying the audit and monitoring service infrastructure

The multi-tiered architecture of audit and monitoring service requires that you deploy an audit and monitoring service infrastructure to transfer and store the information captured by agents on the audited computers. This auditing infrastructure is referred to collectively as an Auditing installation. The audit and monitoring service installation represents a logical boundary similar to an Active Directory forest or site. It encompasses all of the audit and monitoring service components you have installed—agents, collectors, audit stores, management database, and consoles—regardless of how they are distributed on your network. The installation also defines the scope of audit data available. All queries and reports are against the audit data contained within the installation boundary.

The most common deployment scenario is to have a single audit and monitoring service installation for an entire organization so that all audit data and management of the audit data is centralized. Within a single audit and monitoring service installation, you can have components wherever they are needed, as long as you have the appropriate network connections that allow them to communicate with each other. The audit data for the entire installation is available to users who have permission to query and view it using a console. For most organizations, having a single audit and monitoring service installation is a scalable solution that allows a “separation of duties” security model through the use of audit roles. If you establish a single audit and monitoring service installation, there will be one Master Auditor role for the entire organization, and that Master Auditor can control the audit data that others users and groups can see or respond to by defining roles that limit access rights and privileges.

However, if you have different lines of business with different audit policies, in different geographic locations, or with different administrative groups, you can configure them as separate audit and monitoring service installations. For example, if you have offices in North America and Hong Kong managed by two different IT teams—IT-US and IT-HK—you might want to create two installations to maintain your existing separation of duties for the IT‑US and IT-HK teams.

Planning where to install audit and monitoring service components

Before you install audit and monitoring service components, you should develop a basic deployment plan for how you will distribute and manage the components that make up an installation. For example, you should decide how many collectors and audit stores to create and where to put them. You should also consider the network connections required and how many computers you plan to audit. For example, you can have multiple agents using the same set of collectors, but you should keep the collectors within one hop of the agents they serve and within one hop of the audit stores to which they transfer data.

By planning where to install components initially, you can determine the number of collectors you should have for load balancing or redundancy. After the initial deployment, you can add collectors and audit stores whenever and wherever they are needed.

Using multiple databases in an audit store

Each audit store uses Microsoft SQL Server to provide database services to the installation. When you configure the first audit store, you identify the database instance to use for audit and monitoring service and that database becomes the active database for storing incoming audit data. A single audit store, however, can have several databases attached to it. Attached databases store historical information and respond to queries from the management database. You can use the Audit Manager console to control the databases that are attached and to designate which database is active. Only one database can be active in an audit store at any given time.

Although the audit store can use multiple databases, the presentation of session data is not affected. If a session spans two or more databases that are attached to the audit store, the Audit Analyzer console presents the data as a single, unbroken session. For example, if you change the active database during a session, some of the session data is stored in the attached database that is no longer active and some of it stored in the newly activated database, but the session data plays back as a single session to the auditor.

Using multiple consoles in an installation

A single audit installation always has a single audit management server and database. In most cases, however, you use more than one console to request data from the audit management database. The two most important consoles in an installation are the Audit Manager console and the Audit Analyzer console.

  • As an installation owner, you use the Audit Manager console to configure and manage the audit installation. In most organizations, there is only one Audit Manager console installed.
  • Auditors and administrators use the Audit Analyzer console to search, retrieve, play back, and delete sessions. The auditor can use predefined queries to find sessions or define new queries. Auditors can also choose whether to share their queries with other auditors or keep them private. In most organizations, there are multiple Audit Analyzer consoles installed.

In addition to the Audit Manager and Audit Analyzer consoles, audit and monitoring service includes a settings control panel and a collector control panel.

  • As an administrator, you can use the Centrify Audit & Monitoring Service Settings control panel to configure the agent on Windows. Normal users who log on and run applications on the audited computer cannot stop, pause, restart, or configure the agent.
  • You can use the collector control panel to configure a collector.

The following illustration is an example of the architecture of a medium-size installation.