Visit our SQL Audit Background page for lots of help.

SQL Server can definitely output its raw audit events to the Windows event log. In fact, we encourage you to configure it and try it out. We think you will agree that LOGbinder for SQL Server is needed for 2 reasons:

1. Performance: Writing events to the SQL server's local security log can consume added CPU, memory and disk resources which may be unavailable on heavily loaded database servers.
2. Raw, Cryptic Audit Data: The audit records generated by SQL Server audit are cryptic and difficult to understand. SQL Server uses log record format for documenting everything from an insertion on a table to a modification of a stored procedure. And while SQL Server can write events to the security log, it uses the same event ID for all events, and the IDs and keywords are not resolved. Thus, it requires in-depth knowledge of the SQL audit model to decipher events. LOGbinder for SQL Server enriches SQL Server’s cryptic and generic audit messages to produce more than 300 different and easy-to-understand audit log events in Windows event log, where any log management or SIEM solution can collect, alert, report, and analyze.

See a list of event IDs generated by LOGbinder for SQL Server.

You can run LOGbinder for SQL Server on the same server where SQL Server auditing is enabled and LOGbinder for SQL Server's modest resource usage will not be felt in most environments, but you can ensure LOGbinder for SQL Server has absolutely no impact on heavily loaded SQL Servers by installing LOGbinder for SQL Server on a different server. This latter does not incur the expense of another SQL Server license because LOGbinder for SQL Server can use any edition of SQL Server 2008 (and later) - even the free Express Edition - to read audit logs generated by other SQL Servers via shared folders.

Thankfully SQL Server has a very granular audit policy that allows you to audit just the desired actions on just the desired objects. So it is unlikely auditing will have a material impact on your database server performance unless you try to audit frequently executed operations like (select, update, insert, delete) on heavily accessed tables. Even with that said, most SQL Servers can output a great deal of audit events without feeling it. This is especially true if you configure the Audit to target a file instead of the local event log; appending to a file is much faster than calling Windows event APIs. And the good news is LOGbinder for SQL Server is designed to process SQL audit log files and can do so from a different system than your busy database server. So, to ensure audit trail generation without performance degradation, enable auditing of table and view operations only as needed and target the Audit to create files in a shared folder on a different server, where LOGbinder for SQL Server is installed.

LOGbinder is fully integrated with Windows and SQL Server security and complies with widely accepted secure design and coding techniques.

At installation, LOGbinder secures the folder permissions where the software files reside. To protect LOGbinder's configuration from tampering, LOGbinder encrypts its configuration data.

LOGbinder security requirements are greatly simplified since LOGbinder does not store your audit log data. LOGbinder is designed to quickly get audit events out of the SQL Server audit log files and to the destination of your choice, at which point your log management solution takes over. If you configure LOGbinder for SQL Server to direct events to the Windows security log, you leverage the significant effort Microsoft has invested in protecting the security log. And if you are already collecting Windows security logs with your log management application, SQL audit events will automatically be included when you install LOGbinder for SQL Server.

LOGbinder for SQL Server's design helps you fulfill separation of duty and audit trail integrity requirements by quickly getting audit events off the system where they are produced (and thus vulnerable to intruders or malicious administrators) and into your separate and secure log management system.

LOGbinder for SQL Server installs in about 2 minutes and only requires a few settings:

1. Select which folders for LOGbinder to monitor for SQL audit log files
2. Specify the user account LOGbinder should run as
3. Choose whether to output events to the custom LOGbinder SQL event log, to the actual Windows Security Log, syslog or to a text file.

Check the Application log for warnings or errors from source LOGbndSQ

These are functions of a log management solution. LOGbinder complements and enhances the value of your log management solution.

With LOGbinder, any log management solution that supports Windows event logs, text files or syslog can now collect, monitor, archive, and report on SQL Server audit log activity. Also, see next Q&A.

LOGbinder can output to either the Windows Security Log, syslog, text file, or a custom Windows event log called LOGbinder for SQL Server.

Based on customer feedback we may add additional output formats such as syslog, text files, or XML.

See pricing and licensing information.

No. See above questions on performance.

The account needs to be authorized to run as a service, and if using the security log, must be authorized to write to the security log.

Yes, LOGbinder for SQL Server can monitor multiple shared folders for SQL audit logs produced by different SQL servers.