SQL Server Auditing: A Learning Series Part Eight
Continuing our learning series on auditing, today we discuss a couple of caveats to close out the week before we create database audits next week.
- In order to CREATE, ALTER, or DROP on either the server audit or server audit specification, the security principle must be assigned to ALTER ANY SERVER AUDIT or CONTROL SERVER permission.
- You can rename an Audit but not a server audit specification so choose your name wisely.
- In order to modify the properties of either the server audit or server audit specification, you must disable them and then re-enable them after your changes are completed.
- In order to CREATE, ALTER, or DROP a database audit specification, the security principle must be assigned to ALTER ANY DATABASE AUDIT or the ALTER or CONTROL permission on the respective database as well as having the permission in order to connect to the database.
Enjoy and stay tuned as we continue the series next week!
SQL Server Auditing: A Learning Series Part Seven
Continuing our learning series on auditing, today we look at how to query the audit information from the server.
- sys,server_audits displays information on the audits setup on the server.
- sys.server_audit_specifications displays information on the audit specification setup on the server.
- sys.server_audit_specification_details display detailed information about the specifications.
- sys.dm_server_audit_status displays information about the status of your audits.
Enjoy and stay tuned!
SQL Server Auditing: A Learning Series Part Six
Continuing our learning series on auditing, today we look at the results from the audit specification that we created yesterday. In this audit specification we are monitoring for database ownership change or permission change. I changed the owner on one of the databases on the server and an audit log entry was generated as shown in Figure 1. We can see who changed the ownership and what it was changed to. I think it would be better to show me what the original value was. Enjoy and stay tuned!
SQL Server Auditing: A Learning Series Part Five
Continuing our learning series on auditing, today we create a new audit specification (as explained in last week’s post). Remember, in order to create a new server audit specification, you must have created a new server audit. This is a one-to-one relationship and in order to actually collect auditing information both objects are required.
Think of it like an order table that has to have an order lines table in order for a sales order to be made, if that helps your understanding.
- In the security node of SQL Server Management Studio, right-click on Server Audit Specification and select New Server Audit Specification, as shown in Figure 1.
- Change the name and use the drop down selections to select the type of server audits you would like to audit, as seen in Figure 2. (MSDN explanation of groups and actions)
- Right-click on the Server Audit Specification in the Security node and select enable to activate your new audit specification.
You can alternatively script this as well:
CREATE SERVER AUDIT SPECIFICATION [ChangingPermOwner]
FOR SERVER AUDIT [Audit-Test]
ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP)
WITH (STATE = ON)
GO
Enjoy and stay tuned!
SQL Server Auditing: A Learning Series Part Four
Today we continue our series on Auditing with some clarifications. An audit is essentially the combination of several elements. This concept took a day or two to wrap around my brain so I thought I would discuss our way through it.
- The Audit Object is collected on either the server or database level. This covers actions as well as groups of actions.
- The Audit Specification is an object that belongs to an audit. This is a one-to-one relationship between audit object and audit specification. Both items are created at the instance level. The audit specification can collect many server-level or database-level action groups which are raised through extended events. You can have many groups within a specification. In addition, the audit specification is either a database or server specification and it cannot be both.
- The Audit Action Group is a predefined group of actions within the database engine itself. (See the MSDN list of Action Groups and Actions)
- The Target is essentially where the audit results are sent to, which we have already discussed as a file, the Application Log or the Security Log.
I hope this clarifies some points before we move forward. Enjoy and stay tuned.
SQL Server Auditing: A Learning Series Part Three
Continuing our learning series on Auditing, today we move on to setting up the server audit which will allow us to be able to setup auditing at the instance level.
- In SSMS, open the Security node and right-click on Audits and choose New Audit as shown in Figure 1.
- This will present us with a default Create Audit dialog box as shown in Figure 2. Enter a name for your Audit being as descriptive as possible to make it easy for you to look back later and now what this is auditing.
- The Queue delay default is 1000 milliseconds. This is the delay before the audit actions will be processed.
- There is a check box if you would like to shut down the server when the audit log fails. In SQL Server 2012 you have the option to Continue, Shut down the server, or Fail the operation. Figure 2 is from a SQL Server 2008 server.
- As you can see in Figure 2, the default setting for the destination is the file and if this is the setting you choose then you must enter a file path in addition to the other settings shown. If you choose Security Log or Application Log then all of the file options will be unavailable.
- After this process is complete, you will see the audit named under Audits in the Security node. From there you need to right-click on it and select Enable Audit.
As with anything in the GUI SSMS, this too can be scripted as an example:
CREATE SERVER AUDIT [Test-Audit] TO SECURITY_LOG WITH (QUEUE_DELAY = 1000)
Enjoy and stay tuned.
SQL Server Audit in SQL Server 2008 R2
Since I am out of the office today I though I would include this fun video from Microsoft to continue with our Auditing theme that we started earlier in the week. Enjoy!
SQL Server News Hour: SQL Server Audit in SQL Server 2008 R2 – YouTube.
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.
- 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.
- 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.
- 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:
- The SQL Server service account must have the ability to read and write to the file.
- 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.
- Finally, if you have users with the Audit Reader role, then they must have the ability to read the file.
Enjoy and stay tuned as we continue this series!
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!
Point In Time Restores
One of the many skills needed by DBAs today is the ability to restore a database from backup using point in time recovery. This option is only available if you are using the full or bulk-logged recovery model (see my post on recovery models). The default time shown is the ‘most recent possible’ which works in most scenarios.
Why would I need to restore to a point in time? There are many different reasons, one being that you noticed through your monitoring or logs that things went south at a certain point in time. Therefore, we want to restore a minute or two prior to that time. Another scenario that I have seen is that a change is made in an application in production at a certain time. They now want those changes demoted down into a testing environment. In this scenario we would want to make sure our restore includes that point.
How do I do it? In the restore database dialog, you select the ellipsis (…) button to the right of the point in time field below the database name and you will see a date and time option, as shown in Figure 1. Select the remaining restore options as you normally would. Not sure about the rest of the options? See the MSDN directions detailing point in time recovery. Enjoy!













