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.
- 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.
Figure 1 – Generate Security Audits Policy
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!
AD Accounts Are Great, But…
Using Windows Authentication for your database is a great best practice to follow. However, one caveat to remember as one of my administrators found out today. Do not use that account as a login if it is also the account you use for your database.
We setup an AD account for his database, that part is great. He thought that was also the account to use as his application administrative account. Not a good idea because when he fat fingered the password this morning a few times, as people tend to do on Monday mornings when their coffee hasn’t fully kicked in, he locked out his application as well as the database sending 150 alert messages all over the department. This set off a chain reaction where he rebooted his server after unlocked the account and proceeded to call me and tell me that SQL was down and sounded the sky is falling alarm. He overreacted essentially.
When I figured out what he did, I explained the situation and told him that he needed another AD account for his application or I could setup another one for his database. He said he installed his application under that account and cannot change either one. Not the best scenario, but every time you fat finger the account you will bring the world down upon you. Your choice. He chose the road well traveled unfortunately. Enjoy!
Know Your (Pre-Defined DB) ROLE!
Yesterday we talked about the Rock and how he can help you with SQL Server security ala “know your role.”
Do you know your SQL Server pre-defined database security roles?
These pre-defined roles will allow their respective members to perform defined sets of activities within each database. It is important to realize that these exist in every database and you cannot drop these roles. They are as follows:
- db_owner Role: This is the Mac Daddy of fixed database roles as it can perform all configuration and maintenance activities on the database including dropping the database. It is the only role that members can add additional users to this role.
- db_securityadmin Role: Members of this role can modify role membership (except db_owner) and manage permissions.
- db_accessadmin Role: Members of this role can add or remove access to the database for Windows logins, Windows groups, as well as SQL Server logins.
- db_backupoperator Role: Members of this role can back up the database, that is all.
- db_ddladmin Role: Members of this role can run any Data Definition Language (DDL) command in a database, in other words they can run ALTER, CREATE, DISABLE TRIGGER, ENABLE TRIGGER, DROP, TRUNCATE, and UPDATE STATISTICS statements.
- db_datawriter Role: Members of this role can add, delete, or change data in all user tables.
- db_datareader Role: Members of this role can read all data from all user tables.
- db_denydatawriter Role: Members of this role cannot add, modify, or delete any data in the user tables within a database.
- db_denydatareader Role: Members of this role cannot read any data in the user tables within a database.
There are several of these that I rarely use, but they are there if I need them. Like the Rock says “know your role!” Enjoy your weekend!
Know Your ROLE!
In the famous words of The Rock “know your role and shut your mouth!” Well mainly we were going with “know your role.”
Do you know your SQL Server security roles?
A SQL Server role defines exactly what a user can and cannot do inside a database. It is also possible for multiple users be it AD users and groups or SQL Server users can share this role. Roles are similar to AD groups in Windows security except they only control security within databases.
Today we will discuss the fixed roles which are setup across the server instance and apply to all objects on the server. They are as follows:
- SysAdmin Role: This is the Mac Daddy of roles as it can perform any and all actions on the server.
- ServerAdmin Role: This role can change configuration options on the server. They can also shut down the server, choose them wisely.
- SetupAdmin Role: This role can manage linked servers, SQL Server startup options and tasks.
- SecurityAdmin Role: This role can only manage server security. They can also reset passwords saving you from the mundane task, if you have your own minions.
- ProcessAdmin Role: This role has the ability to kill processes running on the SQL Server aka SPID killer aka Die SPID die!
- DbCreator Role: This role can create, alter, drop and restore databases, which is pretty powerful just now Genie from Aladdin powerful.
- DiskAdmin Role: This role can manage the SQL Server disk files.
- BulkAdmin Role: This role can only run the bulk insert command (I have personally never seen used before).
- Public Role: Every user belongs to the public role by default and therefore you cannot change membership to this role. Keep in mind if you assign any permissions to this role it will apply across the entire instance.
There are several of these that I rarely use, but they are there if I need them. Like the Rock says “know your role!” Tomorrow we will discuss pre-defined database roles. Enjoy!
We Need your SA Account
If you are dealing with a large development and infrastructure staff like I do then I am sure at some point you have heard, “We need the password to your SA account.”
Which is always followed up with my question, “Who is your daddy and what does he do?” Wait that is the line from Kindergarten Cop, my real question is always; “What for?”
Then there is a phone call where someone usually tells me that I am not being a team player. No, you do not need my SA account to deploy a database. No, you do not need db_owner to access your own database. At this point, I do not care if the vendor told you it is required. Unless you can tell me what it is you need to do then the answer is no. No, I am not letting you wreak havoc on my production environment. Yes, I would love to help you and yes we are on the same team. No, I will not give you the SA password. Sorry, not going to happen. Yes you can enjoy your weekend, that is all!
My Mistake For Your Enjoyment
This morning when an aggravated user contacted me that they could not get into a new database that I setup on Friday, I discovered that I had made a mistake. Well that’s never happened before, well not today anyway.
Alright, here we go. I created three new logins that would access development and acceptance copies of a production database that I had just setup on an acceptance server using Red Gate‘s SQL Compare and SQL Data Compare (which I will blog about soon, excellent product). In my possession, actually a sharepoint list, I had the password for each of these three new logins. Today I found out that the password I had listed was out of date. No problem, easy fix!
Using SSMS I would easily change the passwords and then update my sharepoint list to the new passwords, this is DBA 101 stuff. Not so fast my friend! SSMS then presented an error stating that the password did not meet our ultra-rigid fort knox password policy (see posts on security). No problem, I forgot to uncheck the ‘Enforce password policy’ check box. That happens all the time when I get in a hurry. Now it is unchecked and SSMS presents the following error:
The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.
There was my real mistake committed on Friday; I forgot to uncheck the ‘User must change password at next login’ check box when I created the logins. It was a rookie mistake, but I was in a hurry to get things done so I could go and get my root canal in the afternoon. Luckily for me this was not a resume updating event. In order to fix this we need to do the following:
USE MASTER
GO
ALTER LOGIN [userlogin] WITH PASSWORD ‘original password’
GO
ALTER LOGIN [userlogin] WITH CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;
Then I was able to change the password, which I used ALTER LOGIN since I had it in the query window. What a way to start the week off. Enjoy!
Orphaned Windows Users….Annie?
A caveat when working with Windows domain users in your SQL Server is the possibility of orphaned users. When a user is removed from AD, they are not automatically removed from SQL Server. This is an orphaned user as far as SQL Server is concerned. Thus, no access will be provided to this account even if the AD account is recreated because it will have a new SID that will not match the existing item stored in SQL Server. You can run the sp_validatelogins stored procedure to display if any orphaned users are in the database.
To resolve this problem you will need to remove the user using DROP LOGIN ‘AD\Annie’. Then you will need to revoke the user’s server access using EXEC sp_revokelogin ‘AD\Annie’ to remove the user’s access to the server.
Enjoy!
Windows Logins Basics
As most people would agree, Windows Authentication is the preferred authentication method in SQL Server as it provides consistency with your Windows or AD administration and it allows you to use groups for ease of administration if your users are organized into groups by security level and function.
To create a login in T-SQL use the following code:
CREATE LOGIN ‘AD\Ed’
To remove a login using T-SQL, use the following code:
DROP LOGIN ‘AD\Ed’
To deny a login using T-SQL, use the following code (NOTE: if the user or group does not exist in SQL Server, this command will add them first):
DENY CONNECT ‘AD\Ed’
This is a good foundation for a couple of other posts that I am working on for this week. Enjoy!
Logon Triggers aka How To Lock That Annoying User Out During Lunch
Earlier this week, I chose a few SQL Server 2008 topics for our #SQLHelp MCITP study group to discuss here on the blog. Thus, today I will discuss logon triggers, one of the new features available in SQL Server 2008 (well actually if I remember correctly they were snuck in 2005 SP2…shhhh). Logon triggers are a special form of trigger that the database administrator can use in order to monitor logon events.
Logon triggers can be used for the following purposes:
- To audit and control server sessions (such as tracking logon activity)
- Limiting the number of sessions allowed for a particular logon
- Restricting logons to SQL Server (similar to AD snap-in that lets you set the hours that a user may logon)
Here is an example from books online showing how to set up a logon trigger that limits the number of concurrent sessions for a particular logon, logon_test in this case. This example, in particular, will limit the concurrent sessions to three. You must create this logon in order to test this code, or change the logon name to match your requirements.
CREATE TRIGGER connection_limit_trigger
ON ALL SERVER WITH EXECUTE AS ‘logon_test’
FOR LOGON
AS
BEGIN
IF ORIGINAL_LOGIN()= ‘logon_test’ AND
(SELECT COUNT(*) FROM sys.dm_exec_sessions
WHERE is_user_process = 1 AND
original_login_name = ‘logon_test’) > 3
ROLLBACK;
END;
Here is some sample code for restricting the user based on logon time (between 12Pm and 1pm in this example for all users except the SA\SQLAdministrator):
CREATE TRIGGER Restrict_Logon_HoursON ALL SERVERFOR LOGONASBEGINIF (DATEPART(HOUR, GETDATE()) BETWEEN 12 AND 13) AND(SUSER_SNAME() != ‘AD\SQLAdministrator’)BEGINROLLBACK;
END;END;
Once you have created logon triggers, you can view them by a simple query to the sys.server_triggers metadata.
SQL Swampland 