So now that you’re well versed on pwned or pwnage let’s talk about a way to ensure that the DBA (who we’ll call “Brent”) that left the company does not get all zombie and start eating your brain after he’s gone.

**RING RING RING**

You: Hello?

Them: Where is my report?

You: How did you get this number?

Them: Where is my report?

You:  What report?

Them:  Wow… Brent was way smarter then you *click*

(and yes this is a shout out to Brent Ozar and a huge congratz to Jeremiah Peschka!!  not saying Brent would ever do this but it’s the buzz of the SQL Twitterverse this morning so I thought I had to work it in somehow )

The first thing to check when something goes wrong after someone has left the company is if anything could of been tied to that user’s Active Directory account because chances are they are now disabled/deleted/removed/zombified.

“So here’s a little script that’s mine… you might want to execute line by line… don’t worry….. be happy.”

(as always any and all scripts on this blog should never be ran… k that’s a bit much… you can run it but test it, tweak it, and make sure it works for you in your environment )

I wrote this script to not care if the instance is the default or a named instance (why you may ask? well cause I use Powershell to run this script against all my servers and return me any reports that are not owned by a particular user):

SET NOCOUNT ON
 
DECLARE @InstanceName nvarchar(100)
DECLARE @ReportServerDatabaseName nvarchar(100)
DECLARE @ReportingDatabaseFoundInd bit
DECLARE @SQLSTMT nvarchar(2000)
 
SELECT @InstanceName = @@SERVERNAME
SELECT @ReportingDatabaseFoundInd = 0
 
