drop user u1

出现如下错误：

Msg 15136, Level 16, State 1, Line 1

The database principal is set as the execution context of one or more procedures, functions, or event notifications and cannot be dropped.

执行如下语句

select *from sys.sql_modules where execute_as_principal_id=database_principal_id('u1')

删除/修改 结果集中的存储过程

第一个错误概念是SQLSERVER会对登录密码进行加密，然后储存起来。这是错误的。SQLSERVER存储的是经过HASH后的密码。HASH和加密的不同之处在于其难于反向破解--但是对于加密算法而言，只要掌握密钥就可以轻易获得明文。从HASH后的字符中找出原始明文是非常困难的（除非你已经知道了明文）。不选择加密而选择HASH的优点是无需保护密钥（参见之前的文章）。那么SQLSERVER是如何处理登录密码的呢？登录时，首先对用户提交的密码进行HASH处理，然后和SQLSERVER存储的HASH后的密码进行比较。如果匹配，则登录成功。当然，你也可以使用一个错误的密码成功登陆SQLSERVER，只要HASH后的文本和原始密码的HASH值一致即可。但找出这样一个不同的密码是非常困难的（比中乐透要难多了）。同时也要记住，这种算法的强度也依赖于密码自身是否难猜。

那么怎样去破解登录密码呢？主要的方法就是建立一个集合（通常叫做字典），该集合内包含可能和登录密码匹配的文本，然后依次尝试集合中的所有文本，直到成功匹配。字典可以包含日期，各种语言的名词，数字或特殊字符等等。因此，保护密码的主要方法就是尽量选择一个不会出现在字典内的文本作为密码。如果你想选择一个好的密码，可以搜索关键字"how to choose a password"，你会找到许多很好的建议。即使你认为你已经选择了一个好的密码，你也应该浏览这些内容-----你也许会发现你的密码并没有想象中的那么“强壮”

边注：一些文档将HASH称之为“难以逆转的加密”，我不同意这种观点。我觉得“不可逆转的加密”本身就很矛盾，因为加密中的“逆转”是指找到合适的解密密钥。

第二个错误的概念是：SQLSERVER所用的HASH算法是MS内部开发的。我要阐述一下关于SQLSERVER算法的历史，但是之前我要声明：这是错误的。SQLSERVER从2000开始使用SHA1算法，6.5本版和7.0版本使用的算法为Snefru。关于6.5版本之前的情况我并不清楚，因为我是在SQLSERVER6.5加入的。

接下来是对6.5及以后本版的的概述。在6.5版本中，密码只能是ASCII字符，因此Snefru算法也只应用于ASCII字符。在7.0版本中，Unicode字符也可以作为密码，因此Snefru算法也应用到了Unicode字符。这是6.5和7.0中的主要不同。在2000版本中，使用的HASH算法改为SHA1,但也向后兼容。SQLSERVER会保存经过HASH后的密码，同时也会保留一份将密码转换成大写形式的HASH后的文本，这样就允许大小写不敏感的密码。David Litchfield 的写过一篇长，批评了这个问题。 有一点非常重要：大小写不敏感的HASH更容易被破解，因为这减小了字典的大小。 基于此原因，SQLSERVER2005没有采用大小写不敏感的的做法，这样更有利于安全。SQLSERVER2005中的另一个改变是删除了一些系统视图，HASH后的密码只对sysadmin可见。

在应用中，很少会使用到HASH后的密码。HASH变化后的密码主要应用于CREATE LOGIN DDL和SP2后ALTER LOGIN DDL中。 除非万不得已，最好不要使用HASH后的密码。只有在下面的场景中应使用HASH密码：应用程序需要在各个服务器间使用相同的密码。 CREATE LOGIN DLL可以应用于SQLSERVER7.0,2000和2005中，并在2005中支持HASH选项；而ALTER LOGIN DDL只在2000及2005中使用。请注意，SQLSERVER2005不再支持SQLSERVER6.5里的HASH。SQLSERVER2000中对大小写不敏感的特性也在2005中移除。如果将SQLSERVER从7.0升级到2005，其秘密存储的格式会在以下任意情况发生时转换到SQLSERVER2005的格式：登录成功或者成功改变密码（当指定了OLD_PASSWORD）

原文地址：SQL Server 2005: About login password hashes

虽然SHA1早已经被破解了，但是理解SQLSERVER密码的存储方式仍然非常重要。因此我翻译此文，希望对您有所帮助

4:19 PM 8/11/2008

两个KB:

如何在 SQL Server 2005 实例之间传输登录和密码

如何在 SQL Server 实例之间传输登录和密码

在许多情况下，为了执行操作系统中的操作，人们开启了xp_cmdshell，并且授权那些非sysadmin角色的帐户可以去调用xp_cmdshell，但并没有认识到这些用户可以执行任意命令，在某些情况下，这些用户可以通过xp_cmdshell将自己加入到sysadmin角色甚至提升为windows的管理员.很明显，这并不是我们想要的. Xp_cmdshell非常难控制，即使对它的使用进行了监测，也仍然会让攻击者在被逮住之前大用特用，而那时破坏可能已经发生了。

一般来讲，你绝对要避免使用xp_cmdshell，如果可能，你应该将其应用与其脱离。比较好的方式可能是使用CLR，在开发人员可控的范围内创建一个可以执行”外部访问/不安全”（external access/unsafe）操作的程序集(最好使用数字签名来建立信任)来执行需要的操作。优点如下：

·         除了外部/不安全的信任机制（也就是通过签名）的优点，该方法还不依赖于服务器设置

·         sysadmin可以在需要时撤销这种信任关系而不会影响其他应用。

·         更好的粒度控制和孤立性

但是请记住CLR并不能解决所有的问题. 如果要给予应用程序（该程序会以SQLSERVER启动账户的身份或者OS上的特权用户的身份执行执行操作）一定程度的信任，你要确保应用程序编码良好的，没有其他安全漏洞（例如代码注入，buffer溢出等等），并且是可控（也就是，不允许随意任意的命令或者打开系统中的文件等等）

 如果数据库管理员不希望用户在SQLSERVER中使用CLR而将其禁用，可以使用其他的方式，创建一个T-SQL的存储过程，里面含有需要在操作系统上调用的命令，然后通过Execute as或者数字签名来暂时将调用者提升为sysadmin.使用这种方法是请确保不要有用户输入 （例如为调用命令而使用参数）；或者如果你需要使用输入参数的命令，确保对输入进行验证

我列出一些和SQL CLR，数字签名有关的链接，希望这些信息能够对你有所帮助

·         TRUSTWORTHY Database property

·         Security Considerations for Databases and Database Applications

·         Permissions Hierarchy

·         Understanding Context Switching

·         Execute As

·         Extending Database Impersonation using Execute As

·         Module Signing

·         CREATE ASSEMBLY

·         Creating an Assembly

非常感谢Byham, Laurentiu Cristofor, Ruslan Ovechkin, Jack Richins 和 Sameer Tejani的帮助

原文地址：http://blogs.msdn.com/sqlsecurity/archive/2008/01/10/xp-cmdshell.aspx 

下面是示例代码

原文地址：http://blogs.msdn.com/lcris/archive/2006/01/13/sql-server-2005-example-for-how-to-allow-a-user-to-encrypt-but-not-decrypt.aspx

SQLSERVER 2005提供的对存储过程签名(signature)功能是我最喜欢的。

如果我们要编写一个存储过程,执行该存储过程里的代码需要权限P,并且我们想要用户Alice可以执行这个存储过程，但是我们不想将权限P直接赋予给用户Alice， 我们可以用证书(certificate)对这个存储过程进行签名来完成这一需求：

a)      如果P是一个数据库级别的权限，那我们可以在相应的数据库中创建一个证书，使用证书创建一个用户(user)，然后将权限p授权给这个用户

b)      如果P是一个服务器级别的权限，那我们能要在master数据库中创建一个证书，使用证书创建一个登录(login)，然后将权限P授权给这个登录

  签名之后，存储过程就会在执行期间获得权限P，而我们仅仅授予了Alice执行这个存储过程的权限。

     如果我们既需要服务器级别的权限，又需要数据库级别的权限，那么我们既要创建用户，又要创建登录。下面列出步骤：

1)      在数据库中创建证书

2)      创建一个用户(user)并映射到这个证书

3)      将数据库级别的权限授予这个用户

4)      备份这个证书

5)      在master数据库中还原这个证书

6)      创建一个登录(login)，并将登录映射到证书

7)      将服务器级别的权限授予给这个登录

  我们也可以先在master数据库中创建证书，然后再将其还原到用户alice工作的数据库。也就是证书的创建顺序并不重要，重要的是master数据库中的证书一定要和用户数据库中的相同。

下面是演示：

-- 目的
-- 展示如何用证书签名一个存储过程, 
--并授予证书相应的权限

 

create database demo;

use demo;

 

-- 创建一个存储过程，该过程会创建一个主体（包含登录和用户）
-- 这需要服务器级别的ALTER ANY LOGIN 权限
-- 和数据库级别的 ALTER ANY USER 权限
create procedure sp_CreatePrincipal
      @name varchar(256),
      @password varchar(128)
as
   declare @sqlcmd varchar(2000);

 

   begin tran;

 

   -- create login
   set @sqlcmd = 'create login ' + quotename(@name) + ' with password = ' + quotename(@password, '''');
   exec (@sqlcmd);
   if @@error <> 0

   begin

      rollback tran;
      print 'Cannot create login'
      return;
   end

 

   -- create user
   set @sqlcmd = 'create user ' + quotename(@name);
   exec (@sqlcmd);
   if @@error <> 0
   begin
      rollback tran;
      print 'Cannot create user'
      return;
   end

 

   commit tran;
go

 

-- 调用这个存储过程
-- 创建主体
sp_CreatePrincipal 'alice', 'Apufe@))%';

 

--我们需要让alice可以调用这个存储过程，创建新的主体， 
-- 但并不直接授予她权限（创建主体的权限，译者注）
grant execute on sp_CreatePrincipal to alice;

 

-- 目前 alice还不能创建主体
execute as login = 'alice';
sp_CreatePrincipal 'bob', 'Apufe@))%';
revert;

 

-- 使用证书对存储过程进行签名
-- 首先我们要创建一个数据库主密钥（database master key）
create master key encryption by password = 'Apufe@))%';
create certificate certSignCreatePrincipal with subject = 'for signing procedure sp_CreatePrincipal';

 

-- 签名存储过程sp_CreatePrincipal
add signature to sp_CreatePrincipal by certificate certSignCreatePrincipal;

-- 现在签名完成了，可以将证书的私钥移除了
alter certificate certSignCreatePrincipal remove private key;

-- 对证书进行备份，随后在master数据库中将要使用该备份
backup certificate certSignCreatePrincipal to file = 'certSignCreatePrincipal.cer';

 

-- 创建一个用户并将用户映射到证书
create user u_certSignCreatePrincipal from certificate certSignCreatePrincipal;
--通过授权映射映射的方式将ALTER ANY USER权限赋给证书  （因为用户和证书是映射的，所以权限也就赋给了证书，SQLSERVER本身没有直接将权限赋给证书的方法。译者注）
grant alter any user to u_certSignCreatePrincipal;

 

-- 在master数据库中创建该证书
use master;
create certificate certSignCreatePrincipal from file = 'certSignCreatePrincipal.cer';

-- 创建登录并映射到证书
create login l_certSignCreatePrincipal from certificate certSignCreatePrincipal;
-- 通过授权映射登录的方式将ALTER ANY LOGIN权限赋给证书
grant alter any login to l_certSignCreatePrincipal;

 

-- 完成！
use demo;

 

-- 验证一下，master数据库中的证书和demo数据库中的证书是一样的。
select c.name from sys.certificates c, master.sys.certificates mc where c.thumbprint = mc.thumbprint;

 

-- 现在alice可以创建主体了
execute as login = 'alice';
sp_CreatePrincipal 'bob', 'Apufe@))%';
revert;

 

-- cleanup
drop user u_certSignCreatePrincipal;
drop login l_certSignCreatePrincipal;
drop procedure sp_CreatePrincipal;
drop certificate certSignCreatePrincipal;
drop user alice;
drop login alice;
drop user bob;
drop login bob;

 

use master;

drop certificate certSignCreatePrincipal;
drop database demo;
-- EOD

原文： SQL Server 2005: procedure signing demo