SQL Server 数据库身份认证以及包含数据库

首先分为SQL Server 认证与Windows 身份认证。

 

SQL Server 认证可以运行以下语句来查询

select * from sys.sql_logins

管理员可以直接修改密码，但无法知晓原有密码原文，SQL Server使用混淆算法来保护安全性不如Windows 身份认证，

 

Windows认证模式

首先分为本机账号与域账号

 

SQL Server 将认证和授权分散给了不同的对象来完成，SQL Server 的“登入名”（Login）用于认证，连接SQL Server 的SQL或者Windows 账户必须在SQL Server中有对应的登入名才能成功登入。

而每个数据库中的“用户”（User）被授予了操作数据库中对象的相应权限。登入名和用户之间通过SID联系起来，于是登入SQL Server 的登入名也获得了操作数据库的相应权限。

这个机制带来以下两个问题：

1.提高了高可用解决方案的维护成本。msdb（系统数据库）无法被镜像。类似制作数据库镜像系统，就需同时在主体和镜像服务器上的添加同样的用户名密码，否则发生故障转移，镜像服务就无法使用新的登入名进行登入。另外，在镜像服务器上添加登入名时要确保和主体服务器上的登入名使用相同的SID，否则就会破坏登入名到数据库用户之间的对应关系。成为所谓的孤立账户。

2.增加了迁移数据库的复杂性。不能仅仅简单地迁移用户数据数据库和程序。因为还有一部分和应用相关的对象遗漏在用户数据库之外，其中包括登入名。在迁移应用的时候，登入名需被单独的从老的环境中提取出来，在部署到新的环境上。

 

孤立账户解决参考以下链接

http://www.cnblogs.com/kerrycode/p/3465547.html

 

 

前提是数据库兼容级别110以上，即2012以上。包含数据库创建。。

EXEC sys.sp_configure N'contained database authentication', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO

修改[AdventureWorks2012]为包含数据库

USE [master]
GO
ALTER DATABASE [AdventureWorks2012] SET CONTAINMENT = PARTIAL WITH NO_WAIT
GO

查询实例中所有的包含数据库

use master
select * from sys.databases
where containment >0

  将现有的数据库用户改为包含数据库用户

USE [AdventureWorks2012]
GO
DECLARE @username SYSNAME;
DECLARE user_cursor CURSOR
FOR
    SELECT  dp.name
    FROM    sys.database_principals AS dp
            JOIN sys.server_principals AS sp ON dp.sid = sp.sid
    WHERE   dp.authentication_type = 1
            AND sp.is_disabled = 0;
OPEN user_cursor
FETCH NEXT FROM user_cursor INTO @username
WHILE @@FETCH_STATUS = 0
    BEGIN
        EXECUTE sp_migrate_user_to_contained @username = @username,
            @rename = N'keep_name', @disablelogin = N'disable_login';
        FETCH NEXT FROM user_cursor INTO @username
    END
CLOSE user_cursor;
DEALLOCATE user_cursor;