IF @InstanceName = SUBSTRING(@InstanceName, ISNULL(CHARINDEX('\', @InstanceName)+1, 0), LEN(@InstanceName))
	BEGIN
		SELECT	@ReportServerDatabaseName = 'ReportServer'
	END
ELSE
	BEGIN
		SELECT	@ReportServerDatabaseName = 'ReportServer' + '$' + SUBSTRING(@InstanceName, ISNULL(CHARINDEX('\', @InstanceName)+1, 0), LEN(@InstanceName))
	END
 
SELECT	@ReportingDatabaseFoundInd = 1
FROM	master.dbo.sysdatabases
WHERE	name = @ReportServerDatabaseName
 
IF @ReportingDatabaseFoundInd = 1
	BEGIN
		SELECT @SQLSTMT = 'SELECT	@@SERVERNAME as [InstanceName],
									U.UserName as [SubscriptionOwner], C.[Path],
									S.[description]
							FROM	' + @ReportServerDatabaseName +
								'.dbo.subscriptions S INNER JOIN ' +
								@ReportServerDatabaseName + '.dbo.users U ON U.userid = S.ownerid INNER JOIN ' +
								@ReportServerDatabaseName + '.dbo.[Catalog] C ON S.Report_OID = C.ItemID'
		EXEC sp_executesql @SQLSTMT
	END

Now if this list is a bit HUGE you can add a WHERE clause in there to look for a particular user name.

So now that you’ve found all the reports that are tied to the no longer existant user how do you change them?

DECLARE @OldID uniqueidentifier
DECLARE @NewID uniqueidentifier
SELECT @OldID = UserID FROM dbo.Users WHERE UserName = 'Domain\LoginName'
SELECT @NewID = UserID FROM dbo.Users WHERE UserName = 'Domain\LoginName'
UPDATE dbo.Subscriptions SET OwnerID = @NewID WHERE OwnerID = @OldID

A gotcha to watch out for with this is that the new ID that you set the report to needs to be in the users table (in your ReportServer database) so if you want to change it to a user that is not already in there you’ll have to log in as that user and add/update/delete a report to get them in there. (There is probably an easier way but that has always worked for me)

Enjoy!!

There are 2 MSDB database roles that relate to the Central Managment Server:

ServerGroupReaderRole:  Members of this group can only view the Central Management Server’s registered servers

and

ServerGroupAdministratorRole: Only members of this group can add/update/delete registered servers to the Central Management Server

So if your first instict was to grant db_datareader access to the MSDB database it pays to take a look around and make sure that you’re not granting more security then what is required.

Some great articles on Central Managment Servers:

Configuring and Using a Central Management Server for SQL 2008 – Brent Ozar

SQL Server 2008 Central Managment Servers – Kimberly Tripp

Create a Central Management Server and Server Group

Enjoy!!

Big thanks to Brent Ozar for helping both by critiquing the video ahead of time (and providing some very valuable feedback) as well as offering to encode, setup, and host the video on SQLServerPedia.com.

In watching the video on SQLServerPedia I’m already thinking of ideas for topics of future webcasts as well as  improvements that can/will be made down the road as well… but I guess at the end of the day everyone has to have a first video and this is mine.

Here is the link for the Podcast on SQLServerPedia  (larger viewing area and you can download for later if you’d like):

Guest Podcast: Auditing Your Database Server

[media id=1 width=490 height=400]

Thanks for watching!!

Enjoy!!

http://www.eventbrite.com/event/378687665

Please be sure to not only click the “Add to my calendar” but also the “Register” button so that we can plan accordingly for food and drinks. 

Date:  July 29th 2009
Time: 5:00 pm – 7:00 pm
Location: Stanley A. Milner library
Map: 7 Sir Winston Churchill Square
Meeting Room: 6th Floor – Room 7
Speaker: Colin Stasiuk
Topic: SQL Security Auditing Through The Ages

(Live Meeting Link to follow)

Agenda:
5:00 pm – Pizza and Socializing
5:30 pm – Sponsor Presentation
5:45 pm – Feature Presentation
6:45 pm – Wrap Up and Draws

Presenter Information:   Colin Stasiuk is an MCP, MCTS SQL 2005/2008, MCITP DBDEV, and MCITP DBA.  Currently, he is an independent consultant contracted to Vantix Systems and working for the Government of Alberta.  Colin is an accomplished Microsoft SQL Server DBA who has been working with SQL Server since 1996.  He is the founder of Benchmark IT Consulting  and is always willing to lend a hand with questions in many SQL Server community forums and via Twitter (http://twitter.com/BenchmarkIT) .  His specialties include SQL Server Administration, Performance Tuning, Security, Best Practice / Standards, Upgrades, and Consolidation.

Colin is a proud PASS member, President of EDMPASS, and is on the DBA Abstract Selection Team for this years PASS Summit. 

 If you haven’t signed up already at EDMPASS.com please do so now to receive meeting notifications, news, and updates from EDMPASS.

Hope to see you there.

In SQL Server 2005 there are 3 Database Roles in the msdb system database:

MSDN Integration Services Roles 2005

 
In SQL Server 2008 these 3 Database Roles are now named db_ssisltduser, db_ssisoperator, and db_ssisadmin

 MSDN Integration Services Roles (2008)

So in this particular case granting the user db_dtsltduser was enough to fullfill their request as they only needed the ability to run packages that they created.  As always with security/permissions make sure you only grant what’s required instead of going to easier route of using an “admin” type of role.

Enjoy!!

Hint: Using SQL Server 2008′s Central Management Servers will allow you to get this “snapshot” for all your servers at once

SELECT
@@SERVERNAME AS 'InstanceName', name AS Login,
sysadmin =
CASE
WHEN sysadmin = 1 THEN 'X'
ELSE ''
END,
securityadmin =
CASE
WHEN securityadmin = 1 THEN 'X'
ELSE ''
END,
serveradmin =
CASE
WHEN serveradmin = 1 THEN 'X'
ELSE ''
END,
setupadmin =
CASE
WHEN setupadmin = 1 THEN 'X'
ELSE ''
END,
processadmin =
CASE
WHEN processadmin = 1 THEN 'X'
ELSE ''
END,
diskadmin =
CASE
WHEN diskadmin = 1 THEN 'X'
ELSE ''
END,
dbcreator =
CASE
WHEN dbcreator = 1 THEN 'X'
ELSE ''
END,
bulkadmin =
CASE
WHEN bulkadmin = 1 THEN 'X'
ELSE ''
END,
CONVERT(CHAR(16),createdate,121) AS 'DateCreated'
FROM MASTER.dbo.syslogins
ORDER BY NAME

Enjoy!!

I would LOVE some feedback/comments/suggestions/etc… what I would love even more is a link to a better script that does the same thing

LOL remember this is v1 so I haven’t really gone back through it and made it “net worthy” but if you could give it a run, give me some feedback, etc it would be greatly appreciated

SET NOCOUNT ON 
DECLARE @DatabaseRoles NVARCHAR(MAX) 
DECLARE @SQLSTMT NVARCHAR(MAX) 
DECLARE @cmptlevel INT 

DROP TABLE #DatabaseRoleMatrix
 


UPDATE: K. Brian Kelley asked if handles nested user defined database roles…. it does now

Enjoy!!

CREATE ROLE db_executor
GRANT EXECUTE TO db_executor
EXEC sp_addrolemember 'db_executor', 'username'

So this is an “all or nothing” script so if you're wanting to be selective with which stored procedures you want to grant the permission to than this is not the solution for you… but head on over to facility9 for a look at how you can grant execute on a “pattern” of stored procedures.

UPDATE: As pointed out by K Brian Kelley you might end up with more work in doing this if later down the road there is a stored procedure that you don't want the user to be able to execute. He suggests (and how can you NOT trust an MVP) granting execute not at the database level but at the schema level for more control over what the user can and cannot execute… very sound advice… Thanks!!

http://benchmarkitconsulting.com/colin-stasiuk/2009/01/21/sqlagentreaderrole-not-so-reader/

Below is the solution I’m working with to give developers access to the Job Activity Monitor but NOT the ability to create new jobs.

I know adding a role to a system database is not ideal but I’m open to other suggestions


USE [msdb]
GO
CREATE ROLE [SQLAgentReadOnlyRole] AUTHORIZATION [dbo]
GO
EXEC sp_addrolemember N'SQLAgentReaderRole', N'SQLAgentReadOnlyRole'
GO
DENY EXECUTE ON OBJECT::msdb.dbo.sp_add_job TO SQLAgentReadOnlyRole
DENY EXECUTE ON OBJECT::msdb.dbo.sp_add_jobserver TO SQLAgentReadOnlyRole
DENY EXECUTE ON OBJECT::msdb.dbo.sp_add_jobstep TO SQLAgentReadOnlyRole
DENY EXECUTE ON OBJECT::msdb.dbo.sp_update_job TO SQLAgentReadOnlyRole
DENY EXECUTE ON OBJECT::msdb.dbo.sp_add_jobschedule TO SQLAgentReadOnlyRole

So after you create your new SQLAgentReadRoleRole you can add role members to it and they will be able to view the Job Activity Monitor but will not be able to create new jobs… use at your own risk as like I said… I’m still working with it but this is the direction I’m heading right now.

If anyone has a more elegant solution I’d be very interested in seeing it.

Why you grant them SQLAgentReaderRole access in msdb…. WRONG

http://technet.microsoft.com/en-us/library/ms188283.aspx

The SQLAgentReaderRole is a reader role for the jobs that currently exist but wait here is where the good (or bad depending on if you’re in a good mood or not) part comes in.

Me – “Hey Mr Developer I made this change in UAT you should now be able to view the job activity monitor… just for my own curiousity I’m going to come by can you try to execute, delete, update jobs that are there.  ”

Mr Developer – “nope… can’t do anything like that”

Me – “Great… can you create a new job”

Mr Developer – “Yup”

Me – ” *sigh* I hate (and by hate I mean it in a love/hate kinda way) Microsoft

That’s right folks… SQLAgentReaderRole can create jobs.  So although it’s called SQLAgentReaderRole be careful granting this access cause whomever you add to this role can create new jobs.

UPDATE will come if/when I find or create a usable solution