Switching context with using EXECUTE AS ... not always switch it in fact as you wish.

Igor Kovalenko — Thu, 01 Mar 2007 11:23:00 GMT

In this demo i will try to explain why SET TRUSTWORTHY ON on some databases may make the sysadmin job unsafe. In previous posts i explained how db owner (or any developer) can try to implemet simplest luring attack against server sysadmin. According to BOL to avoid this problem sysadmin should switch to the context of the account/login with lowest possible privileges. Lets try to test this approach.

USE master
GO

-- create test database
CREATE DATABASE [TestDB] ON PRIMARY ( NAME = N'TestDB', FILENAME = N'C:\TestDB.mdf', SIZE = 3072KB, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'TestDB_log', FILENAME = N'C:\TestDB_log.ldf', SIZE = 1024KB, FILEGROWTH = 10%)
GO

-- set option
EXEC dbo.sp_dbcmptlevel @dbname=N'TestDB', @new_cmptlevel=90
GO

-- first time test with TRUSTWORTHY = OFF

ALTER DATABASE [TestDB] SET TRUSTWORTHY OFF
GO

-- create login Test
USE [master]
GO
CREATE LOGIN [Test] WITH PASSWORD=N'111', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

USE [TestDB]
GO

-- create user test
CREATE USER [Test] FOR LOGIN [Test]
GO

-- create test DDL trigger - fired on any DENY event
CREATE TRIGGER [ddl_test_trigger]
ON DATABASE
FOR DENY_DATABASE
AS

SET NOCOUNT ON

IF IS_SRVROLEMEMBER ('sysadmin') = 1
PRINT 'Sysadmin found, security can be broken easily.'
ELSE
PRINT 'Sysadmin not found, you are in safe.'

GO

-- test under sysadmin (sa) account
DECLARE @cmd nvarchar(1000)

SET @cmd = 'DENY BACKUP DATABASE TO [Test]'
EXEC (@cmd)
GO

-- you'll see "Sysadmin found, security can be broken easily."

-- so the next step according to BOL - switch to lowest privileges context for desired operation
DECLARE @cmd nvarchar(1000)
SET @cmd = 'DENY BACKUP DATABASE TO [Test]'
EXEC (@cmd) AS USER = 'dbo'
GO

-- you'll see now "Sysadmin not found, you are in safe."
-- Thats is our desired goal - to be in safe. Lets try to set TRUSTWORTHY ON

ALTER DATABASE [TestDB] SET TRUSTWORTHY ON
GO

-- try again the "safe" version
DECLARE @cmd nvarchar(1000)
SET @cmd = 'DENY BACKUP DATABASE TO [Test]'
EXEC (@cmd) AS USER = 'dbo'
GO

-- you'll see again "Sysadmin found, security can be broken easily."

-- clear objects
USE Master
GO

DROP DATABASE [TestDB]
GO

DROP LOGIN [Test]
GO

--------------------------------------------------------

As as result of this demo i would recommend you do not use TRUSTWORTHY ON on your databases. Otherwise before making any
changes under 'sa' account in unknown databases please check TRUSTWORTHY setting for the database you are
working with, because simple EXECUTE AS .... (even with cookie) will not protect you from loosing you privileges or
GRANT 'sa' privileges to everybody (as explained in my previous articles). And be always in safe :-).

--------------------------------------------------------

ALTER DATABASE ... ALTER COLLATION (FORCED).

Igor Kovalenko — Sun, 03 Dec 2006 01:29:00 GMT

As all of you know Microsoft has made a small problem for all SQL DBA and developers. If you have a database with any of SQL_xxxxx collations (for more details please have a look at the TERTIARY_WEIGHTS() function here), you will defenetily have a significant problem with index search and ordering performance if you'll try to upgrade your SQL Server with 2005 version. Some of developers was excited when first time reading this article, really :-).

Suddenly ALTER DATABASE .. ALTER COLLATION command will change database collation for you, but all objects will stay "as is" with old collation (by design). The only way to change collation for all existing objects is to create a new empty database with new desired collation and copy data into this new database (copy wizzard, for example).

To sort this issue out i created this small script (in attachment). It was tested both manually and with using VSTS DBPro, and i can confirm that you can change the collation of your database without any problem and manual work. As an input you should provide it with database with one collation, and as output you will have the same database with another (desired) collation. So as for me this is an analoque of ALTER DATABASE ... ALTER COLLATION FORCED command :-). How it works:

- you should use sqlcmd or SSMS in sqlcmd mode,

- specify database name as a parameter,

- specify desired collation as a parameter,

- run it and wait for results.

What is not covered by the script: table and index partitioning. I guess that if you are using these advanced options, you are smart enough to change this script to add required feature. Mostly i created this script for the following scenario: (1) detach database from SQL Server 6.5/7.0/200 version; (2) attach it to SQL Server 2005; (3) run this script; (4) use your database asap.

Some words about performance: than more tables with computed columns (computed column not at the end of the table) you have than more time you will have to wait. 100 Gigabyte db can be easily transformed within one hour on AI64 4way with EVA8000.

Also it is possible to use this script to study SQL 2005 system views and relationship between them.

Many thanks for any reply and comments.

---- January 2008

Many thanks to WaitForPete, script updated to fix these (and some other) issues.

SQL, Analysis Services & related stories. : SQL Server Administration

Switching context with using EXECUTE AS ... not always switch it in fact as you wish.

ALTER DATABASE ... ALTER COLLATION (FORCED).