Blog Archives

SQL Server Auditing: A Learning Series Part Two

Continuing our series on Auditing from yesterday, I wanted to bring up a few additional points if you are planning on using the Windows Security log as the target for your auditing results.

  1. You must add the SQL Server service (the account that you are actually using to run SQL Server, go to the SQL Server Configuration manager and check out the Log On As column) to the Generate security audits policy.  Go to your Local Security Policy then under Security Settings select Local Policies the User Rights Assignment.  There you will find the policy so that you may add the account similar to what is shown Figure 1.
  2. Keep in mind if you are running in a clustered environment you need to do this on each node so that in a failover scenario the auditing continues to work as designed.
  3. Also in the Local Security Policy, you need to go to Local Policies then Audit Policy and select to audit success and failure for the Audit Object Access policy.

In addition, if you plan on using a file as a target instead of the windows logs you must keep the following in mind:

  1. The SQL Server service account must have the ability to read and write to the file.
  2. If you have a user account that is a member of the Audit Administrator role, they must also have the ability to read and write to the file.
  3. Finally, if you have users with the Audit Reader role, then they must have the ability to read the file.
GenSecAudits

Figure 1 – Generate Security Audits Policy

Enjoy and stay tuned as we continue this series!

Advertisement

SQL Server Auditing: A Learning Series Part One

Over the next few weeks I will be presenting here for your learning SQL Server Auditing, as I learn it.  I have never been called upon to use the auditing features in any production SQL Server environments strangely enough.  I have known about the capabilities but never really been in a position to advocate for or against them.

Let us start our journey with some limitations.  Auditing uses SQL Server resources, albeit less than trace-based auditing.  This may or may not be a big deal depending upon how busy the server is.  Another limitation is the fact that auditing in limited at the instance level.  There is no easy way to manage auditing on multiple servers from a central location.  There is also no built-in reporting for auditing and the data is stored in a file or OS event logs.  You can however, load that data into a database and create your own reports.

Enjoy!

%d bloggers like this: