The following table shows differences between gathering with and without agents.
Agents |
No agents | |
---|---|---|
What to include in the site | One computer with the appropriate ODBC driver is enough for the InTrust site specified in the gathering job. It does not matter much what computer that is, as long as the computer has a reliable connection with the InTrust server on the one hand, and with all necessary SQL servers on the other hand. |
If the InTrust server itself is connected to the SQL servers, it is a good idea to create and use a site that includes only the InTrust server. |
How to configure data sources, jobs and policies |
InTrust gathers from one SQL server instance at a time, so there is no point in creating many jobs. Take the following steps:
You can also use a separate copy of the gathering policy for this purpose. |
InTrust gathers from all specified SQL server instances at once if you have a separate gathering job for each SQL server instance, each using a separate gathering policy based on a separate data source. However, SQL servers are processed one by one if you configure data sources, jobs and policies as for gathering with agents. |
For more information about configuring database events data sources, see Auditing Custom Logs.
Depending on how you organize gathering of SQL Server audit data, the SQL server, The InTrust server or the InTrust agent computer gets the most load. When planning the gathering, consider the following:
You can use a site that includes one InTrust agent computer connected to one SQL server. To collect from multiple SQL servers in this way, create a similar site for each SQL server.
Gathering takes place as follows:
|
Caution: When you use an agent for data gathering and trusted_connection is set to true in the connection string, then the connection to the SQL server will be created under the agent account. |
In most environments, this is the preferred way to organize C2 log gathering. The InTrust agent computer gets the most load in the process without significantly affecting SQL server and InTrust server performance.
|
Note: The following measures can help you improve gathering performance in this scenario:
With regard to performance, it does not matter whether the agent computer runs a workstation operating system or server operating system. |
You can use a site that includes multiple SQL servers and gather from them without agents. The following figure shows this workflow:
If you organize gathering like this, include the %COMPUTER_NAME% variable in the connection string of the data source that you use. The variable will be resolved for each computer in the site, and all computers in the site will be processed one by one.
The following is a sample connection string for this gathering method:
DRIVER = SQL Server; SERVER = %COMPUTER_NAME%; UID = sa; PWD = %PASSWORD%; APP = Quest InTrust; WSID = InTrustServer
The InTrust server gets the most load in this case. Note that sequential gathering can take very long.
You can use a site that includes multiple InTrust agents installed on SQL servers, as shown in the following figure:
In this workflow, include the %COMPUTER_NAME% variable in the connection string of the data source that you use. The variable will be resolved by each agent, and all agents will gather data simultaneously. See the description of Method 2 for a sample connection string.
In this case, the SQL servers get the most load.
Cleanup is performed by running a cleanup SQL query. This query is specified in the data source properties on the SQL Cleanup Query tab. By default, cleanup is disabled. However, it is recommended that you enable it, unless you must retain all audit data. Cleanup helps reduce gathering time and saves disk space on your SQL servers.
To enable cleanup
The “Microsoft SQL Server C2 log” and “Microsoft SQL Server C2 log (events for reporting)” data sources are configured to delete C2 trace files after they have been gathered. If you want to keep the files, do the following:
Now, instead of removing the files, InTrust will keep them and append the extension “.que” to their names.
The “Microsoft SQL Server Error log” data source, included in the “SQL Server Error log” policy, is used for collecting the Error log. The data source properties contain the absolute path to the Error log file. You need to edit the path for your particular environment; the default path specified there is just an example.
If the Error log is written to a location other than the default, then do as follows:
If you want to gather Error logs of named SQL server instances, then do as follows for each named instance:
|
Note: The log name is specified in the Log name field on the Settings tab in data source properties. For the SQL Server Error log, make sure “SQL Server Error log” is specified in that field. Otherwise, your Error log-based reports will not work properly. |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center