博客园_我思故我在我有我精彩--liangqihui

word替换回车替换换行替换空格

2012-02-17T08:09:00Z

1.把段落末的向下的“箭头”（Htm中的软回车符）改成word中的段落标记符（Htm中的硬回车符）

编辑－－－替换－－－－点高级，点特殊符号那项,“替换”里选那个手工换行符（从下数第五个吧），“替换为”里选第一个，段落标记，然后全部替换！！搞定～也可以直接填^l和^p,分别对应软回车和硬回车~

2.网上下的文一般中间都空一行或几行，也可以用替换，不过要在第一栏里输（选）两次^l^l，第二栏选^p，或第一栏两次^p^p，第二栏一次^p，这是去一行空格的做法，多去几行我就不唠叨了～呵呵，至于为什么大家都知道吧？？：）

本文链接

[ZT]C# 代码实现设置用户"NETWORK SERVICE"具有对文件夹的读取权限。

2012-01-13T00:52:00Z

设置用户"NETWORK SERVICE"具有对文件夹的读取权限。

原帖地址： http://www.cnblogs.com/sjhrun2001/archive/2009/03/18/1415804.html

1 System.Security.AccessControl.DirectorySecurity fSec;
2
3 string path = "D:\\Test";
4 fSec = new DirectorySecurity();
5 //设置权限的应用为文件夹本身、子文件夹及文件
6 //所以需要InheritanceFlags.ContainerInherit 或 InheritanceFlags.ObjectInherit
7 fSec.AddAccessRule(new FileSystemAccessRule("NETWORK SERVICE", FileSystemRights.Read, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, AccessControlType.Allow));
8 System.IO.Directory.SetAccessControl(path, fSec);
9

顺便提一下，NETWORK SERVICE是IIS6.0的默认用户，而ASPNET是IIS5.0的默认用户。
有一个问题：NETWORK SERVICE在Window2003的电脑管理/用户里面并没有这个用户。

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

原文：

http://www.cnblogs.com/leosky2008/archive/2007/08/08/847405.html

在文件操作中,常常会遇到对所访问的文件夹没有权限的错误,下面介绍C#中怎么设置文件夹的权限:

1/// <summary>
2        /// 为创建的临时文件分配权限
3        /// </summary>
4        /// <param name="pathname"></param>
5        /// <param name="username"></param>
6        /// <param name="power"></param>
7        /// <remarks>SKY 2007-8-6</remarks>
8        public void addpathPower(string pathname, string username, string power)
9        {
10
11            DirectoryInfo dirinfo = new DirectoryInfo(pathname);
12
13            if ((dirinfo.Attributes & FileAttributes.ReadOnly) != 0)
14            {
15                dirinfo.Attributes = FileAttributes.Normal;
16            }
17
18            //取得访问控制列表
19            DirectorySecurity dirsecurity = dirinfo.GetAccessControl();
20
21            switch (power)
22            {
23                case "FullControl":
24                    dirsecurity.AddAccessRule(new FileSystemAccessRule(username, FileSystemRights.FullControl, InheritanceFlags.ContainerInherit, PropagationFlags.InheritOnly, AccessControlType.Allow));
25                    break;
26                case "ReadOnly":
27                    dirsecurity.AddAccessRule(new FileSystemAccessRule(username, FileSystemRights.Read, AccessControlType.Allow));
28                    break;
29                case "Write":
30                    dirsecurity.AddAccessRule(new FileSystemAccessRule(username, FileSystemRights.Write, AccessControlType.Allow));
31                    break;
32                case "Modify":
33                    dirsecurity.AddAccessRule(new FileSystemAccessRule(username, FileSystemRights.Modify, AccessControlType.Allow));
34                    break;
35            }
36        }

DirectoryInfo是需要实例化的,而且实例化的时候必须指定文件夹路径,Directory则是静态类.

主程序中调用的写法:

1private void CreateDirectory()
2{
3
4   addpathPower(sPath, "ASPNET", "FullControl");
5
6}

一般来说
Username 选用 ASPNET

------------------------------------
这几天由于工作需要，需要用C#开发一个设置文件夹共享，并为共享的文件夹设置共享权限的功能。在开发过程中发现了一些有趣的问题，
就是如果用程序的方式创建一个共享目录，那么就是无法直接用程序的方式设置它的共享权限。更为奇怪的是如果手动去改下下共享权限（改前和改后的设置都一样），
就可以以程序的方式设置共享权限了。
这里我贴出创建共享目录的代码
/// <summary>
        /// 共享目录
        /// </summary>
        /// <param name="folderPath">目录地址</param>
        /// <param name="shareName">共享名称</param>
        /// <param name="description">描述</param>
        /// <param name="tempShareName">临时共享目录</param>
        /// <param name="returnMsg">返回消息</param>
        /// <returns></returns>
public static bool ShareFolder(string folderPath, string shareName, string description, out string returnMsg)
        {
            bool bRet = false;
            try
            {
                returnMsg = "";
                if (Directory.Exists(folderPath))
                {
                    ManagementBaseObject oSecurityDescriptor = GetSecurityDescriptorFromBinary(user);
                    ManagementClass oManagementClass = new ManagementClass("Win32_Share");
                    ManagementBaseObject oInParams = oManagementClass.GetMethodParameters("Create");
                    ManagementBaseObject oOutParams = null;
                    oInParams["Description"] = description;
                    oInParams["Name"] = shareName;
                    oInParams["Path"] = folderPath;
                    oInParams["Type"] = DISK_DRIVE;
                    oInParams["Access"] = null; //默认的共享权限是Everyone
/*
如果oInParams["Access"] 不设置或者设置为null，你就会奇怪的发现，当你先要用程序再去设置共享权限时就不行了（xp和2003下，win7,win2008缺可以）
*/
                    oOutParams = oManagementClass.InvokeMethod("Create", oInParams, null);
                    if ((uint)(oOutParams.Properties["ReturnValue"].Value) != 0)
                    {
                        returnMsg = string.Format("无法共享目录[{0}]！", folderPath);
                    }
                    else
                    {
                        bRet = true;
                    }
                }
                else
                {
                    returnMsg = string.Format("不存在目录[{0}]！", folderPath);
                }
            }
            catch (Exception ex)
            {
                returnMsg = ex.Message;
            }
            return bRet;
        }
设置权限的普通方法：
/// <summary>
        /// 设置共享目录的共享权限
        /// </summary>
        /// <param name="folderPath">共享目录名</param>
        /// <param name="user">共享权限用户</param>
        /// <param name="returnMsg">返回消息</param>
        /// <returns></returns>
        public static bool SetPermission(string shareName, string user, out string returnMsg)
        {
            bool bRet = false;
            returnMsg = "";
            //判断用户是否存在
            if (!IsUserExists(user))
            {
                returnMsg = string.Format("用于[{0}]不存在", user);
                return bRet;
            }
            // Step 1 - Getting the user Account Object
            string sShareName =shareName;
            ManagementObject oShareSecuritySetting= null;
            ManagementObjectSearcher oSearcher = new ManagementObjectSearcher("Select * from Win32_LogicalShareSecuritySetting where Name = '" + sharedName + "'");
            //ManagementObjectSearcher oSearcher = new ManagementObjectSearcher("Select * from Win32_LogicalShareSecuritySetting");
            ManagementObjectCollection oResultOfSearch = oSearcher.Get();
            if (oResultOfSearch.Count > 0)
            {
                //The search might return a number of objects with same shared name. I assume there is just going to be one
                foreach (ManagementObject sharedFolder in oResultOfSearch)
                {
    oShareSecuritySetting= sharedFolder;
                    break;
                }
            }
            if (oShareSecuritySetting!= null)
            {
                ManagementBaseObject oSecurityDescriptorObject = oShareSecuritySetting.InvokeMethod("GetSecurityDescriptor", null, null);
                if (oSecurityDescriptorObject != null)
                {
                    if ((uint)(oSecurityDescriptorObject.Properties["ReturnValue"].Value) == 0)
                    {
                        ManagementBaseObject oSecurityDescriptor = oSecurityDescriptorObject.Properties["Descriptor"].Value as ManagementBaseObject;
                        // Step 2 -- Access Control List from the security descriptor
                        int iExistingAcessControlEntriesCount = 0;
                        ManagementBaseObject[] oAccessControlList = oSecurityDescriptor.Properties["DACL"].Value as ManagementBaseObject[];
                        if (oAccessControlList != null)
                        {
                            // Otherwise, resize the list to allow for all new users.
                            iExistingAcessControlEntriesCount = oAccessControlList.Length;
                            Array.Resize(ref oAccessControlList, oAccessControlList.Length + 1);
                        }
                        else
                        {
                            // If there aren't any entries in access control list or the list is empty - create one
                            oAccessControlList = new ManagementBaseObject[1];
                        }
                        // Step 3 - Getting the user Account Object
                        string sUserDomain = Environment.UserDomainName;
                        ManagementObject oUserAccountObject = GetUserAccountObject(sUserDomain, user);
                        ManagementObject oSecurityIdentfierObject = new ManagementObject(string.Format("Win32_SID.SID='{0}'", (string)oUserAccountObject.Properties["SID"].Value));
                        oSecurityIdentfierObject.Get();
                        // Step 4 - Create Trustee Object
                        ManagementObject oTrusteeObject = CreateTrustee(sUserDomain, user, oSecurityIdentfierObject);
                        // Step 5 - Create Access Control Entry
                        ManagementObject oAccessControlEntry = CreateAccessControlEntry(oTrusteeObject, false);
                        // Step 6 - Add Access Control Entry to the Access Control List
                        oAccessControlList[iExistingAcessControlEntriesCount] = oAccessControlEntry;
                        // Step 7 - Assign access Control list to security desciptor
                        oSecurityDescriptor.Properties["DACL"].Value = oAccessControlList;
                        // Step 8 - Assign access Control list to security desciptor
                        ManagementBaseObject oParameterForSetSecurityDescriptor = oSharedFolder.GetMethodParameters("SetSecurityDescriptor");
                        oParameterForSetSecurityDescriptor["Descriptor"] = oSecurityDescriptor;
                        oShareSecuritySetting.InvokeMethod("SetSecurityDescriptor", oParameterForSetSecurityDescriptor, null);
                        bRet = true;
                    }
                    else
                    {
                        returnMsg = string.Format("共享目录[{0}]的安全描述符(SecurityDescriptorObject)的返回值错误！", sShareName);
                    }
                }
                else
                {
                    returnMsg = string.Format("无法获取共享目录[{0}]的安全描述符(SecurityDescriptorObject)", sShareName);
                }
            }
            else
            {
                returnMsg = string.Format("无法获取共享目录[{0}]的共享安全设置！", sShareName);
            }
            return bRet;
        }
    /// <summary>
        /// 获取账户对象
        /// </summary>
        /// <param name="domain">用户的域名</param>
        /// <param name="alias">用户名称别名</param>
        /// <returns></returns>
        private static ManagementObject GetUserAccountObject(string domain, string alias)
        {
            ManagementObject oUserAccountObject = null;
            ManagementObjectSearcher oSearcher = new ManagementObjectSearcher(string.Format("select * from Win32_Account where Name = '{0}' and Domain='{1}'", alias, domain));
            ManagementObjectCollection oResultOfSearch = oSearcher.Get();
            if (oResultOfSearch.Count > 0)
            {
                foreach (ManagementObject userAccount in oResultOfSearch)
                {
                    oUserAccountObject = userAccount;
                    break;
                }
            }
            return oUserAccountObject;
        }
        /// <summary>
        /// 创建指定用户的信任项
        /// </summary>
        /// <param name="domain">域名</param>
        /// <param name="userName">用户名</param>
        /// <param name="securityIdentifierOfUser">用户的权限标识</param>
        /// <returns></returns>
        private static ManagementObject CreateTrustee(string domain, string userName, ManagementObject securityIdentifierOfUser)
        {
            ManagementObject oTrusteeObject = new ManagementClass("Win32_Trustee").CreateInstance();
            oTrusteeObject.Properties["Domain"].Value = domain;
            oTrusteeObject.Properties["Name"].Value = userName;
            oTrusteeObject.Properties["SID"].Value = securityIdentifierOfUser.Properties["BinaryRepresentation"].Value;
            oTrusteeObject.Properties["SidLength"].Value = securityIdentifierOfUser.Properties["SidLength"].Value;
            oTrusteeObject.Properties["SIDString"].Value = securityIdentifierOfUser.Properties["SID"].Value;
            return oTrusteeObject;
        }
        /// <summary>
        /// 创建指定用户的访问控制项（Access Control Entry）对象
        /// </summary>
        /// <param name="trustee">用户的信任项对象</param>
        /// <param name="deny">用户权限是拒绝还是允许</param>
        /// <returns></returns>
        private static ManagementObject CreateAccessControlEntry(ManagementObject trustee, bool deny)
        {
            ManagementObject oAceObject = new ManagementClass("Win32_ACE").CreateInstance();
            oAceObject.Properties["AccessMask"].Value = 0x1U | 0x2U | 0x4U | 0x8U | 0x10U | 0x20U | 0x40U | 0x80U | 0x100U | 0x10000U | 0x20000U | 0x40000U | 0x80000U | 0x100000U; // all permissions
            oAceObject.Properties["AceFlags"].Value = 0x0U; // no flags
            oAceObject.Properties["AceType"].Value = deny ? 1U : 0U; // 0 = allow, 1 = deny
            oAceObject.Properties["Trustee"].Value = trustee;
            return oAceObject;
        }
        /// <summary>
        /// 检查用户是否存在
        /// </summary>
        /// <param name="user"></param>
        /// <param name="returnMsg"></param>
        /// <returns></returns>
        public static bool IsUserExists(string userName)
        {
            bool bRet = false;
            DirectoryEntry oLocalMachine = null;
            DirectoryEntry oNewUser = null;
            try
            {
                oLocalMachine = new DirectoryEntry("WinNT://" + Environment.MachineName);
                oNewUser = oLocalMachine.Children.Find(userName, "user");
                bRet = true;
            }
            catch
            {
                bRet = false;
            }
            return bRet;
        }
运行代码上面这段代码时你会发现
ManagementObject oShareSecuritySetting= null;
            ManagementObjectSearcher oSearcher = new ManagementObjectSearcher("Select * from Win32_LogicalShareSecuritySetting where Name = '" + sharedName + "'");
            ManagementObjectCollection oResultOfSearch = oSearcher.Get();
            if (oResultOfSearch.Count > 0)
            {
                //The search might return a number of objects with same shared name. I assume there is just going to be one
                foreach (ManagementObject sharedFolder in oResultOfSearch)
                {
    oShareSecuritySetting= sharedFolder;
                    break;
                }
            }
这句代码片段是无法找到有效的oShareSecuritySetting。但是实际情况是文件夹是共享的而且有一个默认的Everyone的共享权限。这是为啥我找了很久也没答案。
鉴于无法获取oShareSecuritySetting这个“Win32_LogicalShareSecuritySetting”对象，下一步的权限设置也没法做了。
其实获取这个对象的最终目的是为了获取下面这个对象
ManagementBaseObject oSecurityDescriptor = oSecurityDescriptorObject.Properties["Descriptor"].Value as ManagementBaseObject;
这就头疼了，这些功能代码的目的就是为了使用程序去设置共享及共享权限，如果需要手动去设置下权限那不是有点隔靴搔痒了。
最后实在没办了，我只能想了个笨办法。既然手动创建的共享目录能够获取oSecurityDescriptor 这个对象，那能不能我把这个对象保存下来能，应为只要有了
oSecurityDescriptor这个对象，就可以在这个对象了设置我们自己想要的用户权限了，设置方法上面的代码中有例子的。
最后想出来办法是用.net的序列化方法去序列化一个实现获取到的oSecurityDescriptor对象，把这个对象保存在一个文件里，下次在进行反序列化获取这个对象。
需要注意一点的是。无法获取oShareSecuritySetting只会发生在第一次创建共享目录的时候（注意：使用代码创建的），如果第一次为这个共享目录设置了共享权限，那么下次次再设置权限就没有障碍了。烦啊。。。
好了，还是说序列化吧，如下代码：
private static void ObjectSerialize(object serObj)
        {
            using (FileStream oFileStream = new FileStream(@"C:\LogicalShareSecuritySetting.dat", FileMode.Create))
            {
                BinaryFormatter oFormatter = new BinaryFormatter();
                oFormatter.Serialize(oFileStream, serObj);
            }
        }
ObjectSerialize(oSecurityDescriptor);
这样就把这个对象永久保存在C:\LogicalShareSecuritySetting.dat这个文件里了，为了部署方便，我们可以把这个文件作为一个嵌入的资源嵌入在我们的程序中，下次我们就可以这样反序列化这个对象了：
private const string LOGICAL_SHARESECURITY_SETTING=“Namespace.LogicalShareSecuritySetting.dat”;
ManagementBaseObject oSecurityDescriptor= null;
            try
            {
                Assembly oAsm = Assembly.GetExecutingAssembly();
                using (Stream oStream = oAsm.GetManifestResourceStream(LOGICAL_SHARESECURITY_SETTING))
                {
                    BinaryFormatter oFormatter = new BinaryFormatter();
oSecurityDescriptor= oFormatter.Deserialize(oStream) as ManagementBaseObject;
                }
            }
            catch
            { }
一旦反序列化成功这个oSecurityDescriptor，我们就可以为这个对象赋值一个我们想要的用户权限啦，如下：
if (oSecurityDescriptor != null)
{
    ManagementBaseObject[] oAccessControlList = null;
    oAccessControlList = new ManagementBaseObject[1];
    // Step 3 - Getting the user Account Object
    string sUserDomain = Environment.UserDomainName;
    ManagementObject oUserAccountObject = GetUserAccountObject(sUserDomain, user);//这个user就是本地计算机的用户名，如Guest等。
    ManagementObject oSecurityIdentfierObject = new ManagementObject(string.Format("Win32_SID.SID='{0}'", (string)oUserAccountObject.Properties["SID"].Value));
    oSecurityIdentfierObject.Get();
    // Step 4 - Create Trustee Object
    ManagementObject oTrusteeObject = CreateTrustee(sUserDomain, user, oSecurityIdentfierObject);
    // Step 5 - Create Access Control Entry
    ManagementObject oAccessControlEntry = CreateAccessControlEntry(oTrusteeObject, false);
    // Step 6 - Add Access Control Entry to the Access Control List
    oAccessControlList[0] = oAccessControlEntry;
    // Step 7 - Assign access Control list to security desciptor
oSecurityDescriptor.Properties["DACL"].Value = oAccessControlList;
}
一旦设置成功了，那么我们返回第一段设置共享目录代码的地方，记得不记得这段代码
oInParams["Access"] = null; //默认的共享权限是Everyone
我们就可以吧获取的
oSecurityDescriptor设置给 oInParams["Access"] = oSecurityDescriptor了。
OK，大家有兴趣试试。如果有什么更好的方法，请一定告诉我哦。我期待有更好的方式解决这个问题。

本文链接

[ZT]用sqlserver的sqlcmd、osql、isql的备份与还原

2011-12-06T03:25:00Z

用sqlserver的sqlcmd、osql、isql的备份与还原

--sqlcmd ，sql2005新加工具
1、备份
"C:/Program Files/Microsoft SQL Server/90/Tools/Binn/SQLCMD.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"BACKUP DATABASE test to disk='c:/aa/aaa.bak'"

已为数据库 'test'，文件 'test' (位于文件 2 上)处理了 176 页。
已为数据库 'test'，文件 'test_log' (位于文件 2 上)处理了 1 页。
BACKUP DATABASE 成功处理了 177 页，花费 1.207 秒(1.201 MB/秒)。

2、还原
"C:/Program Files/Microsoft SQL Server/90/Tools/Binn/SQLCMD.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"RESTORE DATABASE test from disk='c:/aa/aaa.bak'"

3、帮助
C:/Documents and Settings/xuysh>"C:/Program Files/Microsoft SQL Server/90/Tools/
Binn/SQLCMD.EXE" -?
Microsoft (R) SQL Server 命令行工具
版本 9.00.1399.06 NT INTEL X86
版权所有 (c) Microsoft Corporation。保留所有权利。

用法: Sqlcmd            [-U 登录 ID]          [-P 密码]
[-S 服务器]            [-H 主机名]          [-E 可信连接]
[-d 使用数据库名称] [-l 登录超时值]     [-t 查询超时值]
[-h 标题]           [-s 列分隔符]      [-w 屏幕宽度]
[-a 数据包大小]        [-e 回显输入]        [-I 允许带引号的标识符]
[-c 命令结束]            [-L[c] 列出服务器[清除输出]]
[-q "命令行查询"]   [-Q "命令行查询" 并退出]
[-m 错误级别]        [-V 严重级别]     [-W 删除尾随空格]
[-u unicode 输出]    [-r[0|1] 发送到 stderr 的消息]
[-i 输入文件]         [-o 输出文件]         [-z 新密码]
[-f <代码页> | i:<代码页>[,o:<代码页>]] [-Z 新建密码并退出]
[-k[1|2] 删除[替换]控制字符]
[-y 可变长度类型显示宽度]
[-Y 固定长度类型显示宽度]
[-p[1] 打印统计信息[冒号格式]]
[-R 使用客户端区域设置]
[-b 出错时中止批处理]
[-v 变量 = "值"...] [-A 专用管理连接]
[-X[1] 禁用命令、启动脚本、环境变量[并退出]]
[-x 禁用变量情况]
[-? 显示语法摘要]

--Osql sql2000和sql2005都有
--1、备份
"C:/Program Files/Microsoft SQL Server/90/Tools/Binn/Osql.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"BACKUP DATABASE test to disk='c:/aa/aaa.bak'"

已为数据库 'test'，文件 'test' (位于文件 3 上)处理了 176 页。
已为数据库 'test'，文件 'test_log' (位于文件 3 上)处理了 1 页。
BACKUP DATABASE 成功处理了 177 页，花费 0.531 秒(2.730 MB/秒)。

2、还原
"C:/Program Files/Microsoft SQL Server/90/Tools/Binn/Osql.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"RESTORE DATABASE test from disk='c:/aa/aaa.bak'"

已为数据库 'test'，文件 'test' (位于文件 1 上)处理了 176 页。
已为数据库 'test'，文件 'test_log' (位于文件 1 上)处理了 2 页。
RESTORE DATABASE 成功处理了 178 页，花费 0.200 秒(7.255 MB/秒)。

3、帮助
C:/Documents and Settings/xuysh>"C:/Program Files/Microsoft SQL Server/90/Tools/
Binn/Osql.EXE" /?
Microsoft (R) SQL Server 命令行工具
版本 9.00.1399.06 NT INTEL X86
版权所有 (c) Microsoft Corporation。保留所有权利。

注意: osql 并不支持 SQL Server 2005的所有功能。
请使用 sqlcmd。有关详细信息，请参阅 SQL Server 联机丛书。

用法: osql                   [-U 登录 ID]          [-P 密码]
[-S 服务器]                [-H 主机名]           [-E 可信连接]
[-d 使用数据库名称]        [-l 登录超时值]       [-t 查询超时值]
[-h 标题]                  [-s 列分隔符]         [-w 列宽]
[-a 数据包大小]            [-e 回显输入]         [-I 允许带引号的标识符]
[-L 列出服务器]            [-c 命令结束]         [-D ODBC DSN 名称]
[-q "命令行查询"]          [-Q "命令行查询" 并退出]
[-n 删除编号方式]          [-m 错误级别]
[-r 发送到 stderr 的消息] [-V 严重级别]
[-i 输入文件]              [-o 输出文件]
[-p 打印统计信息]               [-b 出错时中止批处理]
[-X[1] 禁用命令，[退出的同时显示警告]]
[-O 使用旧 ISQL 行为禁用下列项]
      <EOF> 批处理
      自动调整控制台宽度
      宽消息
      默认错误级别为 -1 和 1
[-? 显示语法摘要]

--Isql ，sql2000工具，2005中没有
--1、备份
"C:/Program Files/Microsoft SQL Server/80/Tools/Binn/Isql.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"BACKUP DATABASE test to disk='c:/aa/aaa.bak'"

2、还原
"C:/Program Files/Microsoft SQL Server/80/Tools/Binn/Isql.EXE" -S ./sqlexpress -U sa -P 000000 -d master -Q"RESTORE DATABASE test from disk='c:/aa/aaa.bak'"

3、帮助
Microsoft Windows XP [版本 5.1.2600]
(C) 版权所有 1985-2001 Microsoft Corp.

C:/Documents and Settings/xuysh>"C:/Program Files/Microsoft SQL Server/80/Tools/
Binn/Isql.EXE"/?
isql: unknown option ?
usage: isql              [-U login id]          [-P password]
[-S server]            [-H hostname]          [-E trusted connection]
   [-d use database name] [-l login timeout]     [-t query timeout]
   [-h headers]           [-s colseparator]      [-w columnwidth]
[-a packetsize]        [-e echo input]        [-x max text size]
[-L list servers]      [-c cmdend]
[-q "cmdline query"]   [-Q "cmdline query" and exit]
[-n remove numbering] [-m errorlevel]
[-r msgs to stderr]
[-i inputfile]         [-o outputfile]
[-p print statistics] [-b On error batch abort]
[-O use Old ISQL behavior disables the following]
      <EOF> batch processing
      Auto console width scaling
      Wide messages
      default errorlevel is -1 vs 1
[-? show syntax summary (this screen)]

本文链接

运用PMI主义

2011-05-22T13:56:00Z

你是专业的项目经理，管理是你的核心职能（技术的实现细节是你需要注意的内容，但大多只需要深入到是可行性论证和成本控制水平，而不是要你在技术上舍本逐末，记住技术上再多的亮点永远也不能掩盖你在项目管理中体现出的无能）
必须以专业的方式做项目，即遵循PMBOK的要求
强调事业环境印务和组织过程资产
强调历史信息，强调经验教训总结，强调记录
问题重在预防，而非解决（虽然解决也很重要，但是它是最基本的，但是PMI体系在设计之初就强调需要根据经验和专业的科学手段尽可能的规避不必要的任何风险）
必须有明确的目标，必须有正是的计划，才可以行动
利害关系者很重要，尽早识别全部的厉害关系者（项目干系人）并让其参与
项目经理鼻息被任命，PM是管理工作的核心责任点
项目是系统工程，项目经理是整合者，多重约束需要牢记在心
项目管理以结果为导向，项目成功时项目经理的最终责任
变更影响项目成功，项目经理应该影响变更发生，管理变更
项目经理的主要责任是整合项目，整合通过沟通实现，项目经理要花费75%-90%的时间用于沟通
项目经理应该拒绝体统不重要的信息要求
必须详细秒速工作，责任必须明确
任何情况下，质量都要达到客户满意
削减费用的前提是削减项目范围，而不是牺牲质量
项目经理必须遵守公司规定，职业道德，法律
项目经理必须主动，不等不靠；无论环境如何，先尽自己的努力
一切决策必须以事实为依据，以程序为准绳，正确的程序优先于正确的结果
防止范围潜变，杜绝质量镀金，项目必须收尾
公正，公平，公开，勇敢，诚实地面对现实
处理各方关系时，都要本着双赢理念

《如何准备PMP考试》 ---机械工业出版社

本文链接

Kerberos 委派故障诊断

2011-05-20T07:38:00Z

Kerberos 委派故障诊断

发布日期： 2004年11月03日

下载

Kerberos_Delegation.doc

1524 KB
Microsoft Word
文件

本白皮书说明了如何对在 Kerberos 身份验证方案中可能出现的委派问题进行故障诊断。本白皮书总结了必需的基础结构，并描述了 Windows®
身份验证方案的例子。其中心内容是围绕四个故障诊断清单来组织的：Active Directory®
目录服务、客户端应用程序、中间层和后端各一个清单。附录中详细介绍了诊断工具，并给出了如何在典型的 IIS 到 SQL 委派方案中解决问题的例子。

本页内容

简介
基础结构的要求
Windows 身份验证方案
配置 Kerberos 委派
诊断委派问题：四个清单
总结
附录 A：诊断工具
附录 B：常见方案的配置示例
附录 C：网络监视器捕获到的网络记录的示例
附录 D：相关信息

简介

本白皮书讨论了对委派问题进行故障诊断的各种方法。由于通常 Kerberos 委派与 Internet 信息服务 (IIS) 和 SQL Server
一起使用，所以本白皮书在“附录 B”中详细介绍了 IIS/SQL 委派方案的例子。

本白皮书假定您已经了解 Kerberos 身份验证的工作原理。有关 Kerberos 协议和操作的更多信息，请参见：

•
Microsoft Windows Server 2003 技术参考，位于：http://go.microsoft.com/fwlink/?LinkId=21711
•
Microsoft 知识库中的“Windows 2000 中的 Kerberos 用户身份验证协议概述”，位于：http://go.microsoft.com/fwlink/?LinkId=24922

返回页首

基础结构的要求

Kerberos 身份验证的问题常常涉及到 Kerberos SSP 所依赖的技术，或者源于 Kerberos
设置的配置中那些很容易纠正的疏忽。本节将回顾依存关系，并总结每种依存关系怎样与 Kerberos 身份验证的故障诊断相关。

操作系统

Kerberos 身份验证依赖于在 Microsoft® Windows Server™ 2003 操作系统、Microsoft Windows® XP
操作系统和 Microsoft Windows® 2000
操作系统中内置的客户端功能。如果一个客户端、域控制器或目标服务器运行的是较早的操作系统，则它本身不能使用 Kerberos 身份验证。

TCP/IP 网络连接

为了使 Kerberos 身份验证发挥作用，在客户端、域控制器和目标服务器之间必须存在 TCP/IP 网络连接。

如果使用了防火墙，确保在网络中启用了 Kerberos 端口。有关域控制器所使用的公共端口，请参见 Microsoft 知识库中的“Windows
Server 域控制器默认端口列表”，位于：http://go.microsoft.com/fwlink/?LinkId=22894。

注意
可以使用缓存的凭据登录的用户可能不会意识到连接问题。

域名系统

客户端使用完全合格的域名 (FQDN) 来访问域控制器。

•
DNS 必须运行以使客户端可以获得 FQDN。
•
为了得到最好的结果，不要使用具有 DNS 的 Hosts 文件。

关于 DNS 的信息，请参见“Microsoft Windows Server 2003 部署工具包”中的“部署 DNS 的过程”，位于：http://go.microsoft.com/fwlink/?LinkId=23041。

Active Directory 域

较早的操作系统（如 Microsoft® Windows NT® 4.0 操作系统）并不支持 Kerberos 身份验证。必须使用 Active
Directory® 目录服务中的用户和计算机帐户来使用 Kerberos 身份验证。本地帐户和 Windows NT 域帐户不能用于 Kerberos
身份验证。

时间服务

为了使 Kerberos 身份验证正常工作，使网络中的计算机上的时间同步（即网络中所有的域和林使用同一个时间源）非常重要。一个 Active
Directory 域控制器将作为它的域的授权时间源，这保证了整个域具有相同的时间。更多信息请参见 Microsoft TechNet 上的“Windows
时间服务技术参考”，位于：http://go.microsoft.com/fwlink/?LinkId=25393。

服务主体名称

服务主体名称 (SPN) 是服务器上所运行的服务的唯一标识符。需要为每个使用 Kerberos 身份验证的服务设置一个
SPN，以使客户端可以在网络中识别此服务。如果没有为一个服务设置 SPN，则客户端将无法定位此服务。如果未正确设置 SPN，则将不可能进行 Kerberos
身份验证。

如果未正确设置 SPN 并且一个客户端尝试获取一个服务票证，则一般的结果是出现 KDC_ERR_C_PRINCIPAL_UNKNOWN 或
KDC_ERR_S_PRINCIPAL_UNKNOWN 错误。此外，还有许多由于没有或不正确地设置 SPN 而造成的其他错误。

一般来讲，可以在创建服务帐户或在一台新的计算机上安装服务时设置 SPN。SPN
标识了服务在哪台计算机上运行、服务在哪个帐户下运行以及服务在哪个端口上运行等详细信息。因此，设置一个服务帐户的 SPN
的安全性几乎与创建此帐户的安全性相同。为一个没有设置 SPN 的服务创建的服务帐户将不会在 2003
功能级域中发布使用它的服务密钥加密的服务票证。相反，Windows Server 将使用用户对用户模式。有关用户对用户身份验证的更多信息，请参见“Windows
Server 2003 技术参考”中的“Kerberos Version 5 身份验证协议的工作原理”，位于：http://go.microsoft.com/fwlink/?LinkID=27175，在其中搜索“用户对用户身份验证的过程”。

表 1 中列出了计算机帐户所识别的内建 SPN。如果计算机具有一个 HOST SPN，则计算机帐户可以识别这些 SPN。除非在对象上显式地放置了这些
SPN，否则 HOST SPN 可以代替表中所列出的任意 SPN。

表 1 计算机帐户可识别的内置 SPN

SPN ? ? ?

alerter

http

policyagent

scm

appmgmt

ias

protectedstorage

seclogon

browser

iisad

rasman

snmp

cifs

min

remoteaccess

spooler

cisvc

messenger

replicator

tapisrv

clipsrv

msiserver

rpc

time

dcom

mcsvc

rpclocator

trksvr

dhcp

netdde

rpcss

trkwks

dmserver

netddedsm

rsvp

ups

dns

netlogon

samss

w3svc

dnscache

netman

scardsvr

wins

eventlog

nmagent

scesrv

www

eventsystem

oakley

schedule

fax

plugplay

SPN 在 Active Directory 中的一个用户帐户下作为名为 Service-Principal-Name 的属性注册。SPN
将分配到此 SPN 所标识的服务在其下运行的帐户上。任何服务都可以查找另一个服务的 SPN。当一个服务要对另一个服务进行身份验证时，它将使用此服务的 SPN
来区分此服务和在此计算机上运行的所有其他服务。

SPN 对于约束委派非常重要。在为委派设置域计算机或用户帐户时，其中的一个步骤就是列出此计算机允许委派到的其他计算机上的服务的 SPN。这个列表构成了一种
ACL。在其他计算机上运行的服务由为这些服务指定的 SPN 标识。

设置 SPN 时所需的权限

为了在给定计算机帐户上写入任意的 SPN，需要“写入
ServicePrincipalName”权限，此权限不会默认授予创建此帐户的人。创建者具有“已验证的对服务主体名称的写入”权限。

为了在用户帐户上写入 SPN，“写入公共信息”权限授予了安全主体创建任意 SPN 的能力。

表 1 影响 SPN 的创建的默认 Active Directory 权限

安全主体计算机帐户对象用户帐户对象

帐户创建者

已验证的对服务主体名称的写入

写入公共信息

自身

已验证的对服务主体名称的写入

无

帐户操作者

写入 servicePrincipalName

已验证的对服务主体名称的写入

写入公共信息

管理员

写入 servicePrincipalName

已验证的对服务主体名称的写入

写入公共信息

身份验证的用户

无

无

因此，计算机帐户可以写入经验证的 SPN，而不是任意的 SPN。

设置 SPN 的要求

多项服务可以在同一个帐户下同时运行。因此，对于每个已设置的 SPN，都需要以下四个唯一的信息段：

•
服务的类型，正式的名称是服务类。此信息段使用户可以区分在同一个帐户下运行的多项服务。
•
服务在其下运行的帐户。
•
运行服务的计算机，包括指向此计算机的所有别名。
•
服务在其上运行的端口。

这四个信息段唯一地标识了在网络上运行的所有服务，并且可以用于对任意服务进行手动身份验证。

SPN 本身由三个信息段组成，即 ServiceClass/Host:Port，其中：

•
ServiceClass 是 SPN 的服务类。
•
Host 是 SPN 所属的计算机的名称。
•
Port 是注册 SPN 的服务所运行的端口。

有关如何使用 Setspn 工具操作帐户的服务主体名称的更多信息，请参考“附录 A：诊断工具”中的“Setspn”。

返回页首

Windows 身份验证方案

使用 Windows 操作系统可以有很多不同的身份验证方案。Kerberos
身份验证以委派为特征，这种特征使得可以跨多台服务器模仿用户身份。Windows Server 2003 中引入了约束委派。

本白皮书将集中讨论 Kerberos 委派的故障诊断问题。理解 Kerberos
身份验证怎样使用约束委派和协议转换进行操作，有助于在解决问题时对配置选项做出选择。

委派提供了与 NTLM 所提供的质询响应方法不同的身份验证方法。以下各节将介绍 NTLM 身份验证、使用 NTLM 身份验证的 Kerberos
身份验证以及涉及 Kerberos 身份验证的三种不同的委派方案。

NTLM 身份验证

图 1 NTLM 质询响应

较早版本的 Windows 操作系统使用 NTLM 来验证凭据。在 NTLM
协议中，客户端将用户名发送到服务器；服务器生成一个质询并将其发送到客户端；客户端使用用户的密码加密这个质询；客户端将一个响应发送到服务器。质询响应机制根据帐户是本地用户帐户还是域用户帐户而有所不同。

•
本地用户帐户。服务器将检查它的安全帐户管理器
(SAM)。如果服务器计算出一个相似的结果，它将验证用户的响应，构建一个访问令牌，并为用户建立一个会话。
•
域用户帐户。服务器将质询和客户端的响应一起转发到域控制器。域控制器对响应进行验证，并将客户端的组信息发送到服务器计算机。服务器使用此信息构建一个访问令牌，并为用户建立一个会话。

图 2 使用 NTLM 验证到后端服务器

作为零用户访问

NTLM
要求客户端在需要连接远程服务器时具有用户的密码，但是此密码从不传送到服务器。其缺点是前端服务器无法使用用户的身份访问后端服务器，这是因为前端服务器不具有用户的密码。

因此，只要前端服务器以用户方式尝试连接到后端服务器，它就会作为零用户进行连接。（参见图 2。）当 System 帐户下运行的一个进程尝试使用 NTLM
协议访问远程资源时，也会出现零用户。因此，如果遇到一条内容为“拒绝零用户访问”的错误消息，则可以假定连接使用的是 NTLM。

在 NTLM
身份验证中，当用户验证前端服务器后，如果前端服务器需要访问在后端服务器上运行的服务，则无法保存用户的凭据。后端服务器接收到一个来自前端服务器帐户的身份验证请求，但是后端服务器：

•
无法确定用户是谁。
•
无法区分两个用户的身份以确定哪个用户向前端服务器发出了请求。
•
无法根据用户的身份提供对资源的不同的访问控制。

使用 NTLM 身份验证或单帐户映射的 Kerberos 身份验证

图 3 Kerberos 和 NTLM 混合身份验证

Kerberos
身份验证可以增强安全性，这是因为可以建立审核和可计量性。然而，前端服务器可能会具有在高流量的情况下对成千个唯一用户进行身份验证而增加的负载。另一方面，如果使用
NTLM，在对前端服务器进行最初的身份验证之后，将不再需要对用户进行身份验证，而只需要验证计算机帐户。图 3 中显示的身份验证方案结合了 NTLM 和
Kerberos
身份验证。用户的身份将传送到另一台计算机以允许跟踪和记录，但是最后一次转发将在此计算机帐户之下进行以监听前端服务器上的负载。然而，由于前面在零用户情形下给出的相同的原因（即后端服务器无法验证请求服务的用户的身份），不推荐采用这种方式。

一个相似的方案是将前端服务器配置为使用单个帐户来访问后端服务器。这将出现同样的结果，即使在两次转发中都使用了 Kerberos 身份验证。

由于在这两种方案中都没有使用用户的身份来访问后端服务器，所以不推荐采用这两种方案。

Kerberos 身份验证

只有在使用 Kerberos 协议时才可以使用委派。因此，委派方案中所涉及的所有部分都必须使用 Kerberos 协议。本节将介绍三种委派方案：

•
Kerberos 身份验证
•
使用约束委派的 Kerberos 身份验证
•
使用约束委派和协议转换的 Kerberos 身份验证

Kerberos 身份验证

图 4 基本的 Kerberos 委派

如果使用 Kerberos
身份验证，当用户验证到前端服务器时，服务器将从在自己的服务帐户下运行切换到在用户的帐户下运行。然后前端服务器可以模仿用户来访问此用户有权访问的任意资源。而且，后端服务器可以验证此用户是请求访问的实体。

委派使用户的凭据可以从一台服务器传送到另一台服务器，并使用户的身份可以在从一台计算机到另一台计算机请求服务时予以保存。因此，图 4
中显示的前端服务器可以由多台中间层服务器代替，但是仍然需要模仿用户来与后端服务器进行通信。

注意
必须为委派信任所有的中间层服务器。

使用约束委派的 Kerberos 身份验证

在 Windows Server 2003 中，约束委派为域管理员提供了一种对委派信任的帐户可以访问的网络资源进行限制的方式。

另一方面，在 Windows 2000 中 Windows
不支持对委派的限制。在为委派信任一个帐户之后，此服务就可以使用用户的身份访问任意的网络资源。如果这项特定的服务受到了恶意用户的损坏，则将非常危险。

注意
只有当域处于 2003
域功能级时，才可以使用约束委派。在图 5 所示的一个客户端从 Windows Server
上升到前端服务器再到后端服务器的方案中，必须将前端服务器配置为只对后端服务器使用委派。

图 5 约束委派

为了限制服务可以以用户方式访问的资源，可以通过列出帐户可向其提交委派凭据的服务来配置约束委派。此列表的形式为允许用户委派到的 SPN。在约束委派中，Web
服务的帐户只接收委派到后端服务器的 SPN 的权限。

图 6 遭破坏的 Web 服务

在使用约束委派时，如果一个恶意用户破坏了 Web 服务帐户，则这个恶意用户只能访问后端服务器。（参见图 6。）

有关 SPN 的更多信息，请参见本白皮书前面的“服务主体名称”。

有关约束委派的更多信息，请参见 Microsoft TechNet 上的“Kerberos 协议转换和约束委派”，位于：http://go.microsoft.com/fwlink/?LinkId=18156。

使用约束委派和协议转换的 Kerberos 身份验证

在 Windows Server 2003 中，即使初始的身份验证使用另一种 SSP 来代替 Kerberos SSP（例如，NTLM 或
Schannel），协议转换也可以使委派发生。

图 7 Kerberos 协议转换的 SSL

由于在 Internet 上执行 Kerberos 身份验证是不现实的，所以前端服务器必须使用安全套接字层 (SSL)
等方法。然而，在前端服务器验证了用户的身份之后，前端服务器可以执行协议转换，并随后在公司网络内部使用所有的 Kerberos
身份验证功能。因此，开发者不需要使整个身份验证过程依赖于单个身份验证协议。

有关协议转换和约束委派的更多信息，请参见 Microsoft TechNet 上的“Kerberos 协议转换和约束委派”，位于：http://go.microsoft.com/fwlink/?LinkId=18156。

返回页首

配置 Kerberos 委派

Kerberos 委派需要 Kerberos 身份验证。因此，在对委派进行故障诊断之前，确保已满足了 Kerberos
身份验证的基础结构的要求。更多信息请参见本白皮书的“基础结构的要求”。

图 8 Kerberos 委派的基本要求

委派的要求

•
应用程序的域用户不能选中敏感帐户，不能被委派选项。
•
必须为中间层服务器上的服务注册 SPN。如果此服务帐户是一个域用户帐户，则此服务的 SPN
必须由域管理员注册。如果此服务帐户使用计算机的帐户，则此过程可以自己注册或者由本地管理员使用 Setspn 来注册。有关 Setspn 的更多信息，请参见“附录
A：诊断工具”中的“Setspn”。
•
必须为委派信任中间层服务帐户。
•
必须在后端服务器上为服务注册一个 SPN。
•
如果使用了约束委派，则中间层服务和后端服务必须位于同一个域中。

返回页首

诊断委派问题：四个清单

以下各节可以帮助您诊断在客户端到中间层到后端委派方案中出现的问题。此外，以下各节还可以帮助您应对在建立此方案时常常遇到的困难。

这些小节描述了可能发生的各种问题，讨论了这些问题可能的原因，并阐述了解决这些问题的步骤。讨论将以清单的形式进行，每个清单都包含一个“任务”列和一个“过程”列。在大多数情况下，“过程”列概述了为了完成任务所需做的工作。不过，过程的详细信息将在清单后的小节中进行说明。

•
清单 1 — Active Directory。正确地配置 SPN 和帐户。
•
清单 2 — 客户端应用程序。正确地配置应用程序并使用 Kerberos 身份验证。
•
清单 3 — 中间层。为委派正确地配置服务并使用 Kerberos 身份验证。
•
清单 4 — 后端。为 Kerberos 身份验证配置服务。

在一些组织中，配置帐户的管理员与对委派问题进行故障诊断的人可能并不相同。因此，在一个清单中收集了 Active Directory 任务。

其他三个清单是通过方案中的角色来组织的，其中包含与以下角色相关的帐户配置信息：

•
客户端。用户由其提出请求的应用程序。
•
中间层。位于中间的以用户方式提出请求的服务。
•
后端。最终与模仿用户的中间层服务进行通信的服务。

对于清单来说，参加委派的每个系统或服务只会应用一个清单。也就是说，无论环境有多复杂，对所有的客户端使用客户端清单，对所有的后端服务使用后端清单，并且对位于中间的所有服务使用中间层清单。

图 9 显示了在委派方案中可能涉及到的元素。

图 9 客户端到中间层再到后端的委派方案

在上面的例子中，客户端具有客户端角色；中间层服务器 1 具有中间层角色；后端服务器 1 到 n 具有后端角色；位于中间的中间层服务器 2 到 n
具有中间层和后端角色。对于这些清单来说，将中间层服务器 n 作为中间层服务器的原因是后端服务所需的任务是中间层服务的任务的一个子集。

故障诊断的策略

一些错误消息可能会帮助诊断发生问题的位置，但是有时这些消息起不到帮助作用。有关故障诊断 Kerberos 错误的更多信息，请参见“故障诊断
Kerberos 错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。

在进行故障诊断时，确保使用 Kerberos 协议验证到每项服务。不过需要注意的是，在对每项服务进行故障诊断时，可能需要使用不同的应用程序。例如：

•
如果服务器正在运行 SQL Server，则客户端应用程序可以是 Query Analyzer、osql.exe 或使用 ADO 的 VB
Script。
•
如果服务器正在运行 IIS，则客户端应用程序可以是 Internet Explorer。

在典型的委派使用中，用户直接或通过 Web 服务方式验证到运行 IIS 并访问 SQL 数据库的服务器，如果使用委派，中间层服务可以模仿具有访问 SQL
数据库中的数据的权限的用户。在这种情况下，经常使用约束委派来使用户可以访问在计算机上运行的特定服务。

清单 1 — Active Directory

Active Directory：正确配置 SPN 和帐户

任务过程完成的数据/执行人
从命令提示符执行

•
验证为中间层服务注册了 SPN。
•
验证为后端服务注册了 SPN。

1.

在命令提示符下键入：

setspn –L 帐户

其中帐户是服务在其下运行的帐户的名称。

2.

验证存在服务帐户的以下两个 SPN：

•
一个是 ServiceClass/Host:Port 的 SPN
•
一个是 ServiceClass/FQDN 的
SPN

详细的指导请参见“验证中间层服务帐户的 SPN”。

有关的例子请参见“附录 B”。

?
从“Active Directory 用户和计算机”

•
如果使用了约束委派：
•
验证域功能级已设置为 Windows Server
2003。

详细的指导请参见“验证域功能级”。

•
对于用户帐户：
•
确认未选中“敏感帐户，不能被委派”选项。

1.

右键单击用户帐户，然后单击“属性”。

2.

单击“帐户”选项卡。

3.

在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

详细的指导请参见“验证帐户选项”。

•
验证为中间层服务配置了委派。

如果中间层服务使用的是计算机帐户：

•
右键单击计算机帐户，然后单击“属性”。

•
如果此帐户在 Windows 2000
功能级域中，确认选中了“帐户可以委派其他帐户”选项。
•
如果此帐户在 Windows Server 2003
功能级域中，配置“委派”选项卡上的各个选项。

如果中间层服务使用的是域用户帐户：

•
右键单击服务帐户，然后单击“属性”。

•
如果此服务帐户在 Windows 2000
功能级域中，应该选中“帐户”选项卡上的“帐户可以委派其他帐户”选项。
•
如果此计算机帐户在 Windows Server 2003
功能级域中，配置“委派”选项卡上的各个选项。

详细的指导请参见“验证中间层服务帐户的委派”。

有关的例子请参见“附录 B”。

?

•
如果使用“组策略”进行配置，验证中间层服务具有以下两种权限之一：

•
作为操作系统的一部分
•
在身份验证之后模仿一个客户端

1.

通过单击“开始”，“程序”，“管理工具”，然后单击“域安全策略”来打开域安全策略。

2.

单击“本地策略”，然后单击“用户权限分配”。

详细的指导请参见“验证中间层服务权限”。

?

图 10 Active Directory 帐户配置

以下任务具有常规的配置指导。可以在“附录 B”中找到在常见的方案中需要设置的选项的示例。

验证中间层服务帐户的 SPN

验证为此方案中的每个中间层服务帐户都注册了一个 SPN。如果中间层服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN
都将自动设置，所以不需要验证是否正确地设置了 SPN。

验证为服务帐户设置了 SPN

在命令提示符下键入：

setspn –L 帐户

其中帐户是服务帐户的名称。

应该最少列出两个 SPN，这是因为为了使委派正常工作，必须存在以下两个服务帐户的 SPN：

•
ServiceClass/Host:Port，其中 ServiceClass
是适当的服务类，Host 是主机的名称，Port 是运行服务的端口。
•
ServiceClass/FQDN，其中 FQDN
是主机的完全合格域名。

疑难解答

如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。如果列出了重复的 SPN，则使用
Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

有关的例子请参见“附录 B”。

验证后端服务帐户的 SPN

验证为方案中的每个后端服务帐户都注册了一个 SPN。如果后端服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN
都将自动设置，所以不需要验证是否正确地设置了 SPN。

如果后端服务使用的是域用户帐户，则验证为服务帐户设置了 SPN。

有关的例子请参见“附录 B”。

验证域功能级

如果配置的是约束委派，则需要验证域控制器在 Windows Server 2003 功能级上操作。（注意：只有约束委派才需要此步骤。）

图 11 Windows Server 2003 域功能级

重要
Windows 2000
不支持约束委派。由于不受限的委派会降低安全性，所以应避免在 Windows 2000 环境中使用委派。

要验证域控制器的功能级

1.

打开“Active Directory 用户和计算机”。

2.

右键单击“DomainName”，然后单击“属性”。

3.

确认在“域功能级”下列出了 Windows Server 2003。

验证用户帐户选项

确认未选中用户帐户的“敏感帐户，不能被委派”选项。

要确认未选中“敏感帐户，不能被委派”选项：

1.

打开“Active Directory 用户和计算机”。

2.

右键单击“UserAccount”，然后单击“属性”。

3.

单击“帐户”选项卡。

图 12 用户帐户选项

4.

在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

验证中间层服务帐户的委派

验证为委派信任此方案中的每个中间层服务帐户。如果有一个中间层服务帐户不信任委派，则将收到类似如下的错误信息：

零用户登录失败

NT AUTHORITY\ANONYMOUS 用户登录失败

尽管在客户端和中间层服务之间或中间层服务和后端服务之间可以使用 Kerberos
协议，但是如果一项中间层服务未受到委派信任，则此中间层服务将不具有客户端的 TGT。这样，身份验证将退回到
NTLM。由于中间层服务不具有网络凭据（即用户的密码），所以它将成为零用户。

有关的例子请参见“附录 B”。

服务在计算机帐户下运行

如果服务在计算机帐户下运行，则需要为委派的服务器配置此计算机帐户。

为了验证中间层服务器计算机帐户受到委派信任

1.

打开“Active Directory 用户和计算机”。

2.

找到中间层服务器的计算机帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果此计算机帐户在 Windows 2000 功能级域中，应该选中“常规”选项卡上的“信任计算机作为委派”选项。（参见图
13。）

图 13 为委派信任功能级 Windows 2000 域计算机帐户

•
如果此计算机帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 14 没有为委派信任 Windows Server 2003 功能级域计算机帐户

在“委派”选项卡上，如果选中了“不信任此计算机作为委派”，则选择以下两个“信任”选项之一：

1.

要将帐户配置为使用不受限的委派，选择信任此计算机来委派任何服务（仅 Kerberos）。不推荐选择此选项。

2.

要将帐户配置为使用受限的委派，选择仅信任此计算机来委派指定服务。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。前面曾经提到过，SPN 本身由三个信息段（即 ServiceClass/Host:Port）组成，其中：

ServiceClass 是 SPN 的服务类。

Host 是 SPN 所属的计算机。

Port 是注册 SPN
的服务在其上运行的端口。

如果服务在域用户帐户下运行

如果服务在域用户帐户下运行，则需要为委派配置服务帐户。

为了验证为委派信任了中间层服务帐户

1.

打开“Active Directory 用户和计算机”。

2.

定位到所要配置的帐户，右键单击此帐户，然后单击“属性”。

•
如果此计算机帐户在 Windows 2000 功能级域中，单击“帐户”选项卡。

图 15 为委派信任服务帐户

在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。

•
如果此服务帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 16 不使用协议转换的服务帐户

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将此帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。（参见图 16。）
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成，其中：

ServiceClass 是 SPN 的服务类。

Host 是 SPN 所属的计算机。

Port 是注册 SPN
的服务在其上运行的端口。

验证中间层服务权限

由于模仿另一个用户的能力是委派的一个主要部分，所以如果一个过程没有所需的权限，它将无法委派。因此，验证委派方案中的每个中间层服务都具有以下两种权限之一：

•
作为操作系统的一部分（在 Windows 2000 或 Windows Server 2003 中可用）
•
在身份验证之后模仿一个客户端（在 Windows Server 2003 中新增）

这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似，只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿，而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。

默认情况下，为本地系统帐户分配“作为操作系统的一部分”权限。因此，如果中间层服务在本地系统帐户下运行，则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户，需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。如果使用组策略配置这些权限，则需要验证在域控制器上正确配置了策略。如果使用本地安全策略进行配置，在“清单
3 — 中间层”中对此过程进行了介绍。

如果使用了协议转换，中间层服务常常没有关于传入的用户身份的信息——也就是说，传入的用户在身份验证时所使用的协议可能没有提供与 Kerberos
身份验证相同的一组完整的凭据。因此，需要为这些中间层服务分配“作为操作系统的一部分”权限。

例如，尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户，但是它并没有正式对此用户进行身份验证。因此，运行 IIS
的中间层服务必须具有“作为操作系统的一部分”权限，以便在一个用户请求 Web 服务或后端服务器时模仿此用户。

这样，应该为第一个中间层服务配置“作为操作系统的一部分”权限。然而，由于“在身份验证之后模仿一个客户端”权限不能进行远程访问，所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限（如果使用的是
Windows Server 2003）。

为了验证服务帐户具有适当的权限

1.

通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。

注意
如果域控制器实施了组策略，则遵循步骤
1 中的指导。如果本地计算机实施了策略，则必须在本地计算机上打开本地安全策略。关于本地安全策略的指导请参见“清单 3 — 中间层”。

2.

单击“本地策略”，然后单击“用户权限分配”。

例如，图 17 显示了为 Tailspintoys\iisservice 分配了“在身份验证之后模仿一个客户端”权限。

图 17 默认域安全设置中的用户权限分配

为了对服务帐户设置“在身份验证之后模仿一个客户端”权限

1.

通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。（参见上方过程中的“注意”部分。）

2.

单击“本地策略”，再单击“用户权限分配”，然后单击“在身份验证之后模仿一个客户端”。

3.

添加所有需要委派凭据的帐户（例如 IIS 帐户）。

4.

由于更改是在域控制器上的域安全策略中进行的，接着在命令提示符下对客户端计算机运行 gpupdate
/force，以立即传播策略的更改。

清单 2 — 客户端应用程序

客户端应用程序：为 Kerberos 身份验证配置并使用此身份验证

任务过程完成的数据/执行人

•
从“Active Directory 用户和计算机”：

•
验证未选中此帐户的“敏感帐户，不能被委派”选项。（注意：如果完成了 Active Directory
清单，就完成了此任务。）

1.

右键单击用户帐户，然后单击“属性”。

2.

单击“帐户”选项卡。

3.

在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

详细的指导请参见“验证用户帐户选项”。

验证名称解析工作正常。

1.

使用 ping 来验证可用解析中间层服务器和后端服务器的 FQDN。

2.

验证客户端的本地 Hosts 文件不具有中间层服务器和后端服务器的短名称。

3.

如果客户端和服务器位于不同的域中，确保为连接使用服务器的
FQDN。

详细的指导请参见“验证名称解析”。

验证为 Kerberos 协议配置了客户端应用程序。

详细的指导请参见“验证为 Kerberos 协议配置了应用程序”。

有关的例子请参见“附录 B”。

验证客户端使用 Kerberos 身份验证来身份验证到服务。

可以通过以下方式进行验证：

•
为 NTLM 故障审核检查中间层服务器上的安全日志。
•
使用 Kerberos Tray 在连接到服务器之前清除票证，然后观察票证以找到一个连接到服务器的票证。

使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。

详细的指导请参见“验证客户端使用的是 Kerberos 身份验证”。

?

图 18 Kerberos 客户端应用程序

验证用户帐户选项

验证未选中用户帐户的“敏感帐户，不能被委派”选项。注意：如果按顺序完成以上清单，则此任务已在 Active Directory
清单中完成。

要验证未选中“敏感帐户，不能被委派”选项

1.

打开“Active Directory 用户和计算机”。

2.

右键单击 UserAccount，然后单击“属性”，

3.

再单击“帐户”选项卡。

图 19 用户帐户选项

4.

在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

验证名称解析

验证名称解析工作正常。Kerberos 身份验证要求每台计算机都可以解析与之通信的下一台计算机的 DNS
名称，而不论此计算机是位于中间层还是在后端。

•
使用 ping 验证可以进行以下解析：

•
从客户端解析中间层服务器的 FQDN。
•
从中间层服务器解析后端服务器的 FQDN。

Ping 通常返回服务器的 FQDN 及 IP 地址。确保客户端的本地 Hosts
文件不具有中间层服务器或后端服务器的短名称。
•
如果客户端和服务器位于不同的域中，为连接使用服务器的 FQDN。如果使用 NetBIOS
名称，则客户端计算机可能会解析一个本地域主体。这可能会造成身份验证的失败，这是因为客户端在本地域中找到了服务器的不正确的 SPN
并将其发送到远程的域目标。

可以使用 Net view 从命令行验证以下问题。

•
为测试 HOST/ServerName SPN 并验证到正确的 NetBIOS SPN 的解析，在命令提示符下键入：

net view \\NetBIOSName

注意
如果为本地命名的主体 SPN
而不是远程目标对名称进行解析，则身份验证将失败。在本地域中存在失效的或作废的对象时，这种情况很常见。经过 NetBIOS 和 FQDN
的名称解析将解析到正确的远程目标，但是 SPN 查找将解析到本地主体。
•
为了验证 HOST/FQDN SPN（在林中应是唯一的），从命令提示符键入：

net view \\FQDN
•
如果使用 NTLM 的 Net view 失败，则身份验证可能不是问题。为了验证 NTLM，从命令提示符键入：

net view \\IPAddress

例如，如果使用 NetBIOS 解析一个本地域主体，则 Net view 将给出以下结果：

•
如果 SPN 查找解析到错误的本地主体并且 Kerberos 身份验证失败，则 net view \\NetBIOSName
将由于拒绝访问而失败。
•
如果 SPN 查找解析到正确的远程主体并且 Kerberos 身份验证成功，则 net view \\FQDN
将成功完成。
•
如果使用 NTLM，则 net view \\IPAddress
将成功完成。

验证为 Kerberos 协议配置了应用程序

•
验证客户端应用程序支持 Kerberos 身份验证。

注意
Internet Explorer
版本 5.5 及更高版本都支持 Kerberos 身份验证。
•
验证为 Kerberos
协议配置了客户端应用程序。这个过程将根据所使用的客户端应用程序而有所不同。

有关的例子请参见“附录 B”。

验证客户端使用的是 Kerberos 身份验证

为了验证客户端使用 Kerberos 身份验证来验证服务，在域用户帐户下使用客户端身份验证连接到此服务。（Kerberos
身份验证只能在域用户帐户下进行，而不能在本地计算机用户帐户下进行。）

即使可以成功地连接，此连接也可能在 NTLM 上发生。因此，通过以下方式验证使用的是 Kerberos 身份验证数据包：

•
为 NTLM 成功审核检查中间层服务器上的安全日志。有关启用审核和使用安全日志的更多信息，请参见“附录
A：诊断工具”中的“安全事件日志”。
•
在连接到服务器之前使用 Kerberos Tray 清除票证，然后观察票证以找到一个连接到服务器的票证。更多信息请参见“附录
A：诊断工具”中的“Kerberos Tray”。
•
使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。如果拥有一个 Kerberos
分析程序，则可以很容易地观察流量并从流量中找出错误消息。此外，从域控制器到客户端的较大的流量表示一个成功的 Kerberos 连接。更多信息请参见“附录
A：诊断工具”中的“网络监视器”。

有关使用审核、调试输出和网络跟踪对 Kerberos 身份验证进行故障诊断的更多信息，请参见“故障诊断 Kerberos 错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。

如果使用 Kerberos 协议建立了连接，确保用户具有访问服务器的权限。如果用户不具有此权限，则可能会收到类似“用户
domain\UserName 不具有查看资源的权限”或“拒绝
domain\UserName 访问”的错误。

如果使用以下方式建立连接：

•
Kerberos 协议，转到“清单 3 — 中间层”以继续诊断问题。
•
NTLM，则两种可能的原因是：

1.

系统尝试使用 Kerberos 协议进行身份验证，但是返回了一条“帐户不在数据库中”错误消息或相关的错误消息。这样，系统将尝试使用 NTLM
进行身份验证。Windows Server 2003 和 Windows 2000 使用一种名为 Negotiate (SPNEGO) XP 的算法以及
Windows 来协商使用哪种身份验证协议。尽管 Kerberos 协议是默认协议，但是如果默认协议失败，Negotiate 将尝试 NTLM。有关故障诊断
Kerberos 错误的更多信息，请参见“故障诊断 Kerberos 错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。

2.

调用 Negotiate 将返回 NTLM
作为唯一可用的协议。

如果发现仍然在使用 NTLM 身份验证，或者在应该使用 Kerberos 身份验证的情况下没有尝试 Kerberos
身份验证，请联系“产品支持服务”以帮助诊断问题。

清单 3 — 中间层

如果中间层服务使用 NTLM 来验证下一项服务，则通常会收到类似如下的错误：

零用户登录失败

NT AUTHORITY\ANONYMOUS 用户登录失败

如果已验证了每台计算机使用的都是 Kerberos
协议，则此身份验证问题的一种可能的原因是没有为委派正确地配置中间层服务。在这种情况下，通常会收到类似如下的错误：

UserName 登录失败

中间层：配置服务以模仿用户

任务过程完成的数据/执行人

•
验证中间层服务和服务器支持 Kerberos
协议。

•
从命令行提示符：

•
验证为中间层服务注册了
SPN。

1.

在命令提示符下键入：

setspn –L 帐户

其中帐户是服务在其下运行的帐户的名称。

2.

验证存在服务帐户的以下两个 SPN：

•
一个是 ServiceClass/Host:Port 的
SPN
•
一个是 ServiceClass/FQDN 的
SPN

详细的指导请参见“验证中间层服务帐户的 SPN”。

有关的例子请参见“附录 B”。

•
从“Active Directory 用户和计算机”：

•
验证为中间层服务配置了委派。（注意：如果按顺序完成以上清单，则此任务已在 Active Directory
清单中完成。）

如果中间层服务使用的是计算机帐户：

•
右键单击计算机帐户，然后单击“属性”。

•
如果此帐户在 Windows 2000
功能级域中，验证选中了“帐户可以委派其他帐户”选项。
•
如果此帐户在 Windows Server 2003
功能级域中，配置“委派”选项卡上的选项。

如果中间层服务使用的是域用户帐户：

•
右键单击服务帐户，然后单击“属性”。

•
如果此服务帐户在 Windows 2000
功能级域中，验证选中了“帐户”选项卡上的“帐户可以委派其他帐户”选项。
•
如果此服务在 Windows Server 2003
功能级域中，配置“委派”选项卡上的各个选项。

详细的指导请参见“验证中间层服务帐户的委派”。

有关的例子请参见“附录 B”。

•
从域安全策略组策略（如果完成了 Active Directory 清单，则已完成）或本地安全策略：

•
验证中间层服务具有以下两种权限之一：

•
作为操作系统的一部分
•
在身份验证之后模仿客户端

•
单击“本地策略”，然后单击“用户权限分配”。

详细的指导请参见“验证中间层服务权限”。

•
验证已授权用户访问中间层服务器上的所需的资源。

•
验证为模仿配置了中间层服务。

有关的例子请参见“附录 B”。

•
验证中间层服务在连接到下一台服务器之前模仿用户。

更多信息请参见“验证中间层服务模仿用户”。

?

图 20 中间层服务支持 Kerberos 协议

验证中间层支持 Kerberos 协议

验证每个中间层服务或服务器都支持 Kerberos 协议。

验证中间层的 SPN

验证为每个中间层服务帐户都注册了一个 SPN。（注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。）

如果中间层服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN 都将自动设置，所以不需要验证是否正确地设置了
SPN。

验证为服务帐户设置了 SPN

在命令提示符下键入：

setspn –L帐户

其中帐户是服务帐户的名称。

应该至少列出两个 SPN，这是因为为了使委派正常工作，必须存在以下两个服务帐户的 SPN：

•
ServiceClass/Host:Port，其中 ServiceClass
是适当的服务类，Host 是主机的名称，Port 是运行服务的端口。
•
ServiceClass/FQDN，其中 FQDN
是主机的完全合格域名。

疑难解答

如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

有关常见方案的例子请参见“附录 B”。

验证域功能级

如果配置的是约束委派，则需要验证域控制器在 Windows Server 2003 功能级上操作。（只有约束委派才需要此步骤。）

注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。

图 21 Windows Server 2003 域功能级

重要
Windows 2000
不支持约束委派。由于不受限的委派会降低安全性，所以应避免在 Windows 2000 环境中使用委派。

要验证域控制器的功能级

1.

打开“Active Directory 用户和计算机”。

2.

右键单击 DomainName，然后单击“属性”。

3.

验证在“域功能级”下列出了 Windows Server 2003。

验证中间层服务帐户的委派

注意：如果按顺序完成前面的全部清单，则此任务已在 Active Directory 清单中完成。

验证为委派信任此方案中的每个中间层服务帐户。如果没有为委派信任此中间层服务帐户，则将收到类似如下的错误信息：

零用户登录失败

NT AUTHORITY\ANONYMOUS 用户登录失败

尽管在客户端和中间层服务之间或中间层服务和后端服务之间可以使用 Kerberos
协议，但是如果没有为委派信任此中间层服务，则此中间层服务将不具有客户端的 TGT。这样，身份验证将退回到
NTLM。由于中间层服务不具有网络凭据（即用户的密码），所以它将成为零用户。

有关的例子请参见“附录 B”。

服务在计算机帐户下运行

如果服务在计算机帐户下运行，则需要为委派的服务器配置此计算机帐户。

为了验证为委派信任中间层服务器计算机帐户

1.

打开“Active Directory 用户和计算机”。

2.

找到中间层服务器的计算机帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果此计算机帐户在 Windows 2000 功能级域中，应该选中“常规”选项卡上的“信任计算机作为委派”选项。（参见图
22。）

图 22 为委派信任功能级 Windows 2000 域计算机帐户

•
如果此计算机帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 23 没有为委派信任 Windows Server 2003 功能级域计算机帐户

在“委派”选项卡上，如果选中了“不信任此计算机来委派”，则选择以下两个“信任”选项之一：

1.

要将帐户配置为使用不受限的委派，选择信任此计算机来委派任何服务（仅 Kerberos）。不推荐选择此选项。

2.

要将帐户配置为使用受限的委派，选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成，其中：

ServiceClass 是 SPN 的服务类。

Host 是 SPN 所属的计算机。

Port 是注册 SPN
的服务在其上运行的端口。

服务在域用户帐户下运行

如果服务在域用户帐户下运行，则需要为委派配置服务帐户。

为了验证为委派信任了中间层服务帐户

1.

打开“Active Directory 用户和计算机”。

2.

定位到所要配置的帐户，右键单击此帐户，然后单击“属性”。

•
如果配置的帐户在 Windows 2000 功能级域中，单击“帐户”选项卡。

图 24 为委派信任服务帐户

在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。

•
如果此服务帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 25 不使用协议转换的服务帐户

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将此帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。（参见图 25。）
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。这些 SPN 应该是后端服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成，其中：

ServiceClass 是 SPN 的服务类。

Host 是 SPN 所属的计算机。

Port 是注册 SPN
的服务在其上运行的端口。

验证中间层服务权限

注意：如果使用域安全策略进行配置，在“清单 1 — Active Directory”中对此过程进行了介绍。

由于模仿另一个用户的能力是委派的一个主要部分，所以如果一个过程没有所需的权限，它将无法委派。因此，验证委派方案中的每个中间层服务都具有以下两种权限之一：

•
作为操作系统的一部分（在 Windows 2000 或 Windows Server 2003 中可用）
•
在身份验证之后模仿一个客户端（在 Windows Server 2003 中新增）

这两种权限都给予一个帐户模仿另一个帐户的能力。“在身份验证之后模仿一个客户端”权限与“作为操作系统的一部分”权限相似，只是前者不能进行远程访问。即第一种权限只允许一个过程在身份验证之后进行模仿，而“作为操作系统的一部分”权限则允许一个过程在身份验证之前进行模仿。

如果使用组策略配置这些权限，则需要验证在域控制器上正确配置了策略。

默认情况下，为本地系统帐户分配“作为操作系统的一部分”权限。因此，如果中间层服务在本地系统帐户下运行，则不需要在安全策略中修改用户权限的分配。对于所有其他的帐户，需要为其配置“作为操作系统的一部分”或“在身份验证之后模仿一个客户端”权限。

如果使用了协议转换，中间层服务常常没有关于进来的用户身份的信息——也就是说，进来的用户在身份验证时所使用的协议可能没有提供与 Kerberos
身份验证相同的一组完整的凭据。因此，需要为这些中间层服务分配“作为操作系统的一部分”权限。

例如，尽管运行 IIS 的中间层服务可能会将浏览 Web 页面的权限授予传入的用户，但是它并没有正式对此用户进行身份验证。因此，运行 IIS
的中间层服务必须具有“作为操作系统的一部分”权限，以便在一个用户请求 Web 服务或后端服务器时模仿此用户。

这样，应该为第一个中间层服务配置“作为操作系统的一部分”用户权限设置。然而，由于“在身份验证之后模仿一个客户端”权限不能进行远程访问，所以应该为任何将在初始的身份验证之后被访问的中间层服务配置“在身份验证之后模仿一个客户端”权限（如果使用的是
Windows Server 2003）。

为了验证服务帐户具有适当的权限

1.

通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开本地安全策略。

注意
如果域控制器实施了策略，则遵循步骤 1
中的指导。如果域控制器实施了策略，则必须打开域安全策略或组策略。

2.

单击“本地策略”，然后单击“用户权限分配”。

例如，图 26 显示了为 Administrators 和 SERVICE 配置了“在身份验证之后模仿一个客户端”权限。

图 26 本地安全设置中的用户权限分配

为了为服务帐户设置“在身份验证之后模仿一个客户端”权限

1.

通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开域安全策略。

注意
如果域控制器实施了策略，则遵循步骤 1
中的指导。如果域控制器实施了策略，则必须打开域安全策略或组策略。

2.

单击“本地策略”，再单击“用户权限分配”，然后单击“在身份验证之后模仿一个客户端”。

3.

添加所有需要委派凭据的帐户（例如 IIS 帐户）。

验证用户身份验证

验证已授权用户访问中间层服务器上的所需的资源。

验证中间层服务配置

验证为模仿配置了此方案中的每个中间层服务。根据服务的不同也许有必须配置的设置或元数据，以便中间层服务使用 Kerberos 协议。

注意
可以将 IIS 配置为同时使用
Negotiate 和 NTLM。更多信息参见 Microsoft 知识库中的“HOW TO：将 IIS 配置为同时支持 Kerberos 和 NTLM
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=24925。

有关的例子请参见“附录 B”。

验证中间层服务模仿用户

验证中间层服务在连接到下一个服务之前模仿用户。例如，ASP.NET 应用程序或 COM+ 应用程序可以在 domain\UserName
下运行以代替模仿真正的用户，并且可以在 domain\UserName 下连接到后端服务器。这会造成类似如下的错误：

domain\UserName登录失败

拒绝 domain\UserName 访问。

清单 4 — 后端

后端：为 Kerberos 身份验证配置服务。

任务过程完成的数据/执行人

•
从命令提示符：
•
验证为后端服务的服务帐户注册了 SPN。（注意：如果按顺序完成以上清单，则此任务已在 Active Directory
清单中完成。）

1.

在命令提示符下键入：

setspn –L 帐户

其中帐户是服务在其下运行的帐户的名称。

2.

验证存在服务帐户的以下两个 SPN：

•
一个是 ServiceClass/Host:Port 的
SPN
•
一个是 ServiceClass/FQDN 的
SPN

详细的指导请参见“验证后端服务帐户的 SPN”。

有关的例子请参见“附录 B”。

•
验证已授权用户访问后端服务器上的所需的资源。

?

?

图 27 后端服务器

验证后端服务帐户的 SPN

验证为方案中的每个后端服务帐户都注册了一个 SPN。（如果按顺序使用以上清单，则此任务已在 Active Directory 清单中完成。）

如果后端服务作为本地系统或网络服务运行，则不需要手动设置任何 SPN。这样，由于所有的 SPN 都将自动设置，所以不需要验证是否正确设置了
SPN。

验证为服务帐户设置了一个 SPN

在命令提示符下键入：

setspn –L 帐户

其中帐户是后端服务在其下运行的帐户的名称。

•
验证存在使委派正常工作所需的以下两个后端服务帐户的 SPN：

•
一个是 ServiceClass/Host:Port 的 SPN，其中 ServiceClass
是适当的服务类，Host 是主机的名称，Port 是运行服务的端口。
•
一个是 ServiceClass/FQDN 的 SPN，其中 FQDN
是主机的完全合格域名。

疑难解答

如果没有列出任何 SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。中间层服务需要以上两个 SPN
以正确地对后端服务使用委派凭据。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

有关的例子请参见“附录 B”。

验证已授权用户访问后端服务器的资源

例如，如果后端服务器是 SQL Server，确保授权用户访问 SQL 数据库。如果没有对用户进行授权，可能会收到类似如下的错误：

UserName 登录失败

拒绝 UserName 访问

注意
后端服务帐户不需要设置委派，这是因为它将身份验证到或将凭据委派到其他服务。

返回页首

总结

本白皮书讨论了对 Kerberos 委派问题进行故障诊断的各种方法。前面各节详细介绍了在设置这些方案时经常出现的错误以及解决这些问题的方式。

由于最常见的 Kerberos 委派的使用是使用 IIS 和 SQL 的委派方案，所以“附录 B”对 IIS/SQL 委派方案进行了更详细的介绍。

返回页首

附录 A：诊断工具

一些用于诊断 Kerberos 错误的工具（例如事件查看器和网络监视器）与用于其他与网络相关的或身份验证的问题的工具相同。其他的特定工具（例如
Kerberos List 和 Kerberos Tray）可以用于详细的特定于 Kerberos 的信息。本节提供了有关故障诊断工具的信息。

事件查看器

在 Windows Server 2003 和 Windows 2000 中都包括事件查看器。系统日志 XP 以及 Windows 和安全日志将包含
Kerberos 错误代码和其他与身份验证相关的事件。有关使用事件查看器进行故障诊断的更多信息，请参见 Microsoft 知识库的“HOW TO：在
Windows Server 2003 中使用事件查看器诊断系统问题”，位于：http://go.microsoft.com/fwlink/?LinkId=23046。

安全事件日志

安全事件日志中包含可以说明 Kerberos
身份验证是否发生故障或使用的是否是其他身份验证协议的信息。用户的特定登录/注销事件的详细信息将显示所使用的身份验证协议。

尽管推荐使用 Kerberos 身份验证，但是系统可能会在发生错误或故障时转到 NTLM。这种转换会引起更多的问题，这是因为用户将不会获得任何
Kerberos 票证并且可能无法访问 Kerberos 知道的服务或不具有在整个网络中进行单次登录的功能。

NTLM 或 Kerberos 协议

怎样可以知道登录时使用的是 NTLM 还是 Kerberos 协议？所有在运行 Windows Server 2000 的计算机上进行的帐户登录都应该使用
Kerberos 2003 或 Windows 协议（或 Negotiate，可以表示使用了 Kerberos
协议）。为了捕获这些事件，需要启用对成功的用户身份验证的帐户登录事件和计算机身份验证的登录事件的审核。

“登录类型”域有助于确定哪种事件适用于登录尝试的类型。表 2 中列出了“登录类型”域中可能的值。

表 2 登录类型

2

Interactive（交互登录）

3

Network（通过网络访问系统）

4

Batch（作为批处理作业启动）

5

Service（由服务控制器启动的 Windows 服务）

6

Proxy NT or Windows（代理登录；在 Windows 2000 中未使用）

7

Unlock（解除对工作站的锁定）

8

NetworkCleartext（使用纯文本凭据的网络登录）

9

NewCredentials（由 RunAs 在使用 /netonly
选项时使用）

如果安全日志显示使用的是 NTLM 并且存在与身份验证相关的问题，则需要通过使用本节中介绍的工具进行诊断。

启用故障审核

默认情况下，Windows Server 2003
只记录成功的审核。通常，这种默认设置将妨碍查找身份验证问题，这是因为在日志中很多失败的身份验证尝试都没有显示。启用故障审核将显示失败的身份验证，并因此会提供一些有关错误源的额外信息。

为了启用故障审核

1.

通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开本地安全策略。

注意
此过程假定域控制器没有实施审核策略。如果情况是这样，则必须在域控制器上打开域安全策略或合适的组策略。

2.

单击“本地策略”，然后单击“审核策略”。

3.

右键单击“审核帐户登录事件”。

4.

选择“定义这些策略设置”。

5.

在“审核这些尝试：”下确保选中了“成功”和“失败”选项。

6.

单击“确定”。

7.

重复步骤 3 到 6 以使“审核登录事件”记录成功和失败事件。

8.

如果更改是在域控制器上的域安全策略中进行的，在命令提示符下对客户端计算机运行 gpupdate
/force，以传播策略的更改。

Klist.exe: Kerberos List

Kerberos List 是一个命令行工具，可以用来查看和删除已授予当前的登录会话的 Kerberos 票证。为了使用 Kerberos List
来查看票证，必须在一台是 Kerberos 领域的成员的计算机上运行此工具。

当从客户端运行 Kerberos List 时，将显示以下信息：

•
Windows 中的 Kerberos 密钥分发中心 (KDC) 的票证授权票证 (TGT)。
•
UNIX 上的 Ksserver 的票证授权票证 (TGT)。

如何安装 Kerberos List

Windows Server 2003、Windows 2000.XP 和 Windows 都支持 Kerberos List

可以从 Microsoft 下载中心下载 Klist.exe 和其他“Windows Server 2003 资源工具包工具”，位于：http://go.microsoft.com/fwlink/?LinkID=16544。

如何使用 Kerberos List

Kerberos List 是一个命令行工具，此工具使用以下语法：

klist [tickets | tgt | purge] [-?]

要运行 Kerberos List：

1.

依次单击“开始”、“所有程序”、“附件”和“命令提示符”。

2.

在命令提示符窗口中，键入：

klist.exe参数

然后按 ENTER 键。

Kerberos List 的参数

票证

列出在登录之后身份验证到的服务的当前缓存的票证。“票证”可以用于验证为用户发出了一个 Kerberos
票证。在一个身份验证请求之后，应该出现多个票证。此命令还将显示有关获取的票证的详细信息，包括这些票证发布到的服务器、有效期和票证选项。

“票证”显示所有缓存票证的以下属性：

选项描述

结束时间

票证失效的时间。在票证经过这段时间之后，将不能用于身份验证到服务。

KerbTicket 加密类型

用于加密 Kerberos 票证的加密类型。

更新时间

更新的票证的最大生存期（参见下面的表中的
TicketFlags）。为了继续使用此票证，必须在到达已建立的结束时间之前以及在 RenewUntil
中建立的过期数据之前对其进行更新。

服务器

票证的服务器和域。

tgt

列出初始的 Kerberos 票证授权票证 (TGT)。tgt显示了当前缓冲的票证的以下属性：

选项描述

AltTargetDomainName

为生成此票证的 InitializeSecurityContext 提供的名称，通常是一个
SPN。

DomainName

服务的域名。

结束时间

票证失效的时间。在票证经过结束时间之后，将不能用于身份验证到服务。

FullServiceName

服务的帐户主体的规范名称。

KeyExpirationTime

来自 KDC 应答的过期时间。

RenewUnitil

更新的票证的最大生存期（参见 TicketFlags）。为了继续使用一个票证，必须对其进行更新。必须在结束时间和
RenewUntil 中设置的过期时间之前更新票证。

ServiceName

TGT 是密钥分发中心 (KDC）服务的票证。TGT 的服务名称是 krbtgt。

StartTime

票证生效的时间。

TargetDomainName

对于跨领域的票证，此领域是票证有效的领域，而不是发出票证的领域。

TargetName

请求票证的服务名称。这是目录中的一个帐户的 servicePrincipalName
属性的名称。

TicketFlags

在当前的票证上设置的十六进制的 Kerberos 票证标记。Kerberos Tray
在“标志”选项卡上显示了这些标志。

TimeSkew

票证的客户端计算机和服务器计算机之间的报告时间之差。

清除

删除用户所拥有的所有 Kerberos
票证。“票证”将破坏所有已缓存的票证，所以谨慎使用此选项。此选项可能会使用户不能再身份验证到资源。如果出现这种情况，则必须注销，然后重新登录。

-?

显示命令行帮助。

Kerbtray.exe: Kerberos Tray

Kerberos Tray 是一个图形用户界面工具，此工具将显示运行 Kerberos 版本 5 身份验证协议的 Microsoft
实现的计算机的票证信息。Windows Server 2003、Windows XP 和 Windows 2000 都支持 Kerberos Tray。

可以通过使用位于桌面的通知区域中的 Kerberos Tray 工具图标来查看和清除票证缓存。通过将光标放置在此图标上，可以查看初始的票证授权票证
(TGT) 过期前还有多少时间。此图标还将在本地安全机构 (LSA) 更新票证之前以小时为单位变化。

如何安装 Kerberos Tray

Kerberos Tray 包含在“Windows Server 2003 资源工具包”和“Windows 2000 资源工具包”中。

可以从 Microsoft 下载中心下载 Kerbtray.exe 和其他“Windows Server 2003 资源工具包工具”，位于：http://go.microsoft.com/fwlink/?LinkID=16544。

如何使用 Kerberos Tray

1.

为运行 Kerberos Tray，双击 Kerbtray文件。Kerbtray 图标将出现在通知区域中。

2.

为了在运行 Kerberos Tray 之后打开主 Kerbtray
窗口，双击它在通知区域中的图标。将显示有关当前用户的所有票证的信息。在“标志”选项卡中将显示每个票证的票证选项。

3.

为了清除票证，在通知区域中右键单击 Kerbtray 图标并单击清除票证。

Ldifde

可以使用 Ldifde 来创建、修改和删除运行 Windows Server 2003 或 Windows XP Professional
的计算机上的目录对象。还可以使用 Ldifde 来扩展方案，将 Active Directory
用户和组信息导出到其他应用程序或服务，以及使用来自其他目录服务的数据填充 Active Directory。

Ldifed.exe 位于域控制器上，但是不能复制到运行 Windows XP 和 Windows Server 2003
的客户端计算机或在这些计算机上使用。

Ldifed 提供了一种快速提取和显示一个林或域中特定 SPN 的方法。在以下情况下这将非常有用：

•
在林中有多个对象具有相同的 HOST/NetBIOSname SPN，可能会造成 Kerberos 身份验证故障。
•
在帐户上注册了多个（因此无效）MSSQL SPN。

语法

ldifde [-i] [-f FileName]
[-s ServerName] [-c String1 String2]
[-v] [-j Path] [-t PortNumber]
[-d BaseDN] [-r LDAPFilter] [-p Scope]
[-l LDAPAttributeList] [-o LDAPAttributeList]
[-g] [-m] [-n] [-k]
[-a UserDistinguishedName Password]
[-b UserName Domain Password] [-?]

参数

-i

指定导入模式。如果没有指定，则默认的模式是导出。

-f FileName

确定导入或导出的文件名。

-s ServerName

指定执行导入或导出操作的域控制器。默认情况下，Ldifde 将在安装 Ldifde 的域控制器上运行。

-cString1String2

使用 String2 代替所有出现的 String1。此参数通常在从一个域将数据导入到另一个域并且导出域的可分辨名称
(String1) 需要使用导入域的可分辨名称 (String2) 来代替时使用。

-v

设置详细的模式。

-j Path

设置日志文件的位置。默认位置为当前路径。

-t PortNumber

指定一个 LDAP 端口号。默认的 LDAP 端口是 389。全局的目录端口是 3268。

-d BaseDN

设置数据导出的搜索库的可分辨名称。

-r LDAPFilter

为数据导出创建一个 LDAP 搜索筛选器。例如，为了使用特定的姓氏导出所有用户，可以使用以下筛选器：

-r (and(objectClass=User)(sn=Surname))

-p Scope

设置搜索范围。搜索范围选项是 Base、OneLevel 或 SubTree。

-l LDAPAttributeList

设置在导出查询的结果中所返回属性的列表。如果省略了此参数，则返回所有属性。

-o LDAPAttributeList

设置在导出查询的结果中所省略的属性的列表。此参数通常在从 Active Directory 导出对象然后将其导入到另一个遵循 LDAP
的目录时使用。如果另一个目录不支持一些属性，则可以使用此选择从结果集中省略这些属性。

-g

省略分页的搜索。

-m

省略只应用于 Active Directory
对象的属性。（例如，Object-Guid、Object-Sid、Pwd-Last-Set 和
SAM-Account-Type 属性。）

-n

省略二进制值的导出。

-k

忽略导入操作期间的错误并继续进行。以下是忽略的错误的一个完整的列表：

•
对象已是组的成员
•
违反对象类（即指定的对象类不存在），如果导入的对象没有其他属性
•
对象已存在
•
违反约束条件
•
属性或值已存在
•
没有这样的对象

-a UserDistinguishedName Password

将命令设置为使用提供的 UserDistinguishedName 和 Password
运行。默认情况下，此命令将使用当前登录到网络的用户的凭据运行。

-b UserName Domain Password

将命令设置为使用提供的 UserName Domain Password
运行。默认情况下，此命令将使用当前登录到网络的用户的凭据运行。

-?

显示命令菜单。

示例

最初使用计算机帐户安装 SQL Server 以启动服务（从而获得了所需的
SPN）。随后，将配置一个域帐户来启动服务，这样就会出现身份验证问题。产生问题的原因可能是在多个对象上注册了 MSSQL SPN。以下命令将生成一个在林中注册了
MSSQL SPN 的对象的列表：

LDIFDE –f filename.txt –t 3268 –d
“DC=forest,DC=Root,DC=com”
–l serviceprincipalname –r ”(serviceprincipalname=MSSQLSvc/)”
–p subtree

在这个例子中，参数的作用如下：

-f filename.txt

将输出写入到指定的文件。

-t 3268

可选参数，指定全局目录端口。

-d “DC=forest,DC=Root*,DC=com”

为搜索起始点使用所需的林或域的可分辨名称。

-l serviceprincipalname

限制服务主体名称的输出。

**-r ”(serviceprincipalname=MSSQLSvc/*)”

将 SQL 服务指定为要查找的 SPN。

-p subtree

将搜索范围设置为子树。

网络监视器

可以使用网络监视器工具，通过捕获网络记录并随后检查跨网络发送的真正的 Kerberos 包，来获取比事件日志所提供的信息更详细的信息。

注意
有关网络监视器的完整信息，请参见
Microsoft TechNet 上的“网络监视器”，位于：http://go.microsoft.com/fwlink/?LinkId=23049。与网络监视器相关联的最佳做法和过程，请参见
Microsoft TechNet 上的“清单：监视本地计算机上的网络流量”，位于：http://go.microsoft.com/fwlink/?linkid=23047。

网络监视器的完整版本包含在 Microsoft 系统管理服务器 (SMS) 中。而 Windows 2000、Windows XP 和 Windows
Server 2003 家族则包含了此工具的一个限制版本。从 Microsoft 产品支持服务也可以获得此工具。

如何在 Windows Server 2003 上安装网络监视器

1.

打开“Windows 组件向导”。

2.

在“Windows 组件向导”中，单击“管理和监视工具”，然后单击“详细信息”。

3.

在“管理和监视工具的子组件”中，选择“网络监视工具”复选框，然后单击“确定”。

4.

如果提示需要其他的文件，插入操作系统的安装光盘，或键入表示文件在网络上的位置的路径。

注意

•
为了执行这个过程，您必须是本地计算机上的 Administrators 组的成员，或者必须已委派适当的权限。如果此计算机在一个域中，则 Domain
Admins 组的成员可能可以执行此过程。
•
要打开“Windows 组件向导”，依次单击“开始”、“控制面板”、“添加或删除程序”和“添加/删除
Windows 组件”。
•
某些 Windows 组件需要在使用之前进行配置。如果安装了一个或多个这样的组件但是没有加以配置，则在单击“添加/删除 Windows
组件”时将显示一个需要配置的组件列表。要启动“Windows 组件向导”，单击“组件”。
•
此过程将自动安装网络监视器驱动程序。

如何在 Windows XP 上安装网络监视器

网络监视器包含在 Windows XP 支持工具中。

1.

在驱动器中插入 Windows XP CD-ROM。

2.

双击“我的电脑”，右键单击光盘驱动器，然后单击“资源管理器”。

3.

转到Support\Tools，然后双击Setup.exe。

4.

当“Windows 支持向导”启动时，单击“下一步”。

5.

在最终用户许可协议上单击“我同意”。

6.

键入名称和组织，然后单击“下一步”。

7.

单击“典型”或“完全”安装类型，然后单击“下一步”。

8.

验证安装位置，然后单击“安装”。

如何在 Windows 2000 上安装网络监视器

1.

单击“开始”，指向“设置”，然后单击“控制面板”。

2.

双击“添加或删除程序”。

3.

单击“添加/删除 Windows 组件”。

4.

单击“管理和监视工具”，然后单击“详细信息”。

5.

单击以选中“网络监视工具”复选框，然后单击“确定”。

6.

单击“下一步”。

重要
在 Windows XP
上网络监视是由 Netcap.exe 工具完成的。此工具只允许网络流量的捕获。而捕获的结果不能使用同一个工具查看。必须使用 Windows 2003
家族上的网络监视器的 2000 或 Windows Server 完整版来查看捕获到的数据。

如何在 Windows XP 中捕获网络流量

如果使用在 Windows XP 支持工具中提供的 Netcap.exe 版本，使用以下过程：

1.

依次单击“开始”、“所有程序”、“附件”和“命令提示符”。

2.

在命令提示符窗口中，键入：

Netcap.exe /c:***path*

其中path是要存储此网络记录的目录和文件名的完全路径，然后按 ENTER 键。

3.

在复制错误之后，键入：

Netcap.exe /remove

然后按 ENTER 键。这将停止网络捕获。

在 Windows 2000 中捕获网络流量的过程和在 Windows 和 Windows Server 2003 中捕获网络流量的过程与 Windows
XP 的过程不同。对这些操作系统使用如下过程：

如何在 Windows 和 Windows Server 2003 家族中捕获网络流量

1.

依次单击“开始”、“控制面板”、“性能和维护”和“管理工具”，然后双击“网络监视器”。

2.

单击“启动”按钮开始捕获网络流量。

3.

复制错误。

4.

单击“停止”按钮以停止捕获网络流量。

5.

在右侧的捕获统计信息中，验证没有因为缓冲器溢出而丢失数据包。如果丢失了任何数据包，在“捕获”菜单上的“缓冲器设置”对话框中增加缓冲器的大小，并重新执行捕获。

更多信息请参见 Microsoft TechNet 上的“捕获网络帧”，位于：http://go.microsoft.com/fwlink/?LinkId=23052。

如何筛选特定于 Kerberos 的网络流量

可以筛选出来自除 Kerberos 协议之外的所有协议的包。为了应用一个只显示与 Kerberos
协议相关的网络流量的筛选器，在网络监视器中执行以下捕获：

1.

单击“捕获”，然后单击“显示捕获的数据”。

2.

单击“漏斗”按钮，然后双击协议 == 任何。

3.

单击“禁用全部”。

从列表中选择
Kerberos，然后单击“启用”。单击“确定”，然后再次单击“确定”。在执行此过程之后，将只会出现 Kerberos
数据包。

如果在应用此筛选器之后没有出现数据包

可能的原因是：

•
Kerberos 票证已发出或已缓存。可以使用 Kerberos List 来显示当前在计算机上发出的所有票证。还可以使用 Kerberos List
来清除所有票证。
•
没有尝试 Kerberos 身份验证协议。安全日志中相关的登录事件应该指出对用户进行身份验证所使用的协议。如果列出了 NTLM，则没有尝试
Kerberos 身份验证。如果 NTLM 回退是在登录时或请求网络资源时发生的，则事件日志中可能包含有用的信息。更多信息请参见“故障诊断 Kerberos
错误”白皮书，位于：http://go.microsoft.com/fwlink/?LinkID=27176。
•
网络监视器缓冲器溢出。在高流量的网络中，如果使用默认的缓冲器大小来配置此工具，则很容易出现这种情况。

分析捕获到的 Kerberos 流量

在捕获了一些 Kerberos
包之后，可以通过确定捕获到的数据与成功的身份验证之间的区别来对问题进行诊断。在大多数情况下，诊断将涉及到以下包交换并在捕获的数据中查找 KRB_ERROR
包。不过在一些情况下，特别是在一切都正常的情况下，需要进行更深入的分析。“附录
C”中提供了几个捕获的网络数据的例子，这些例子说明了成功的登录并显示了常见的失败。对捕获的数据进行了注释，以帮助说明每个帧对身份验证尝试的成功或失败的影响。

更多信息请参见：

•
Microsoft 知识库中的“如何使用网络监视器查看 HTTP 数据帧”，位于：http://go.microsoft.com/fwlink/?LinkId=23055。
•
Microsoft 知识库中的“有关网络监视器的常见问题”，位于：http://go.microsoft.com/fwlink/?LinkId=23056。

Setspn

Setspn 工具设置 SPN。由于 SPN 是安全敏感的，所以如果具有域管理员权限，则只能为用户对象设置 SPN。

如何安装 Setspn

Setspn 工具包含在 Windows Server 2003 支持工具中。

如何使用 Setspn

•
为了添加一个 SPN，可以在命令提示符下键入以下命令：

setspn –A ServiceClass/Host:Port AccountName

•
为了删除一个 SPN，可以在命令提示符下键入以下命令：

setspn –D ServiceClass/Host:Port AccountName

•
为了查看为一个帐户注册的 SPN，可以在命令提示符下键入以下命令：

setspn –L AccountName

•
为了重新设置一个帐户的主机名称的默认 SPN 注册，可以在命令提示符下键入以下命令：

setspn –R AccountName

以下各节将讨论上面所列出的参数。

•
ServiceClass。SPN 的种类有很多，应该为一台计算机上的每个服务都指定一个适当的 SPN 服务类。如果编写一个应用程序以利用
Kerberos 身份验证和委派，则它将具有访问预先确定所需的特定类型的 SPN。

例如，当 Internet Explorer 版本 5.5 及更高版本使用 Kerberos 协议来身份验证到 Web 服务时，此应用程序将查找 HTTP
SPN。另一方面，SQL Server 客户端将查找 MSSQLSvc/ SPN。如果在一个 SPN 上使用了错误的服务类，则在一个服务搜索此
SPN 时将无法定位此 SPN。
•
Host。SPN 所属于的计算机是服务在其上运行的计算机可以参考的所有名称。这通常包含一个 NetBIOS 名称、一个完全合格的域名
(FQDN) 和为此计算机指定的任意别名。需要为计算机所参考的每个名称设置一个独立的 SPN，并相应地更改
Host参数。
•
Port。服务在其上运行的端口。如果这是此服务的默认端口（例如 HTTP 的 80
端口），则可以省略。然而，推荐不论运行的是什么服务都包含端口。
•
AccountName。服务在其下运行的域帐户的名称。如果此服务作为本地系统或网络服务运行，则通常不需要为此服务显式地设置
SPN，这是因为大多数常见的 SPN 服务类将自动映射到自动为每个计算机帐户生成的 HOST/
SPN。

返回页首

附录 B：常见方案的配置示例

Internet Explorer 到 IIS 再到 SQL Server

图 28 Internet Explorer 到 IIS 再到 SQL Server

Internet Explorer 6

验证为 Kerberos 协议配置了客户端应用程序

这个过程将根据所使用的客户端应用程序而有所不同。对于 Internet Explorer 6，必须确保配置了集成的 Windows
身份验证并且站点位于本地 Intranet 区域中。

要配置集成的 Windows 身份验证

1.

在 Internet Explorer 中的“工具”菜单上，单击“Internet
选项”，然后“单击高级”选项卡。

2.

在“安全”列表框中，选择“启用集成的 Windows
身份验证（需要重新启动）”复选框，然后单击“确定”。

3.

重新启动 Internet Explorer。

有关此问题的信息，请参见 Microsoft 知识库中的“在升级到 Internet Explorer 6 之后无法协商 Kerberos
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=23045。

验证网站位于本地 Intranet 区域中

如果 Internet Explorer 尝试访问一个位于 Internet 区域的站点，则将不会使用 Kerberos 协议。Internet
区域站点不能使用集成的 Windows 身份验证，其原因包括这些协议通常通过 Web 代理工作等。如果站点位于 Internet 区域中，Internet
Explorer 将不会尝试使用 Kerberos 身份验证，并且将自动尝试 NTLM。在 Internet Explorer 的所有版本中，当访问一个希望使用
Kerberos 身份验证的网站时，必须验证此网站位于本地 Intranet 区域中。

注意
Internet Explorer
窗口的右下角中的一个图标指示了网站所处于的区域。此图标将为 Internet 区域显示“Internet”，为 Intranet 区域显示“本地
Intranet”。如果网站位于 Internet 区域中，则必须手动将站点添加到本地 Intranet 站点列表中。

要将一个站点添加到本地 Intranet 站点列表中

1.

在 Internet Explorer 中，单击“工具”，然后单击“Internet 选项”。

2.

单击“安全”选项卡，接着单击“本地
Intranet”，再单击“站点”，然后单击“高级”。

3.

在将该网站添加到区域中：文本框中，键入要使用 Kerberos
身份验证进行身份验证的网站名称，然后单击“添加”。

4.

单击“确定”。

有关添加本地 Intranet 站点的自动过程，请参见 Microsoft TechNet 上的“管理 Internet Explorer
增强的安全性配置”白皮书中的以下主题，位于：http://go.microsoft.com/fwlink/?LinkId=26091。

•
“使用组策略从安全区域添加或删除站点”
•
“使用 Internet Explorer 维护来执行受信任的站点和安全设置”

IIS

验证为运行 IIS 的服务设置了一个 SPN

在命令提示符下键入：

setspn –L 帐户

其中帐户是运行 IIS 的服务器在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 IIS 帐户的 SPN：

•
一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。
•
一个是 HTTP/FQDN 的 SPN，其中 FQDN
是主机的完全合格域名。

在大多数情况下，将为 IIS 自动使用 HOST/Host 和 HOST/FQDN。如果 IIS
作为本地系统或网络服务运行，则不需要手动设置任何 SPN。如果运行 IIS 的服务器的主机名具有一个别名，则通常要求注册 SPN。

疑难解答

如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这些 SPN 对于
Internet Explorer 正确地身份验证到 Web 服务器来说是必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

验证为 IIS 帐户配置了委派

通常情况下，IIS 在本地系统或网络服务帐户下运行。

为了验证为委派信任了 IIS 帐户

1.

打开“Active Directory 用户和计算机”。

2.

找到 IIS 的服务帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果 IIS 使用的是 Windows 2000
功能级域中的帐户，应该选中“常规”选项卡上的“信任计算机作为委派”选项。（参见图 29。）

图 29 为委派信任功能级 Windows 2000 域计算机帐户

如果 IIS 使用的是 Windows 2000
功能级域中的帐户，单击“帐户”选项卡。在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”选项。（参见图 30。）

图 30 为委派信任服务帐户

•
如果 IIS 帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 31 使用约束委派的 Windows Server 2003 功能级域用户帐户

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成，在此情况下：

MSSQLSvc 是 SQL Server 的服务类。

SQLServer 是计算机的主机名。

1433 是 SQL Server
在其上运行的端口。

验证为模仿配置了中间层服务。

当运行 SQL 2000 时，必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。

在中间层是 IIS 的例子中，必须只为网站启用集成的 Windows 身份验证选项。这确保了使用的是 Kerberos 协议而不是其他协议。

要为只使用集成的 Windows 身份验证的网站配置目录安全性

1.

打开“IIS 管理器”。

2.

单击运行 IIS 的计算机的名称，然后单击“网站”。

3.

右键单击网站的名称，然后单击“属性”。

4.

单击“目录安全性”选项卡，然后在“身份验证和访问控制”下单击“编辑...”。

5.

通过以下方式验证只选中了“集成的 Windows 身份验证”复选框：

•
清除“启用匿名访问”。
•
选择“集成的 Windows 身份验证”复选框。
•
清除下面的这些复选框：

“Windows 域服务器的摘要式身份验证”

“基本身份验证（以明文形式发送密码）”

“.NET Passport 身份验证”

SQL Server

验证为 SQL Server 帐户设置了一个 SPN

如果 SQL Server 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。

在命令提示符下键入：

setspn –L 帐户

其中帐户是 SQL Server 在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 SQL 服务的 SPN：

•
一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host
是主机的名称。
•
一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server
的计算机的完全合格域名。

在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。

疑难解答

如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这些 SPN 是
Web 服务器或 Web 服务正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

Internet Explorer 到使用 ASP.NET Web 服务的 IIS 到 SQL Server

有关为委派配置 ASP.NET 应用程序的更多信息，请参见 Microsoft 知识库中的“如何为委派方案配置 ASP.NET 应用程序”，位于：http://go.microsoft.com/fwlink/?LinkId=24926。

图 32 Internet Explorer-ASP.NET-SQL Server 委派方案

Internet Explorer 6

验证为 Kerberos 协议配置了客户端应用程序

这个过程将根据所使用的客户端应用程序而有所不同。对于 Internet Explorer 6，必须确保配置了集成的 Windows
身份验证并且站点位于本地 Intranet 区域中。

要配置集成的 Windows 身份验证

1.

在 Internet Explorer 中的“工具”菜单上，单击“Internet
选项”，然后“单击高级”选项卡。

2.

在“安全”列表框中，选择“启用集成的 Windows
身份验证（需要重新启动）”复选框，然后单击“确定”。

3.

重新启动 Internet Explorer。

有关此问题的信息，请参见 Microsoft 知识库中的“在升级到 Internet Explorer 6 之后无法协商 Kerberos
身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=23045。

验证网站位于本地 Intranet 区域中

如果 Internet Explorer 尝试访问一个位于 Internet 区域中的站点，则将不会使用 Kerberos 协议。Internet
区域站点不能使用集成的 Windows 身份验证，其原因包括这些协议通常通过 Web 代理进行工作等。如果站点位于 Internet 区域中，则
Internet Explorer 将不会尝试使用 Kerberos 身份验证，并且将自动尝试 NTLM。在 Internet Explorer
的所有版本中，当访问一个希望使用 Kerberos 身份验证的网站时，必须验证此网站位于本地 Intranet 区域中。

注意
Internet Explorer
窗口的右下角中的一个图标指示了网站所处于的区域。此图标将为 Internet 区域显示“Internet”，为 Intranet 区域显示“本地
Intranet”。如果网站位于 Internet 区域中，则必须手动将站点添加到本地 Intranet 站点列表中。

要将一个站点添加到本地 Intranet 站点列表中

1.

在 Internet Explorer 中，单击“工具”，然后单击“Internet 选项”。

2.

单击“安全”选项卡，接着单击“本地
Intranet”，再单击“站点”，然后单击“高级”。

3.

在“将该网站添加到区域中：”文本框中，键入要使用 Kerberos
身份验证进行身份验证的网站名称，然后单击“添加”。

4.

单击“确定”。

有关添加本地 Intranet 站点的自动过程，请参见 Microsoft TechNet 上的“管理 Internet Explorer
增强的安全性配置”白皮书中的以下主题，位于：http://go.microsoft.com/fwlink/?LinkId=26091。

•
“使用组策略从安全区域添加或删除站点”
•
“使用 Internet Explorer 维护来执行受信任的站点和安全设置”

IIS/Web 服务

在 Internet Explorer 到 IIS 到 ASP.NET Web 服务再到 SQL Server 方案中，需要为 IIS 帐户、Web
服务帐户和 SQL 服务帐户注册 SPN。

验证为 IIS 帐户设置了一个 SPN

在命令提示符下键入：

setspn –L 帐户

其中帐户是运行 IIS 的服务器在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 IIS 帐户的 SPN：

•
一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。
•
一个是 HTTP/FQDN 的 SPN，其中 FQDN
是主机的完全合格域名。

在大多数情况下，将为 IIS 自动使用 HOST/Host 和 HOST/FQDN。如果 IIS
作为本地系统或网络服务运行，则不需要手动设置任何 SPN。然而，如果运行 IIS 的服务器的主机名具有一个别名，则通常要求注册 SPN。

疑难解答

如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这些 SPN 对于
Internet Explorer 正确地身份验证到 Web 服务器来说是必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

验证为 Web 服务帐户设置了一个 SPN

在命令提示符下键入：

setspn –L帐户

其中帐户是 Web 服务在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 Web 服务帐户的 SPN：

•
一个是 HTTP/Host 的 SPN，其中 Host 是主机的名称。
•
一个是 HTTP/FQDN 的 SPN，其中 FQDN
是主机的完全合格域名。

疑难解答

如果没有列出任何 HTTP SPN 或缺少一个 SPN，则使用 setspn –A 命令添加适当的 SPN。这两个 SPN 是必需的，以使
Web 服务器可以正确地将凭据委派到 Web 服务。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

验证为 IIS 服务器帐户配置了委派

通常情况下，IIS 在本地系统或网络服务帐户下运行。

为了验证为委派信任了 IIS 帐户

1.

打开“Active Directory 用户和计算机”。

2.

找到 IIS 服务的帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果此计算机帐户在 Windows 2000 功能级域中，应该选中“常规”选项卡上的“信任计算机作为委派”选项。（参见图
33。）

图 33 为委派信任功能级 Windows 2000 域计算机帐户

•
如果此 IIS 帐户是 2000 功能级域中的用户帐户，单击 Windows“帐户”选项卡。

图 34 为委派信任服务帐户

在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。

•
如果 IIS 使用的是 Windows Server 2003 功能级域中的计算机帐户或用户帐户，单击“委派”选项卡。

图 35 IIS 服务器帐户委派到使用协议转换的 Web 服务

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。这应该是 Web 服务帐户的 SPN（在 ASP.NET 方案下这应该是 ASP.NET
在其下运行的帐户）。前面曾经提到过，SPN 本身由三个信息段（即 ServiceClass/Host:Port）组成，在 ASP.NET Web
服务的情况下：

HTTP 是 Web 服务的服务类。

lisserver 是计算机的名称。

80 端口是 Web
服务在其上运行的端口。

验证为 Web 服务帐户配置了委派

通常 Web 服务在域用户帐户下运行。

为了验证为委派信任了 Web 服务帐户

1.

打开“Active Directory 用户和计算机”。

2.

找到 Web 服务的帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果此 Web 帐户使用的是 2000 功能级域中的用户帐户，单击 Windows“帐户”选项卡。

图 36 为委派信任服务帐户

在“帐户选项”框中，确认选中了“敏感帐户，不能被委派”。（参见图 36。）

•
如果 Web 服务帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 37 Web 服务帐户委派到不使用协议转换的 SQL Server

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将帐户配置为使用不受限的委派，选择“信任此计算机来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将帐户配置为使用受限的委派，选择“仅信任此计算机来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成，在 SQL 服务的情况下：

MSSQLSvc 是 SQL Server 的服务类。

SQLServer 是计算机的主机名称。

1433 是 SQL
服务在其上运行的端口。

验证为模仿配置了中间层服务

当运行 SQL 2000 时，必须在 IIS 服务器上使用 MDAC 2.6 或更高版本。

当中间层是 IIS 和 ASP.NET Web 服务时，网站必须在“目录安全性”选项卡上只启用了“集成的 Windows
身份验证”选项。这确保了使用的是 Kerberos 协议而不是其他协议。此外，为了使委派可以与 ASP.NET Web
服务一起工作，在此服务中必须开启身份模仿。

要为只使用集成的 Windows 身份验证的网站配置目录安全性

1.

打开“IIS 管理器”。

2.

单击运行 IIS 的计算机的名称，然后单击“网站”。

3.

右键单击网站的名称，然后单击“属性”。

4.

单击“目录安全性”选项卡，然后在“身份验证和访问控制”下单击“编辑...”。

5.

通过以下方式验证只选中了“集成的 Windows 身份验证”复选框：

•
清除“启用匿名访问”。
•
选择“集成的 Windows 身份验证”复选框。
•
清除下面的这些复选框：

“Windows 域服务器的摘要式身份验证”

“基本身份验证（以明文形式发送密码）”

“.NET Passport 身份验证”

为了在 ASP.NET 应用程序中为每个页面的请求模仿 IIS 身份验证的用户，必须在此应用程序的 Web.config 文件中包含一个
<identity> 标记，并将 Impersonate 属性设置为 True。此文件可以在网站和 Web
服务的虚拟根目录中找到。确保在 Web.config 文件中包含以下 <identity> 标记：

<identity impersonate=”true” />

如果 Web.config 文件中没有此标记，将其添加到此文件的 <system.web> 部分。

更多信息请参见 Microsoft 知识库中的“信息：在 ASP.NET 应用程序中执行模仿”，位于：http://go.microsoft.com/fwlink/?LinkId=24923。

SQL Server

验证为 SQL Server 帐户设置了一个 SPN

如果 SQL Server 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。

在命令提示符下键入：

setspn –L 帐户

其中帐户是 SQL Server 在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 SQL 服务帐户的 SPN：

•
一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host
是主机的名称。
•
一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server
的计算机的完全合格域名。

在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。

疑难解答

如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这些 SPN 是
Web 服务器或 Web 服务正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

Internet Explorer 到使用非 Microsoft Web 服务的 IIS 再到 SQL Server

如果中间层是使用非 Microsoft Web 服务的 IIS，则网站必须启用了"集成的 Windows
身份验证"选项。（参见前面例子中的过程。）这确保了使用的是 Kerberos 协议而不是其他协议。其他 Web 服务也需要配置为模仿用户。

图 38 Internet Explorer 到使用非 Microsoft Web 服务的 IIS 到
SQL Server

•
按照前面例子“Internet Explorer 到 IIS 再到 SQL Server”配置 Internet Explorer 6、IIS 和 SQL
Server。
•
配置非 Microsoft 的组件使用 Kerberos 协议来模仿用户。

客户端到 SQL Server 再到 SQL Server

图 39 SQL 到 SQL 委派方案

客户端

验证为 Kerberos 协议配置了客户端应用程序

将客户端配置为使用 Kerberos 身份验证。

注意
当使用 SQL Server
时，可以使用其他工具来帮助验证使用的是 TCP/IP 和 Kerberos 身份验证：

•
客户端网络工具可以用来验证客户端可以使用 TCP/IP 与 SQL Server 进行通信。
•
服务器网络工具可以用来验证 SQL Server 是否正在监听 TCP/IP。
•
Osql 可以用来链接到 SQL Server。然后检查服务器上的网络流量或审核日志，以确定是否是使用 Kerberos
身份验证程序包进行连接的。如果不是，查看网络记录中的 Kerberos 错误消息（如果启用了 Kerberos
审核，则查看客户端事件查看器中的错误消息）。

SQL 服务 1

验证为 SQL 服务帐户 1 设置了一个 SPN

如果 SQL Server 1 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。

在命令提示符下键入：

setspn –L 帐户

其中帐户是 SQL Server 在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 SQL 服务帐户的 SPN：

•
一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host
是主机的名称。
•
一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server
的计算机的完全合格域名。

在 SQL 2000 中，如果 SQL Server 帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。

疑难解答

如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这两个 SPN
是客户端正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

验证为 SQL 服务帐户 1 配置了委派

最佳的情况是，为委派信任 SQL 服务帐户 1，并为 SQL 服务帐户 2 的约束委派设置此帐户。

为了验证为委派信任了 SQL 服务帐户

1.

打开“Active Directory 用户和计算机”。

2.

找到 SQL 服务帐户 1 的帐户。

3.

右键单击此帐户，然后单击“属性”。

•
如果此计算机帐户在 Windows 2000 功能级域中，验证选中了“常规”选项卡上的“信任计算机作为委派”选项。（参见图
40。）

图 40 为委派信任功能级 Windows 2000 域计算机帐户

•
如果此用户帐户在 Windows 2000 功能级域中，单击“帐户”选项卡。

图 41 为委派信任服务帐户

在“帐户选项框中”，确认选中了“敏感帐户，不能被委派”。

•
如果此计算机或用户帐户在 Windows Server 2003 功能级域中，单击“委派”选项卡。

图 42 使用约束委派的 Windows Server 2003 功能级域用户帐户

在“委派”选项卡上，选择以下两个“信任”选项之一：

1.

要将此帐户配置为使用不受限的委派，选择“信任此用户来委派任何服务（仅 Kerberos）”。不推荐选择此选项。

2.

要将此帐户配置为使用受限的委派，选择“仅信任此用户来委派指定服务”。通过选择以下两个选项之一来配置协议转换：

•
要将帐户配置为使用约束委派而不进行协议转换，选择“仅使用 Kerberos”。
•
要将帐户配置为使用约束委派并且进行协议转换，选择“使用任意身份验证协议”。

注意
在使用约束委派时，确认适当的 SPN
在此帐户可以向其提交委派凭据列表的服务之内。此 SPN 应该为 SQL 服务的 SPN。前面曾经提到过，SPN 本身由三个信息段（即
ServiceClass/Host:Port）组成。在这种情况下：

MSSQLSvc 是 SQL Server 的服务类。

SQLServer 是 Host。

1433 是 SQL
服务在其上运行的端口。

验证为模仿和委派配置了中间层服务

当运行 SQL 2000 时，必须在运行 SQL Server 的服务器上使用 MDAC 2.6 或更高版本。

为了验证将连接的服务器配置为模仿用户，可以使用以下 TSQL 命令：

sp_helplinkedsrvlogin

此命令提供了有关对特定的连接服务器定义的用于分布式查询和远程存储过程的登录映射的信息。

语法

sp_helplinkedsrvlogin [ 'rmtsrvname' ] [
'locallogin' ]

参数

'rmtsrvname'应用登录映射的连接服务器的名称。rmtsrvname 是
sysname，默认值为 NULL。如果此参数的值为 NULL，则将返回所有对在运行 SQL Server
的本地计算机中定义的连接服务器定义的登录映射。

'locallogin'SQL Server 登录到具有一个到连接服务器
rmtsrvname 的映射的本地服务器。locallogin 是 sysname，默认值为 NULL。NULL 指定了返回在
rmtsrvname上定义的所有登录映射。如果不是 NULL，则必须已存在一个从 locallogin 到
rmtsrvname的映射。locallogin 可以是一个 SQL Server
登录或一个域用户。域用户必须被授予直接访问或通过已授予访问权限的组中的成员身份来访问 SQL Server 的权限。

要验证连接的服务器的设置

1.

执行以下 TSQL 命令：

sp_helplinkedsrvlogin 'SQLServer2'

此命令应该返回以下输出：
Linked Server Local Login Is Self Mapping Remote Login
---------------- ------------- --------------- --------------
SQL Server 2 NULL 1 NULL
(1 row(s) affected)

2.

在上面的输出中，验证用户不具有相关联的远程访问以及为模仿配置了客户端。（即，将 Is Self Mapping 设置为
1）。

要为模仿配置连接的服务器

1.

展开一个服务器组，然后展开一个服务器。

2.

展开“安全性”，右键单击“连接的服务器”，选择适当的连接服务器，然后单击“属性”。

3.

在“安全性”选项卡上，选择“使用登录的当前安全上下文生成”，然后单击“确定”。

有关前面两个过程以及如何设置安全性以确保只有授权用户才能访问 SQL Server 中存储的数据和对象的更多信息，请参见 MSDN
中的“管理安全性”，位于：http://go.microsoft.com/fwlink/?LinkId=26092。

或者，可以通过从查询分析器运行以下命令来创建一个连接的服务器：

sp_addlinkedsrvlogin 'SQLServer2', 'true'

SQL 服务 2

验证为 SQL 服务帐户 2 设置了一个 SPN

如果 SQL Server 2 在一个域用户帐户 domain\sqlServiceAccount 下运行，则需要为
sqlServiceAccount 而不是 computername$ 注册一个 SPN。不这样做将会导致登录失败。

在命令提示符下键入：

setspn –L 帐户

其中帐户是 SQL Server 2 在其下运行的帐户的名称。

为了使委派正常工作，必须存在以下两个 SQL 服务帐户 2 的 SPN：

•
一个是 MSSQLSvc/Host:1433 的 SPN，其中 Host
是主机的名称。
•
一个是 MSSQLSvc/FQDN:1433 的 SPN，其中 FQDN 是运行 SQL Server 2
的计算机的完全合格域名。

在 SQL 2000 中，如果 SQL 服务帐户在本地系统帐户下运行或作为域管理员运行，则将默认注册此 SPN。

疑难解答

如果没有列出任何 MSSQLSvc SPN 或缺少一个 SPN，则应该使用 setspn –A 命令添加适当的 SPN。这两个 SPN
是中间层 SQL Server 正确地身份验证以及委派凭据到运行 SQL Server 的计算机所必需的。

如果列出了重复的 SPN，则使用 Setspn 工具重命名或删除重复的 SPN。可以使用 Ldifde 来查询全局目录以确保没有重复的 SPN。

返回页首

附录 C：网络监视器捕获到的网络记录的示例

注意
下面的记录已经过更改以删除不相关的或不必要的信息。

在正常登录期间进行 Kerberos 身份验证

在这个例子中，Kerberos 客户端从 KDC 获取了一个 TGT 和会话票证。
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 7027; Total IP Length = 333; Options = No Options
UDP: Src Port: Unknown (1676); Dst Port: Kerberos (88); Length = 313 (0x139)
KERBEROS: KRB_AS_REQ
KERBEROS: Realm (realm[2]) =multi
KERBEROS: Server name (sname[3]) =krbtgt/multi
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/multi
KERBEROS: Host addresses (addresses[9])
KERBEROS: Host address =NetBIOS: IIS
***************************************
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 14792; Total IP Length = 1457; Options = No Options
UDP: Src Port: Kerberos (88); Dst Port: Unknown (1676); Length = 1437 (0x59D)
KERBEROS: KRB_AS_REP
KERBEROS: Client realm (crealm[3]) =MULTI.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =aaa
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =aaa
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/MULTI.EXAMPLE.COM
*
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 7028; Total IP Length = 1436; Options = No Options
UDP: Src Port: Unknown (1677); Dst Port: Kerberos (88); Length = 1416 (0x588)
KERBEROS: KRB_TGS_REQ
KERBEROS: Pre-authentication Data (padata[3])
KERBEROS: Data type = PA-{AP|TGS}-REQ
KERBEROS: Ticket (ticket[3])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST
(Service & other unique instance)
KERBEROS: Principal name value (name-string[1]) =krbtgt/MULTI.EXAMPLE.COM
KERBEROS: Realm (realm[2]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[3]) =host/iis.multi.example.com
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_HST
(Serv with host name as instance)
KERBEROS: Principal name value (name-string[1]) =host/iis.multi.example.com
*
FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 14793; Total IP Length = 1422; Options = No Options
UDP: Src Port: Kerberos (88); Dst Port: Unknown (1677); Length = 1402 (0x57A)
KERBEROS: KRB_TGS_REP
KERBEROS: Client realm (crealm[3]) =MULTI.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =aaa
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =aaa
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =MULTI.EXAMPLE.COM
KERBEROS: Server name (sname[2]) =host/iis.multi.example.com
KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_HST (Serv with host name as instance)
KERBEROS: Principal name value (name-string[1]) =host/iis.multi.example.com

一个成功的登录将包含初始的 KRB_AS_REQ 和 KRB_AS_REP 来获取 TGT。（这只会在第一次身份验证时发生。在客户端拥有一个 TGT
之后，在此 TGT 过期之前协议将不会在请求 TGT。）在交换 AS 消息之后，对于用户尝试访问的任意服务都将有一个服务票证的 KRB_TGS_REQ 和
KRB_TGS_REP。请注意在此交换中可以查看领域名称、发出请求的用户名、时间以及 SPN。在诊断 kerberos
身份验证的问题时，此信息常常是必需的。上面例子的数据包在剪裁之后只显示了必需的数据。在真正的网络捕获中，将显示更多的数据，其中包括票证选项和加密类型等。

IIS 到 SQL 的委派
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 7646; Total IP Length = 351; Options = No Options
+ UDP: Src Port: Unknown (2415); Dst Port: Kerberos (88); Length = 331 (0x14B)
KERBEROS: KRB_AS_REQ
KERBEROS: Request body (req-body[4])
+ KERBEROS: Client name (cname[1]) =Administrator
KERBEROS: Realm (realm[2]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[3]) =krbtgt/DOMXFLXD1.EXAMPLE.COM
*
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 18180; Total IP Length = 1399; Options = No Options
+ UDP: Src Port: Kerberos (88); Dst Port: Unknown (2415); Length = 1379 (0x563)
KERBEROS: KRB_AS_REP
KERBEROS: Client realm (crealm[3]) =DOMXFLXD1.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =Administrator
KERBEROS: Principal name value (name-string[1]) =Administrator
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[2]) =krbtgt/DOMXFLXD1.EXAMPLE.COM
*
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 7647; Total IP Length = 1380; Options = No Options
+ UDP: Src Port: Unknown (2416); Dst Port: Kerberos (88); Length = 1360 (0x550)
KERBEROS: KRB_TGS_REQ
KERBEROS: Realm (realm[2]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[3]) =MSSQLSvc/xflxe3.domxflxd1.example.com:1433
***********************************
+ FRAME: Base frame properties
+ ETHERNET: EType = Internet IP (IPv4)
+ IP: Protocol = UDP - User Datagram; Packet ID = 18182; Total IP Length = 1370; Options = No Options
+ UDP: Src Port: Kerberos (88); Dst Port: Unknown (2416); Length = 1350 (0x546)
KERBEROS: KRB_TGS_REP
KERBEROS: Client realm (crealm[3]) =DOMXFLXD1.EXAMPLE.COM
KERBEROS: Client name (cname[4]) =Administrator
KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
KERBEROS: Principal name value (name-string[1]) =Administrator
KERBEROS: Ticket (ticket[5])
KERBEROS: Realm (realm[1]) =DOMXFLXD1.EXAMPLE.COM
+ KERBEROS: Server name (sname[2]) =MSSQLSvc/xflxe3.domxflxd1.example.com:1433

这是一个客户端请求特定服务（在此例中是 SQL Server）的票证的一个典型的例子。客户端（作为 Administrator
运行的发出此请求的计算机）首先从 KDC 请求一个 TGT。然后，请求一个 SQL Server 的 SPN 的票证。所有的 SQL SPN 都属于服务类
MSSQLSvc。这个特定的服务器在主机 xflxe3.domxflxd1.example.com 上运行。请求被批准，并且客户端收到一个给予其运行 SQL
Server 的服务器的票证的应答。

返回页首

附录 D：相关信息

•
Microsoft TechNet 上的“管理权限的身份验证”，位于：http://go.microsoft.com/fwlink/?LinkId=25038
•
Microsoft 知识库中的“Kerberos 常见问题解答”，位于：http://go.microsoft.com/fwlink/?LinkId=25039
•
Microsoft 知识库中的“Windows 2000 中的 Kerberos 用户身份验证协议概述”，位于：http://go.microsoft.com/fwlink/?LinkId=24922
•
Windows Server 2003 技术参考，位于：http://go.microsoft.com/fwlink/?LinkId=21711

感谢

Vincent Abella, Technical Editor, Microsoft Corporation

Leon Arber, University of Illinois at Urbana-Champaign

David Christiansen, Software Design Engineer, Microsoft Corporation

Mike Danseglio, Technical Writer, Microsoft Corporation

Xin Fan, Software Test Engineer, Microsoft Corporation

JK Jaganathan, Program Manager, Microsoft Corporation

Willis Johnson, Lead Programmer Writer, Microsoft Corporation

Steve Light, Escalation Engineer, Microsoft Corporation

David Longmuir, Technical Editor, Volt

Bala Neerumalla, Software Design Engineer, Microsoft Corporation

Michiko Short, Technical Writer, Microsoft Corporation

Tim Springston, Support Professional, Microsoft Corporation

Todd Stecher, Development Lead, Microsoft Corporation

Liqiang (Larry) Zhu, Software Design Engineer, Microsoft Corporation
本文链接

SPN	?	?	?
alerter	http	policyagent	scm
appmgmt	ias	protectedstorage	seclogon
browser	iisad	rasman	snmp
cifs	min	remoteaccess	spooler
cisvc	messenger	replicator	tapisrv
clipsrv	msiserver	rpc	time
dcom	mcsvc	rpclocator	trksvr
dhcp	netdde	rpcss	trkwks
dmserver	netddedsm	rsvp	ups
dns	netlogon	samss	w3svc
dnscache	netman	scardsvr	wins
eventlog	nmagent	scesrv	www
eventsystem	oakley	schedule
fax	plugplay

安全主体	计算机帐户对象	用户帐户对象
帐户创建者	已验证的对服务主体名称的写入	写入公共信息
自身	已验证的对服务主体名称的写入	无
帐户操作者	写入 servicePrincipalName 已验证的对服务主体名称的写入	写入公共信息
管理员	写入 servicePrincipalName 已验证的对服务主体名称的写入	写入公共信息
身份验证的用户	无	无

VPN 拨号，出现错误721,800的处理方案

2011-04-12T01:05:00Z

VPN 拨号，出现错误721,800的处理方案

客户机拨VPN出现721错误的解决办法：

局域网中的机器有的可以访问VPN服务器，有的不能，仔细检查，发现出问题的机器是打了SP2补丁。

解决办法如下(摘自微软网站)：

以下操作均在客户机上

1. 单击“开始”，然后单击“运行”。

2. 在“打开”框中，键入 regedit，然后单击“确定”。

3. 在注册表编辑器中，找到以下子项

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass{4D36E972-E325-11CE-BFC1-08002bE10318}<000x>

其中 <000x> 是 WAN 微型端口 (PPTP) 驱动程序的网络适配器。

4. 在“编辑”菜单上，指向“新建”，然后单击“DWORD 值”。

5. 键入 ValidateAddress，然后按 Enter。该值的默认设置为“1”（打开）；因此，您可以通过将其设置为“0”将其关闭。

6. 退出注册表编辑器。

7. 重新启动计算机。

windows 2000 /XP /2003 VPN 拨号，出现错误800的处理方案连接VPN隧道时发生错误 800：不能建立VPN连接的原因一般有以下几个： 1.检查配置中的目的地的主机名或IP地址使用的是域名而不是IP地址，由于VPN隧道需要定期进行维护，我们有可能变更VPN隧道服务器

windows 2000 /XP /2003 VPN 拨号，出现错误800的处理方案

连接VPN隧道时发生“错误 800：不能建立VPN连接”的原因一般有以下几个：

1.检查配置中的“目的地的主机名或IP地址”使用的是域名而不是IP地址，

由于VPN隧道需要定期进行维护，我们有可能变更VPN隧道服务器的IP地址，但域名不会改变。

2.您所在网络与我们的VPN隧道服务器没有正确的通道，

请尝试更换配置中的“目的地的主机名或IP地址”，将其调整为我们的登陆服务器IP地址或者域名。

3.临时性故障，多半是由于您使用的DNS服务器繁忙无法对服务器IP地址

或者域名的名字进行解析所引起，可以使用以下操作：开始->运行->打开：cmd->确定，执行命令ipconfig /flushdns后再进行VPN连接尝试。

4.由于配置异常造成的无法连接，虽然用户没有做过任何的配置修改，

但由于系统内部的故障会导致配置（注册表信息）出现异常，这是Windows系统中常见的问题。

处理方法是删除原VPN隧道连接的配置，重新建立一个新的VPN隧道连接即可。

5.检查连接的安全参数配置与配置要求一致。

6.您机器上的防火墙规则设置过于严格，导致无法对外进行连接，请调整或关闭所有防火墙再进行尝试。

7.如果有安装家庭网关的用户，也建议重启一下家庭网关设备。

另外一种情况：

由于Windows2000/XP/2003 系统缺省情况下启动了IPSec功能,因此在发起VPN请求时应禁止IPSec功能,需要更改注册表

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]

"ProhibitIPSec"=dword:00000001

修改后重启操作系统即可连通。

本文链接

This article provides a fix for the error: Login failed for user “. The user is not associated with a trusted SQL Server

2011-04-11T01:15:00Z

This article provides a fix for the error:

This error has several causes- one of which is an application or ODBC connection that is initiated from the same machine as the SQL server (ie the server is connecting to itself). The easiest fix for this is to temporarily or permanently disable the loopback check ….

Edit the registry using regedit. (start –> run … Regedit <Enter>)
Browse to : HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck”
Set this value to 1

You should now find that the connection will complete successfully. Another place to check is in event viewer. For this particular error we had 3 events logged in event viewer:

1. Failure Audit :: Login Failed for user ‘<DOMAIN>\<USERNAME>’. (CLIENT 127.0.0.1)

2. Error :: SSPI handshake failed with error code 0x8009030C while establishing a connection with integrated security; the connection has been closed. (CLIENT 127.0.0.1)

3. Failure Audit :: Login Failed for user “. (CLIENT 127.0.0.1)

The above steps resolve this issue.

Below is an article that discusses in more detail disabling the loopback check.

http://support.microsoft.com/kb/896861

本文链接

灾难恢复：当SQL Server 2005的sa密码丢失后

2011-03-23T07:20:00Z

灾难恢复：当SQL Server 2005的sa密码丢失后

原文地址：

http://blogs.msdn.com/b/raulga/archive/2007/07/12/disaster-recovery-what-to-do-when-the-sa-account-password-is-lost-in-sql-server-2005.aspx

参考：

http://msdn.microsoft.com/en-us/library/ms188236(en-US,SQL.90).aspx

http://msdn.microsoft.com/zh-cn/library/dd207004(v=SQL.100).aspx

本文所载方法，同样适用于SQL Server 2008

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

你也许面对过丢失SQL Server sa密码的情况。也许你有从sysadmin服务器角色中删除内建管理员（builtin\administrator）的好习惯，直到某一天你发现sysadmin角色下没人了（意味着SQL Server没管理员咯）。这时你可能会想唯一的选择就是重装SQL Server然后附加数据库，或者干脆直接访问master数据库文件——这些方法都有损坏数据的危险。

SQL Server 2005提供一个不错的针对此种情况的灾难恢复的方法，这种方法不需要侵入master数据库而且会保持master DB中的任何对象和数据存储（比如登录信息、用户凭据或服务主密钥等）的完整——当SQL Server以单用户模式启动，Windows管理员组中的成员都有权限访问SQL Server，这种模式也叫做“维护模式”。

通过单用户模式，SQL Server 2005提供一个可以让Windows管理员在无通知的情况下使用相当于sysadmin角色的权限。这就允许Windows管理员账户执行一些维护任务，比如安装补丁之类。

为了使SQL Server以单用户模式启动，你可以在命令行中加入“-m”参数。你也可以用SQL Server配置管理工具（SQL Server Configuration Manager Tool），它为文件访问和其他特权提供完全控制。如果希望使用该工具恢复你的数据库系统，请参照如下几步：

1.打开“SQL Server 2005配置”菜单下的SQL Server配置管理工具

2.停止你想要恢复的SQL Server实例，停止对应的SQL Server Agent服务

3.切换到“高级”选项卡，在“启动参数”选项的属性文本框末尾加入“;-m”

4.点击“确定”按钮，重启SQL Server实例

注意：请确保“;”和“-m”之间没有空格，注册参数解析器对这种问题十分敏感。你可以在ERRORLOG文件（在SQL Server安装文件夹中）中查看到“SQL Server Started in single-user mode”这样的记录。

5.SQL Server以单用户模式启动后，Windows管理员账户就可以使用sqlcmd实用程序通过Windows验证连接到SQL Server了。你可以使用Transact-SQL命令比如sp_addsrvrolemember添加已存在的登录用户（也可以新建一个只要你愿意）到sysadmin服务器角色。下面的例子添加了一个“CONTOSO”域下的“Buck”账号到sysadmin服务器角色。

EXEC sp_addsrvrolemember 'CONTOSO\Buck', 'sysadmin';

注意：要在Windows7中使用sqlcmd实用程序，需要以管理员身份运行Windows命令行。

6.一旦sysadmin权限恢复完成，请即在SQL Server配置管理工具中清除启动参数中的“;-m”，然后重新启动数据库实例。

重要安全提示：

本操作仅适合在没有任何其他方法可以以某种特权访问系统的情况下用来做灾难恢复。它需要能够被监控和发现的显式的和侵入性的操作，这包括：

l停止SQLServer并且用单用户模式重启动它

l通过Windows验证连接到SQL Server

本文链接

How to move databases between computers that are running SQL Server

2011-03-23T07:20:00Z

How to move databases between computers that are running SQL Server

http://support.microsoft.com/kb/314546/en-us

View products that this article applies to.

This article was previously published under Q314546

On This Page

· SUMMARY

o Step 1: How to move user databases

§ Method 1: Backup and restore the user databases

§ Method 2: Use the "sp_detach_db" and "sp_attach_db" stored procedures

§ Method 3: Use the Import and Export Data Wizard to copy objects and data between SQL Server databases

o Step 2: How to transfer logins and passwords

o Step 3: How to resolve orphaned users

o Step 4: How to move jobs, alerts, and operators

o Step 5: How to move DTS packages

§ Method 1

§ Method 2

o Step 6: Change the sp_configure settings to match the previous system

· MORE INFORMATION

· REFERENCES

Expand all | Collapse all

SUMMARY

This step-by-step article describes how to move Microsoft SQL Server user databases and most common SQL Server components between computers that are running SQL Server.

The steps that are described in this article assume that you will not move the master, model, tempdb, or msdb system databases. The steps provide different options for you to transfer logins and the most common components that are contained in the master and msdb databases.

For information about the specific items not transferred when you follow the steps in this article, see the "More information" section.

Note For Microsoft SQL Server 2008, refer to the "Managing Metadata When Making a Database Available on Another Server Instance" topic at the following in SQL Server 2008 Books on Line Web site:

http://msdn.microsoft.com/en-us/library/ms187580.aspx

Note Data migration from SQL Server 2000 to Microsoft SQL Server 2000 (64-bit) is supported. You can attach a 32-bit database to a 64-bit database by using the sp_attach_db system stored procedure or the sp_attach_single_file_db system stored procedure, or by using backup and restore in the 32-bit Enterprise Manager. You can move databases back and forth between the 32-bit and the 64-bit versions of SQL Server. You can also migrate data from SQL Server 7.0 by using the same methods. However, downgrading data to SQL Server 7.0 from SQL Server 2000 (64-bit) is not supported. A description of each method follows.

Back to the top

Step 1: How to move user databases

If you are using SQL Server 2005, you can use the same method to migrate data from SQL Server 7.0 or from SQL Server 2000. However, the management tool in Microsoft SQL Server 2005 differs from the management tool in SQL Server 7.0 or in SQL Server 2000. You should use SQL Server Management Studio instead of the SQL Server Enterprise Manager. Additionally, you should use the SQL Server Import and Export Wizard (DTSWizard.exe) instead of the Data Transformation Services Import and Export Data Wizard.

To move user databases, use one of the following three methods.

Method 1: Backup and restore the user databases

Back up the user databases on the source server, and then restore the user databases to the destination server.

· The database can be used when the backup is in process. If users perform INSERT, UPDATE, or DELETE statements on the database after the backup is complete, the backup will not contain these changes. If you must transfer all changes, you can transfer the changes with minimal downtime if you perform both a transaction log backup and a full database backup.

1. Restore the full database backup on the destination server and specify the WITH NORECOVERY option.

Note To prevent additional database modifications, direct users to quit database activity on the source server.

2. Perform a transaction log backup and restore the transaction log backup to the destination server by using the WITH RECOVERY option. Downtime is limited to the time of the transaction log backup and restore. For more information, see the "RESTORE" sub-topic in the "Transact-SQL Reference" topic of SQL Server Books Online.

· The database on the destination server will be the same size as the database on the source server. To reduce the size of the database, you must either reduce the source database before you perform the backup, or reduce the destination database after the restore is completed. For more information, see the "Shrinking a Database" sub-topic in the "Creating and Maintaining Databases" heading of SQL Server Books Online.

· If you restore the database to a different file location than the source database, you must specify the WITH MOVE option. For example, on the source server the database is in the D:\Mssql\Data folder. The destination server does not have a D drive, and you want to restore the database to the C:\Mssql\Data folder. For more information about how to restore a database to a different location, click the following article numbers to view the articles in the Microsoft Knowledge Base:

221465 Using the WITH MOVE option with the RESTORE statement

304692 Moving SQL Server 7.0 databases to a new location with BACKUP and RESTORE

· If you want to overwrite a preexisting database on the destination server, you must specify the WITH REPLACE option. For more information, see the "RESTORE" sub-topic in the "Transact-SQL Reference" topic of SQL Server Books Online.

· Depending on the version of SQL Server to which you restore, the character set, sort order, and Unicode collation may have to be the same on both the source and destination servers. For more information, see the "Note about collation" later in this section.

Method 2: Use the "sp_detach_db" and "sp_attach_db" stored procedures

To use the sp_detach_db and sp_attach_db stored procedures, follow these steps:

1. Detach the database on the source server by using the sp_detach_db stored procedure. You must copy the .mdf, .ndf and .ldf files associated with the database to the destination server. See this table for a description of the file types:

File name extension	Description
.mdf	Primary data file
.ndf	Secondary data file
.ldf	Transaction log file

2. Attach the database on the destination server by using the sp_attach_db stored procedure and point to the files you copied to the destination server in the previous step. For more information about how to use these methods, click the following article number to view the article in the Microsoft Knowledge Base:

224071 How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server

· The database is inaccessible after the detach, and you cannot use the database when you copy the files. All data that is contained in the database at the point in time of the detach is moved.

· The character set, sort order, and Unicode collation may have to be the same on both servers when you use the Attach or Detach method. For more information, see the following note about collation.

Note about collation If you move databases between SQL Server 7.0 servers by using the backup and restore or Attach and Detach methods, the character set, sort order and Unicode collation must be the same on both servers. If you move databases from SQL Server 7.0 to SQL Server 2000 or between SQL Server 2000 servers, the database maintains the collation of the source database. This means that if the destination server that is running SQL Server 2000 has a different collation than the source database, the destination database has a different collation than the destination server's master, model, tempdb, and msdb databases. For more information, see the "Mixed Collation Environments" topic in SQL Server 2000 Books Online.

Method 3: Use the Import and Export Data Wizard to copy objects and data between SQL Server databases

You can copy a whole database or selectively copy objects and data from the source database to the destination database by using the Data Transformation Services Import and Export Data Wizard.

· The source database may be used during the transfer. If the source database is used during the transfer, you may see some blocking when the transfer is in progress.

· When you use the Import and Export Data Wizard, the character set, sort order and collation does not have to be the same between the source server and destination server.

· Because unused space in the source database does not move, the destination database may not have to be as large as the source database. Similarly, if you move only some objects, the destination database may not have to be as large as the source database.

· SQL Server 7.0 Data Transformation Services may not transfer text and image data longer than 64 KB correctly. This problem does not apply to the SQL Server 2000 version of Data Transformation Services. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

257425 FIX: DTS Object Transfer does not transfer BLOB data greater than 64 KB

Back to the top

Step 2: How to transfer logins and passwords

If you do not transfer the logins from the source server to the destination server, your current SQL Server users may be unable to log on to the destination server. You can transfer the logins and passwords by using the instructions in the following Microsoft Knowledge Base article:

246133 How to transfer logins and passwords between instances of SQL Server

The default databases for the logins on the destination server may be different from the default database for the logins on the source server. You can change the default database for a logon with the sp_defaultdb stored procedure. For more information, see the "sp_defaultdb" sub-topic of the "Transact-SQL Reference" topic in SQL Server Books Online.

Back to the top

Step 3: How to resolve orphaned users

After you transfer logins and passwords to the destination server, users may be unable to access the database. Logins are associated to users by the security identifier (SID), and if the SID is inconsistent after you move a database, SQL Server may deny the user access to the database. This problem is known as an orphaned user. If you transfer logins and passwords by using the SQL Server 2000 DTS Transfer Login feature, you will probably have orphaned users. Additionally, integrated logins granted access on a destination server in a different domain than the source server cause orphaned users.

1. Look for orphaned users. Open Query Analyzer on the destination server, and then run the following code in the user database that you moved:

exec sp_change_users_login 'Report'

The procedure lists any orphaned users who do not link to a logon. If no users are listed, skip step 2 and step 3 and go to step 4.

2. Resolve the orphaned users. If a user is orphaned, database users can log on to the server successfully but will not have permission to access the database. If you try to grant the logon access to the database, you receive the following error message because the user already exists:

Microsoft SQL-DMO (ODBC SQLState: 42000) Error 15023: User or role '%s' already exists in the current database.

For more information about how to resolve orphaned users, click the following article numbers to view the articles in the Microsoft Knowledge Base:

240872 How to resolve permission issues when you move a database between servers that are running SQL Server

This article contains instructions about how to map the logins to the database users and resolves users orphaned from standard SQL Server logins and integrated logins.

274188 "Troubleshooting Orphaned Users" topic in Books Online is incomplete

This article describes how to use the sp_change_users_login stored procedure to correct the orphaned users one by one. The sp_change_users_login stored procedure only resolves users orphaned from standard SQL Server logins.

3. If the database owner (dbo) is listed as orphaned, run this code in the user database:

exec sp_changedbowner 'sa'

The stored procedure changes the database owner to dbo and corrects the issue. To change the database owner to another user, run sp_changedbowner again with the user you want. For more information, see the "sp_changedbowner" sub-topic in the "Transact-SQL Reference" topic of SQL Server Books Online.

4. If your destination server is running SQL Server 2000 Service Pack 1, the database owner user may not be in the list in the Users folder in Enterprise Manager after you perform the attach or restore or both. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

305711 BUG: DBO user does not display in Enterprise Manager

5. You may receive the following error message if you try to change the system administrator (sa) password through Enterprise Manager if the logon that was mapped to dbo on the source server does not exist on the destination server:

Error 21776: [SQL-DMO] The name 'dbo' was not found in the Users collection. If the name is a qualified name, use [] to separate various parts of the name, and try again.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

218172 Cannot change SA password in Enterprise Manager

Warning If you restore or attach the database again, the database users may be re-orphaned and you have to repeat step 3.

Back to the top

Step 4: How to move jobs, alerts, and operators

Step 4 is optional. You can generate scripts for all jobs, alerts and operators on the source server, and then run the script on the destination server.

· To move jobs, alerts and operators, follow these steps:

1. Open the SQL Server Enterprise Manager, and then expand the Management folder.

2. Expand SQL Server Agent, and then either right-click Alerts, Jobs, or Operators.

3. Click All Tasks, and then click Generate SQL Script. For SQL Server 7.0, click Script All Jobs, or Alerts, or Operators.

You will have the option to generate scripts for All Alerts, All Jobs or All Operators based on the item you right-click.

· You can move jobs, alerts and operators from SQL Server 7.0 to SQL Server 2000 or between computer servers that are running SQL Server 7.0 and SQL Server 2000.

· If you have operators that are set up for notification by SQLMail on the source server, you have to set up SQLMail on the destination server to have the same functionality. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

263556 How to configure SQL Mail

Back to the top

Step 5: How to move DTS packages

Step 5 is optional. If DTS packages are stored on the source server in the SQL Server or the repository, you can move them if you want. To move DTS packages between servers, use one of the following methods.

Method 1

1. Save the DTS package on the source server to a file, and then open the DTS package file on the destination server.

2. Save the package on the destination server to the SQL Server, or to the repository.
Note You have to move each package one by one in separate files.

Method 2

1. Open each DTS package in the DTS Designer.

2. On the Package menu, click Save As.

3. Specify the destination SQL Server.

Note The package may not run correctly on the new server. You may have to change the package, and change any references in the package to connections, files, data sources, profiles and other information that is located on the old source server, to reference the new destination server. You must make these changes on a package by package basis based on the design of each package.

Back to the top

Step 6: Change the sp_configure settings to match the previous system

You may have to change the settings so that they match the settings in the new system. For example, if the new system has more memory or if it is running different SQL instances and applications, you may want to change the min and max server memory settings or the AWE setting. You may have to change the MAXDOP setting if the number of CPU cores that are exposed to the operating system have changed.

Back to the top

MORE INFORMATION

You may also want to move other items such as linked servers, mirroring, replication, log shipping, full-text catalogs, named backup devices, maintenance plans, database diagrams, database snapshots, credentials and proxy accounts, endpoints, server scoped DDL triggers (such as a logon trigger), or other items involving either master or msdb. Examine the source server for these configurations and take steps to set them up manually on the destination server, if you want.

For more information about how to move full text components, click the following article number to view the article in the Microsoft Knowledge Base:

240867 How to move, copy, and back up full-text catalog folders and files

Database diagrams and backup and restore history are not moved if you follow the steps in this article. If you must move this information, move the msdb system database. For information about how to move the msdb database, see the Microsoft Knowledge Base articles that are referenced in the "Step 1: How to move user databases" section. If you move the msdb database, you do not have to follow "Step 4: How to move jobs, alerts, and operators" or "Step 5: How to move DTS packages."

Back to the top

REFERENCES

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

320125 How to move a database diagram

How to transfer the logins and the passwords between instances of SQL Server 2005 and SQL Server 2008

http://support.microsoft.com/kb/918992/en-us

View products that this article applies to.

On This Page

· INTRODUCTION

· MORE INFORMATION

o Remarks

· REFERENCES

Expand all | Collapse all

INTRODUCTION

This article describes how to transfer the logins and the passwords between instances of Microsoft SQL Server 2005, and Microsoft SQL Server 2008, on different servers.

For more information about how to transfer the logins and the passwords between instances of other versions of SQL Server, click the following article number to view the article in the Microsoft Knowledge Base:

246133 How to transfer logins and passwords between instances of SQL Server

Back to the top

MORE INFORMATION

In this article, server A and server B are different servers. Additionally, both server A and server B are running SQL Server 2005.

Note This information also applies to SQL Server 2008.

After you move a database from the instance of SQL Server on server A to the instance of SQL Server on server B, the users may not be able to log in to the database on server B. Additionally, the users may receive the following error message:

This problem occurs because you did not transfer the logins and the passwords from the instance of SQL Server on server A to the instance of SQL Server on server B.

To transfer the logins and the passwords from the instance of SQL Server on server A to the instance of SQL Server on server B, follow these steps:

1. On server A, start SQL Server Management Studio, and then connect to the instance of SQL Server from which you moved the database.

2. Open a new Query Editor window, and then run the following script.

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

USE master

IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL

DROP PROCEDURE sp_hexadecimal

CREATE PROCEDURE sp_hexadecimal

@binvalue varbinary(256),

@hexvalue varchar (514) OUTPUT

DECLARE @charvalue varchar (514)

DECLARE @i int

DECLARE @length int

DECLARE @hexstring char(16)

SELECT @charvalue = '0x'

SELECT @i = 1

SELECT @length = DATALENGTH (@binvalue)

SELECT @hexstring = '0123456789ABCDEF'

WHILE (@i <= @length)

BEGIN

DECLARE @tempint int

DECLARE @firstint int

DECLARE @secondint int

SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))

SELECT @firstint = FLOOR(@tempint/16)

SELECT @secondint = @tempint - (@firstint*16)

SELECT @charvalue = @charvalue +

SUBSTRING(@hexstring, @firstint+1, 1) +

SUBSTRING(@hexstring, @secondint+1, 1)

SELECT @i = @i + 1

END

SELECT @hexvalue = @charvalue

IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL

DROP PROCEDURE sp_help_revlogin

CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS

DECLARE @name sysname

DECLARE @type varchar (1)

DECLARE @hasaccess int

DECLARE @denylogin int

DECLARE @is_disabled int

DECLARE @PWD_varbinary varbinary (256)

DECLARE @PWD_string varchar (514)

DECLARE @SID_varbinary varbinary (85)

DECLARE @SID_string varchar (514)

DECLARE @tmpstr varchar (1024)

DECLARE @is_policy_checked varchar (3)

DECLARE @is_expiration_checked varchar (3)

DECLARE @defaultdb sysname

IF (@login_name IS NULL)

DECLARE login_curs CURSOR FOR

SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM

sys.server_principals p LEFT JOIN sys.syslogins l

ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name <> 'sa'

ELSE

DECLARE login_curs CURSOR FOR

SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM

sys.server_principals p LEFT JOIN sys.syslogins l

ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_name

OPEN login_curs

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin

IF (@@fetch_status = -1)

BEGIN

PRINT 'No login(s) found.'

CLOSE login_curs

DEALLOCATE login_curs

RETURN -1

END

SET @tmpstr = '/* sp_help_revlogin script '

PRINT @tmpstr

SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'

PRINT @tmpstr

PRINT ''

WHILE (@@fetch_status <> -1)

BEGIN

IF (@@fetch_status <> -2)

BEGIN

PRINT ''

SET @tmpstr = '-- Login: ' + @name

PRINT @tmpstr

IF (@type IN ( 'G', 'U'))

BEGIN -- NT authenticated account/group

SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ']'

END

ELSE BEGIN -- SQL Server authentication

-- obtain password and sid

SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )

EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT

EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT

-- obtain password policy state

SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name

SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name

SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ']'

IF ( @is_policy_checked IS NOT NULL )

BEGIN

SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked

END

IF ( @is_expiration_checked IS NOT NULL )

BEGIN

SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked

END

IF (@denylogin = 1)

BEGIN -- login is denied access

SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )

END

ELSE IF (@hasaccess = 0)

BEGIN -- login exists but does not have access

SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )

END

IF (@is_disabled = 1)

BEGIN -- login is disabled

SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'

END

PRINT @tmpstr

END

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin

END

CLOSE login_curs

DEALLOCATE login_curs

RETURN 0

Note This script creates two stored procedures in the master database. The two stored procedures are named the sp_hexadecimal stored procedure and the sp_help_revlogin stored procedure.

3. Run the following statement.

EXEC sp_help_revlogin

The output script that is generated by the sp_help_revlogin stored procedure is the login script. This login script creates the logins that have the original Security Identifier (SID) and the original password.

4. On server B, start SQL Server Management Studio, and then connect to the instance of SQL Server to which you moved the database.

Important Before you go to step 5, review the information in the "Remarks" section.

5. Open a new Query Editor window, and then run the output script that is generated in step 3.

Back to the top

Remarks

Review the following information before you run the output script on the instance on server B:

· Review the output script carefully. If server A and server B are in different domains, you have to modify the output script. Then, you have to replace the original domain name with the new domain name in the CREATE LOGIN statements. The integrated logins that are granted access in the new domain do not have the same SID as the logins in the original domain. Therefore, the users are orphaned from these logins. For more information about how to resolve these orphaned users, click the following article number to view the article in the Microsoft Knowledge Base:

240872 How to resolve permission issues when you move a database between servers that are running SQL Server

If server A and server B are in the same domain, the same SID is used. Therefore, the users are not likely to be orphaned.

· In the output script, the logins are created by using the encrypted password. This is because of the HASHED argument in the CREATE LOGIN statement. This argument specifies that the password that is entered after the PASSWORD argument is already hashed.

· By default, only a member of the sysadmin fixed server role can run a SELECT statement from the sys.server_principals view. Unless a member of the sysadmin fixed server role grants the necessary permissions to the users, the users cannot create or run the output script.

· The steps in this article do not transfer the default database information for a particular login. This is because the default database may not always exist on server B. To define the default database for a login, use the ALTER LOGIN statement by passing in the login name and the default database as arguments.

· The sort order of server A may be case insensitive, and the sort order of server B may be case sensitive. In this case, the users must type all the letters in the passwords as uppercase letters after you transfer the logins and the passwords to the instance on server B.

Alternatively, the sort order of server A may be case sensitive, and the sort order of server B may be case insensitive. In this case, the users cannot log in by using the logins and the passwords that you transfer to the instance on server B unless one of the following conditions is true:

o The original passwords contain no letters.

o All the letters in the original passwords are uppercase letters.

The sort order of both server A and server B may be case sensitive, or the sort order of both server A and server B may be case insensitive. In these cases, the users do not experience a problem.

· A login that already is in the instance on server B may have a name that is the same as a name in the output script. In this case, you receive the following error message when you run the output script on the instance on server B:

Msg 15025, Level 16, State 1, Line 1
The server principal 'MyLogin' already exists.

Similarly, a login that already is in the instance on server B may have a SID that is the same as a SID in the output script. In this case, you receive the following error message when you run the output script on the instance on server B:

Msg 15433, Level 16, State 1, Line 1
Supplied parameter sid is in use.

Therefore, you must do the following:

1. Review the output script carefully.

2. Examine the contents of the sys.server_principals view in the instance on server B.

3. Address these error messages accordingly.

· In SQL Server 2005, the SID for a login is used as the basis for implementing database-level access. A login may have two different SIDs in two different databases on a server. In this case, the login can only access the database that has the SID that matches the SID in the sys.server_principals view. This problem may occur if the two databases are consolidated from two different servers. To resolve this problem, manually remove the login from the database that has a SID mismatch by using the DROP USER statement. Then, add the login again by using the CREATE USER statement.

Back to the top

REFERENCES

For more information about how to troubleshoot orphaned users, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/ms175475.aspx

For more information about the CREATE LOGIN statement, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/ms189751.aspx

For more information about the ALTER LOGIN statement, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/ms189828.aspx

How to resolve permission issues when you move a database between servers that are running SQL Server

http://support.microsoft.com/kb/240872/en-us

View products that this article applies to.

This article was previously published under Q240872

On This Page

· SUMMARY

· MORE INFORMATION

o Restrictions

o Map the standard and integrated logins

o SQL Server 7.0 and SQL Server 2000

o SQL Server 2005

· REFERENCES

Expand all | Collapse all

SUMMARY

This article describes how to map the standard and integrated logins in order to resolve permission issues when you move a database between servers that are running SQL Server.

Back to the top

MORE INFORMATION

When you move a database from one server that is running SQL Server to another server that is running SQL Server, a mismatch may occur between the security identification numbers (SIDs) of the logins in the master database and the users in the user database. By default, SQL Server 7.0, SQL Server 2000, and SQL Server 2005 provide the sp_change_users_login system stored procedure to map these mismatched users. However, you can only use the sp_change_users_login stored procedure to map standard SQL Server logins and you must perform these mapping for one user at a time. For more information about the sp_change_users_login stored procedure, see the "sp_change_users_login" topic in SQL Server 7.0,SQL Server 2000, and SQL Server 2005 Books Online.

In SQL Server 7.0 or later versions, you can maintain the mapping between the logins in the master database and the users in the user database by using the SIDs. This mapping is required to maintain correct permissions for the logins in the user databases. When this mapping is lost, the logins have permission issues that include but are not limited to the following:

· If the SQL Server login does not exist on the new server, and the user tries to log on, the user may receive the following error message:

Server: Msg 18456, Level 16, State 1
Login failed for user '%ls'.

· If the SQL Server login exists on the new server, but the SID in the master database differs from the SID in the user database, the user can log on to SQL Server successfully; however, when the user tries to access that database, the user may receive the following error message:

Server: Msg 916, Level 14, State 1, Line1
Server user '%.*ls' is not a valid user in database '%.*ls'.

Note In SQL Server 2005, the user may receive the following error message:

Server user '%s' is not a valid user in database '%s'. Add the user account into the database first.

For more information about the SQL Server 7.0 Security model, see the "Microsoft SQL Server 7.0 Security" white paper. To view the white paper, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/Aa226173(SQL.70).aspx

For more information about the SQL Server 2000 Security model, click the following article number to view the article in the Microsoft Knowledge Base:

322712 Microsoft SQL Server 2000 S322712 Security Features and Best Practices

Back to the top

Restrictions

· If there are users in the sysusers table without a prefix of the computer name or the domain name that own objects, and these objects are referenced in applications by using the two-part name username.objectname, the application may break because the sp_sidmap stored procedure renames these users with the prefix of the computer name or domain name as it appears in the sysxlogins table. To work around this problem, after the sp_sidmap stored procedure is completed, rename the users who were affected in the sysusers table to their former names or contact your primary support provider.

· This article does not consider aliases. You must manage the aliases manually.

· If a standard SQL Server login does not exist on the new SQL Server server, you can add the login with a NULL password. You may have to change the password for these logins accordingly.

· If a user was created in the user database with a name that differs from that which appears in the sysxlogins table, it is impossible to know the corresponding login for that user. Therefore, before you run the sp_sidmap stored procedure:

1. Transfer all the objects that this user owns to a staging database.

2. Drop the user, add the user that has the correct name, and then transfer back all the objects for this user.

· If a user has neither a corresponding login nor a prefix of either the local computer name or the domain name, you receive a message for this user. This message indicates that you must first add the user at the Windows level and then add it to the SQL Server as a login. After you do this, you must run the sp_sidmap stored procedure again.

· If a user has a prefix of either the domain name or the local Windows server name, but the corresponding login does not exist in the sysxlogins table, the stored procedure tries to add this as a new login to SQL Server. If the Windows user does not exist, it generates an output message in the results window and then manually creates the login after it first adds the Windows user.

· If there is more than one login for a user in the sysusers table, you see an output message in the results file and it lists all the logins that have the same username. At this point, you must manually intervene to make sure that the user corresponds to only one login.

Example If the sysusers table has a user named "johndoe" and the sysxlogins table has logins with names such as "Test\johndoe" and "Test2\johndoe", when you run the stored procedure, you receive a message that states that one of the users has more than one login and that the System Administrator must choose one. This is the only time that you must run the second stored procedure, sp_prefix_sysusersname, which is provided in this article. Additionally, this situation is described in detail in the Readme.txt file.

Back to the top

Map the standard and integrated logins

After you move a database from one server that is running SQL Server server to another server that is running SQL Server server, follow these steps for minimal user intervention:

Back to the top

SQL Server 7.0 and SQL Server 2000

1. Make sure that there is a login in the sysxlogins table in the master database for each user in the sysusers table of the database.

Note To add a standard SQL Server login, see the "sp_addlogin" topic in SQL Server Books Online. To add an integrated SQL Server login, see the "sp_grantlogin" topic in SQL Server Books Online.

2. Download the MapSids.exe file, and then extract the Sp_sidmap.sql and Readme.txt files.

3. Log on to the server that is running SQL Server as a system administrator, and then run the Sp_sidmap.sql file in the user database. Running the Sp_sidmap.sql file creates the two stored procedures, sp_sidmap and sp_prefix_sysusersname.

4. Make sure that the database is not accessed by any other user than the one who is running the stored procedures.

5. Make sure that Query Analyzer displays results in text format and not in grid format. To do this, either press the CTRL^T keys, or click Query, and then click Results in Text. This is very important so that you can view the results and the informational messages in one window and save the output to a text file. You might need this file later to resolve some of the mappings.

6. Because you cannot verify whether the parameters are passed correctly, make sure to pass them correctly to the sp_sidmap stored procedure:

EXEC sp_SidMap @old_domain = old_domain_name,

@new_domain = new_domain_name,

@old_server = old_server_name,

@new_server = new_server_name

Replace the values for the old and new domain names and server names appropriately.

7. Save the results in a file and follow the directions that are provided in the Readme.txt file.

Note When you run these stored procedures, the sysusers table is the only table that changes in the database. To return to a state where you started, restore the database from the backup or reattach the database.

Back to the top

SQL Server 2005

If you are running SQL Server 2005, use the WITH LOGIN clause of the ALTER USER statement to remap a user to a new login. For more information, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn.microsoft.com/en-us/library/ms176060.aspx

Note To use the WITH LOGIN clause of the ALTER USER statement, you must apply SQL Server 2005 Service Pack 2.

Back to the top

REFERENCES

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

274188 "Troubleshooting orphaned users" topic in Books Online is incomplete

246133 How to transfer logins and passwords between instances of SQL Server

168001 User logon and/or permission errors after restoring dump

298897 SAMPLE: Mapsids.exe Helps Map SIDs Between User and Master Databases When Database Is Moved

How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server

http://support.microsoft.com/kb/224071/en-us

View products that this article applies to.

This article was previously published under Q224071

On This Page

· SUMMARY

· MORE INFORMATION

o Prerequisites

o Moving user databases

o Moving sample databases

o Moving the model database

§ SQL Server 7.0

§ SQL Server 2005 and SQL Server 2000

o Moving the MSDB database

§ SQL Server 7.0

§ SQL Server 2005 and SQL Server 2000

o Moving the master database

§ SQL Server 7.0 and SQL Server 2000

§ SQL Server 2005

o Moving the tempdb database

· REFERENCES

Expand all | Collapse all

SUMMARY

This article describes how to change the location of the data files and of the log files for any Microsoft SQL Server 2005, SQL Server 2000, or SQL Server 7.0 database.

For more information about how to move system databases in SQL Server 2008, see the "Moving System Databases" topic in SQL Server Books Online. To view this topic, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/ms345408.aspx

Back to the top

MORE INFORMATION

The steps that you must follow to change the location for some SQL Server system databases differ from the steps that you must follow to change the location for user databases. These special cases are described separately.

Note SQL Server 7.0 system databases are not compatible with SQL Server 2000. Do not attach SQL Server 7.0 master, model, msdb or distribution databases to SQL Server 2000. If you are using SQL Server 2005, you can only attach databases of SQL Server 2005 to an instance. All the examples in this article assume that SQL Server is installed in the D:\Mssql7 folder. Additionally, the examples assume that all data files and log files are located in the default D:\Mssql7\Data folder. The examples move the data files and the log files for all the databases to the E:\Sqldata folder.

The default data location for SQL 2000 and 2005 editions are as follows:

· For SQL Server 2000 32 bit editions, visit the following MSDN Web site:
http://msdn.microsoft.com/en-us/library/aa176560(SQL.80).aspx

· For SQL Server 2000 64 bit editions, visit the following MSDN Web site:
http://msdn.microsoft.com/en-us/library/aa274567(SQL.80).aspx

· For SQL Server 2005 editions, visit the following MSDN Web site:
http://msdn.microsoft.com/en-us/library/ms143547(SQL.90).aspx

Back to the top

Prerequisites

· Make a current backup of all databases, especially the master database, from their current location.

· You must have system administrator (sa) permissions.

· You must know the name and the current location of all data files and log files for the database.

Note You can determine the name and the current location of all files that a database uses by using the sp_helpfile stored procedure:

use <database_name>

sp_helpfile

· You should have exclusive access to the database that you are moving. If you experience problems during the process, and if you cannot access a database that you have moved or if you cannot start SQL Server, examine the SQL Server error log and SQL Server Books Online for more information about the errors that you are experiencing.

Back to the top

Moving user databases

The following example moves a database that is named mydb. This database contains one data file, Mydb.mdf, and one log file, Mydblog.ldf. If the database that you are moving has more data files or log files, specify the files in a comma-delimited list in the sp_attach_db stored procedure. The sp_detach_db procedure does not change regardless of how many files the database contains because the sp_detach_db procedure does not list the files.

1. Detach the database as follows:

use master

sp_detach_db 'mydb'

2. Next, copy the data files and the log files from the current location (D:\Mssql7\Data) to the new location (E:\Sqldata).

3. Re-attach the database. Point to the files in the new location as follows:

use master

sp_attach_db 'mydb','E:\Sqldata\mydbdata.mdf','E:\Sqldata\mydblog.ldf'

Verify the change in file locations by using the sp_helpfile stored procedure:

use mydb

sp_helpfile

The filename column values should reflect the new locations.

Note Microsoft Knowledge Base article 922804 describes an issue for SQL Server 2005 databases on a network-attached storage. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

922804 FIX: After you detach a Microsoft SQL Server 2005 database that resides on network-attached storage, you cannot reattach the SQL Server database

Consider this issue. Additionally, consider the permissions that are applied to a database when it is detached in SQL Server 2005. For more information, see the "Detaching and Attaching a Database" section of the "Securing Data and Log Files" topic in SQL Server Books Online. To view this topic, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/ms189128.aspx

Back to the top

Moving sample databases

To move the pubs sample database and the Northwind sample database in SQL Server 2000 or in SQL Server 7.0, or to move the AdventureWorks sample database and the AdventureWorksDW sample database in SQL Server 2005, follow the same procedure for moving user databases.

Back to the top

Moving the model database

SQL Server 7.0

1. Make sure that the SQL Server Agent is not currently running.

2. Follow the same procedure for moving user databases.

SQL Server 2005 and SQL Server 2000

In SQL Server 2005 and in SQL Server 2000, you cannot detach system databases by using the sp_detach_db stored procedure. When you try to run the sp_detach_db 'model' statement, you receive the following error message:

Server: Msg 7940, Level 16, State 1, Line 1
System databases master, model, msdb, and tempdb cannot be detached.

To move the model database, you must start SQL Server together with the -c option, the -m option, and trace flag 3608. Trace flag 3608 prevents SQL Server from recovering any database except the master database.

Note You will not be able to access any user databases after you do this. You must not perform any operations, other than the following steps, while you use this trace flag. To add trace flag 3608 as a SQL Server startup parameter on SQL Server 2000, follow these steps:

1. In SQL Server Enterprise Manager, right-click the server name, and then click Properties.

2. On the General tab, click Startup Parameters.

3. Add the following new parameter:

-c -m -T3608

If you are using SQL Server 2005, you can use SQL Server Configuration Manager to change the startup parameters of the SQL Server service. For more information about how to change the startup parameters, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/ms190737.aspx

After you add the -c option, the -m option, and trace flag 3608, follow these steps:

1. Stop and then restart SQL Server.

2. Detach the model database by using the following commands:

use master

sp_detach_db 'model'

3. Move the Model.mdf and Modellog.ldf files from the D:\Mssql7\Data folder to the E:\Sqldata folder.

4. Reattach the model database by using the following commands:

use master

sp_attach_db 'model','E:\Sqldata\model.mdf','E:\Sqldata\modellog.ldf'

5. Remove -c -m -T3608 from the startup parameters in SQL Server Enterprise Manager or in SQL Server Configuration Manager.

6. Stop and then restart SQL Server. You can verify the change in file locations by using the sp_helpfile stored procedure. For example, use the following command:

use model

sp_helpfile

Back to the top

Moving the MSDB database

SQL Server 7.0

Note If you are using this procedure while moving the msdb and model databases, you must reattach the model database first, and then reattach the msdb database. Follow these steps:

1. Make sure that the SQL Server Agent is not currently running.

2. Follow the same procedure for moving user databases.

Note If SQL Server Agent is running, the sp_detach_db stored procedure will not succeed and you will receive the following message:

Server: Msg 3702, Level 16, State 1, Line 0
Cannot drop the database 'msdb' because it is currently in use.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

SQL Server 2005 and SQL Server 2000

To move the MSDB database, you must start SQL Server together with the -c option, the -m option, and trace flag 3608. Trace flag 3608 prevents SQL Server from recovering any database except the master database. To add the -c option, the -m option, and trace flag 3608, follow the steps in the "Moving the model database" section. After you add the -c option, the -m option and trace flag 3608, follow these steps:

1. Stop, and then restart SQL Server.

2. Make sure that the SQL Server Agent service is not currently running.

3. Detach the msdb database as follows:

use master

sp_detach_db 'msdb'

4. Move the Msdbdata.mdf and Msdblog.ldf files from the current location (D:\Mssql8\Data) to the new location (E:\Mssql8\Data).

5. Remove -c -m -T3608 from the startup parameters box in Enterprise Manager.

6. Stop and then restart SQL Server.

Note If you try to reattach the msdb database by starting SQL Server together with the -c option, the -m option, and trace flag 3608, you may receive the following error message:

Server: Msg 615, Level 21, State 1, Line 1
Could not find database table ID 3, name 'model'.

7. Reattach the msdb database as follows:

use master

sp_attach_db 'msdb','E:\Mssql8\Data\msdbdata.mdf','E:\Mssql8\Data\msdblog.ldf'

Note If you use this procedure together with moving the model database, you are trying to detach the msdb database while you detach the model database. When you do this, you must reattach the model database first, and then reattach the msdb database. If you reattach the msdb database first, you receive the following error message when you try to reattach the model database:

Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.

In this case, you must detach the msdb database, reattach the model database, and then reattach the msdb database,

After you move the msdb database, you may receive the following error message:

Error 229: EXECUTE permission denied on object 'ObjectName', database 'master', owner 'dbo'.

This problem occurs because the ownership chain has been broken. The database owners for the msdb database and for the master database are not the same. In this case, the ownership of the msdb database had been changed. To work around this problem, run the following Transact-SQL statements. You can do this by using the Osql.exe command-line utility (SQL Server 7.0 and SQL Server 2000) or the Sqlcmd.exe command-line utility (SQL Server 2005):

USE MSDB

EXEC sp_changedbowner 'sa'

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

272424 Object ownership chain checking across databases depends on the login that is mapped to the object owners

Back to the top

Moving the master database

SQL Server 7.0 and SQL Server 2000

1. Change the path for the master data files and the master log files in SQL Server Enterprise Manager.

Note You may also change the location of the error log here.

2. Right-click the SQL Server in Enterprise Manager and then click Properties.

3. Click Startup Parameters to see the following entries:

-dD:\MSSQL7\data\master.mdf

-eD:\MSSQL7\log\ErrorLog

-lD:\MSSQL7\data\mastlog.ldf

-d is the fully qualified path for the master database data file.

-e is the fully qualified path for the error log file.

-l is the fully qualified path for the master database log file.

4. Change these values as follows:

a. Remove the current entries for the Master.mdf and Mastlog.ldf files.

b. Add new entries specifying the new location:

-dE:\SQLDATA\master.mdf

-lE:\SQLDATA\mastlog.ldf

5. Stop SQL Server.

6. Copy the Master.mdf and Mastlog.ldf files to the new location (E:\Sqldata).

7. Restart SQL Server.

SQL Server 2005

For more information about moving the master database and the Resource database, visit the following MSDN Web site: http://msdn2.microsoft.com/en-us/library/ms345408.aspxYou may experience a failure when you move the master database and the Resource database. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

918695 You may experience a failure when you install SQL Server 2005 Service Pack 1 on an instance of SQL Server 2005

Back to the top

Moving the tempdb database

You can move tempdb files by using the ALTER DATABASE statement.

1. Determine the logical file names for the tempdb database by using sp_helpfile as follows:

use tempdb

sp_helpfile

The logical name for each file is contained in the name column. This example uses the default file names of tempdev and templog.

Use the ALTER DATABASE statement, specifying the logical file name as follows:

use master

Alter database tempdb modify file (name = tempdev, filename = 'E:\Sqldata\tempdb.mdf')

Alter database tempdb modify file (name = templog, filename = 'E:\Sqldata\templog.ldf')

You should receive the following messages that confirm the change:

Message 1

File 'tempdev' modified in sysaltfiles. Delete old file after restarting SQL Server.

Message 2

File 'templog' modified in sysaltfiles. Delete old file after restarting SQL Server.

2. Using sp_helpfile in tempdb will not confirm these changes until you restart SQL Server.

3. Stop and then restart SQL Server.

Back to the top

REFERENCES

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

912397 The SQL Server service cannot start when you change a startup parameter for a clustered instance of SQL Server 2000 or of SQL Server 2005 to a value that is not valid

274188 "Troubleshooting orphaned users" topic in Books Online is incomplete

246133 How to transfer logins and passwords between instances of SQL Server

168001 User logons and permissions on a database may be incorrect after the database is restored

For more information, see the following books:

Microsoft Corporation
Microsoft SQL Server 7.0 System Administration Training Kit
Microsoft Press, 2001

Microsoft Corporation
MCSE Training Kit: Microsoft SQL Server 2000 System Administration
Microsoft Press, 2001

Microsoft Corporation
Microsoft SQL Server 2000 Resource Kit
Microsoft Press, 2001

Back to the top

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Usefor other considerations.

How to transfer a database from one collation to another collation in SQL Server

http://support.microsoft.com/kb/325335/en-us

View products that this article applies to.

This article was previously published under Q325335

On This Page

· SUMMARY

o What is collation?

o When to use the Use Collation option in DTS

o Transfer methods that do not change a database's collation

o Transfer a database from one collation in SQL Server 7.0 to a different collation in SQL Server 7.0

o Transfer a database from one collation in SQL Server 7.0 to a collation in SQL Server 2000

o Transfer a database from one collation in SQL Server 2000 to a different collation in SQL Server 2000

o Change the collation of the master database

§ Change the collation of the master database in SQL Server 2000

§ Change the collation of the master database in SQL Server 7.0

· REFERENCES

Expand all | Collapse all

SUMMARY

This article defines collation and describes how to transfer a database from one collation in Microsoft SQL Server to another collation in SQL Server. The same concepts and discussions about SQL Server 2000 also apply to SQL Server 2005.

Back to the top

What is collation?

A collation specifies the bit patterns that represent each character. It also specifies the rules that are used to sort and to compare the characters. A collation has the following characteristics:

· Language

· Case sensitivity

· Accent sensitivity

· Kana sensitivity

To know the collation that a server is currently using, you can run the sp_helpsort system procedure in SQL Query Analyzer.

SQL Server 7.0 does not support databases that have multiple collations. Therefore, all the databases that you create in SQL Server 7.0 use the default collation. SQL Server 2000 supports multiple collations. SQL Server 2000 databases can have collations other than the default collation. Additionally, SQL Server 2000 also supports columns that have collations other than the collations of the databases where they were created.

Back to the top

When to use the Use Collation option in DTS

SQL Server 2000 can have multiple databases or columns that have collations other than the default collation. Because of this, a new option that is named Use Collation is introduced in Data Transformation Services (DTS). The behavior of the Use Collation option is determined by the type of transfer that you are performing. If you transfer data between two instances of SQL Server 2000 and you enable the Use Collation option, the data is translated from the source code page to the destination code page. If you do not enable the Use Collation option and the code pages are the same on both instances of SQL Server 2000, a direct data transfer occurs. If the code pages are different, the data from the source code page is translated to the destination code page. However, the translation may not be correct when you transfer the data.

Note The collation is important if the collation is used for the data itself and if a column uses the COLLATE clause. The Use Collation option determines whether a code page translation occurs when the data is transferred from one collation to another collation. The Use Collation option does not affect whether the COLLATE property of a column definition is set. Therefore, if a source table contains a column that was created with a specific collation by using the COLLATE clause, that collation persists when data is transferred, regardless of whether the Use Collate option is enabled in the Data Transformation Services Wizard.

Back to the top

Transfer methods that do not change a database's collation

The following methods do not change a database's collation:

· Backup and restore: Restoring a database on a server that has a different collation than the server that is used for the backup does not convert the restored database to the new collation. The database collation remains as is.

· Detach and reattach: If you detach a database that was created with one collation and you reattach the database to another server that has a different collation, the collation of the database does not change. The collation of the database remains as is.

· Copy Database Wizard: The Copy Database Wizard essentially automates the process of detaching and reattaching. The collation of the database remains as is.

Note The Copy Database Wizard is available in SQL Server 2000. However, the Copy Database Wizard is not available in SQL Server 7.0.

Back to the top

Transfer a database from one collation in SQL Server 7.0 to a different collation in SQL Server 7.0

To change the collation of a database between two computers that are running SQL Server 7.0, you must create the user database and all the objects on the destination server and then transfer the data by using DTS or the bcp utility.

To transfer a database from a computer that is running SQL Server 7.0 to a computer that is running SQL Server 7.0 and that has a different collation, follow these steps:

1. Back up the source database.

2. Use SQL Server Enterprise Manager to create scripts for all the objects in the source database.

3. To export the data from all the tables in the database, use DTS or the bcp utility.

4. Create a new database on the destination server by using SQL Server Enterprise Manager or the CREATE DATABASE statement.

Note When you use the CREATE DATABASE statement, the database will have the same collation as the computer that is running SQL Server 7.0.

5. Use SQL Query Analyzer to run the scripts that you created in step 2 to re-create all the objects in the destination database.

Note The tables and columns will have the same collation as the computer that is running SQL Server 7.0.

6. Import the data in the destination tables by using DTS or the bcp utility.

Back to the top

Transfer a database from one collation in SQL Server 7.0 to a collation in SQL Server 2000

To change the collation of a database between SQL Server 7.0 and SQL Server 2000, you must create the database, the columns, or both with the appropriate collation on the destination server before you transfer the data. However, you can use DTS to drop and then re-create the objects when you transfer data from SQL Server 7.0 to SQL Server 2000. When doing so, you must enable the Use Collation option in DTS.

Note Do not use the DTS utility that is included in SQL Server 7.0 to transfer all objects to or from a computer that is running SQL Server 2000. You must use the DTS utility that is included in SQL Server 2000 when you have to transfer data between SQL Server 7.0 and SQL Server 2000.

To transfer a database from one collation in SQL Server 7.0 to a collation in SQL Server 2000, follow these steps:

1. Back up the source database.

2. Use SQL Server Enterprise Manager to create scripts for all the objects in the source database.

3. If the columns must have a different collation than the default collation on the destination database, make the required collation changes to the appropriate columns in the scripts.

4. Create a new database on the destination server with the appropriate collation.

5. Use SQL Query Analyzer to run the scripts that you created in step 2 on the destination server to re-create all objects in the database.

Note The new tables and columns have the same collation as the database unless you specify a different collation for the columns.

6. Use DTS or the bcp utility to transfer the data.

Note If you use DTS, verify the following:

o Make sure that the Use Collation option is enabled when you transfer data from SQL Server 7.0 to SQL Server 2000.

o Because the objects are already created on the destination server with the appropriate collation, disable the Create Destination Objects First option.

Back to the top

Transfer a database from one collation in SQL Server 2000 to a different collation in SQL Server 2000

To transfer a database from one collation in SQL Server 2000 to a different collation in SQL Server 2000, follow these steps:

1. Back up the source database.

2. Note if any columns use the COLLATE clause.

3. Create a new database on the destination server with the appropriate collation.

4. If no columns use the COLLATE clause, use DTS to transfer the data to the destination server. To do so, enable the Use Collation option for code page translation and to transfer the data to the new collation on the destination database. If any columns use the COLLATE clause, follow these steps:

a. Generate scripts for all the objects (not including the indexes, the triggers, the primary keys, the foreign keys, the default settings, and the constraints). Additionally, make sure that you enable the Only script 7.0 compatible features option to remove the COLLATE clause from the script.

Note When you use the Only script 7.0 compatible features option, you can change the collation. However, any new SQL Server 2000 options (including user-defined functions, extended properties, the INSTEAD OF trigger, and indexes on views) will not be considered when the scripts are generated.

b. Run the scripts from step a on the destination database to create the objects with the destination database collation.

c. Use DTS to transfer only the data from the source database.

d. After the data is successfully transferred, generate scripts for all the constraints, foreign keys, primary keys, and indexes from the source database.

Note On the Formatting tab of the Generate SQL Scripts dialog box, click to clear the following check boxes:

§ Generate the CREATE <object> command for each object

§ Generate the DROP <object> command for each object

e. Run the scripts from step d on the destination database.

Back to the top

Change the collation of the master database

If you want to change the collation of the master database, you must rebuild the master database. When you rebuild the master database, you essentially create a new master database. Therefore, consider the following items before you rebuild the master database:

· Make sure to make a valid backup of the current master database. When you rebuild the master database, the msdb database and the model database are also re-created. Therefore, you must back up the msdb database and the model database before you rebuild the master database. The msdb database is the system database that is used to store your SQL Server jobs, alerts, operators, and DTS packages. The model database is the template database that is used when you create a new database.

· Because rebuilding the master database creates a new master database, you must re-enter the existing login information after you rebuild the master database. Therefore, you must export the login information before you rebuild the master database. After you re-create the master database, import the login information. For more information about how to export login information, click the following article number to view the article in the Microsoft Knowledge Base:

246133 How to transfer logins and passwords between instances of SQL Server

· Because the msdb database is rebuilt when you rebuild the master database, you must generate scripts for all the jobs, alerts, and operators before you rebuild the master database. Additionally, you must make sure that you move all DTS packages. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

314546 How to move databases between computers that are running SQL Server

· Because the model database is rebuilt when you rebuild the master database, any changes that were previously made to the model database must either be noted, scripted, or exported before you rebuild the master database. After the model database is rebuilt, reapply any noted changes.

Change the collation of the master database in SQL Server 2000

Before you change the collation of the master database, follow these steps:

1. When you rebuild the master database, it does not automatically recall all the databases that were created before the database is rebuilt. Therefore, all databases must be restored from a backup or if the files are still on disk, you can reattach the databases by using the sp_attach_db system stored procedure. Make sure that you have all the necessary information to reattach existing databases before you rebuild the master database. For more information about the sp_attach_db system stored procedure, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/aa259611(SQL.80).aspx

2. When you rebuild the master database, only the collation of the master database, the model database, and the msdb database is changed. The collation of the user databases is not changed. To change the collation of an existing user database or to create a new database with the appropriate collation, use the ALTER DATABASE command, and then use DTS or the bcp utility to transfer the data to the new database.

Note If you use the ALTER DATABASE command in SQL Server 2000 to change the collation of a database, the collation of the columns in the tables is not automatically changed. To change the collation of the columns, use the ALTER TABLE command and the ALTER COLUMN command. If you are using DTS, you can create the table and the columns with the appropriate collation before you transfer the data or you can use the Use Collation option. If you are using DTS and the table with the appropriate collation already exists, make sure to disable the Drop Existing Objects First option before you run the package.

Change the collation of the master database in SQL Server 7.0

Before you change the collation of the master database, follow these steps:

1. SQL Server 7.0 does not support having databases with collations other than the default collation. Therefore, before you rebuild the master database, export all the data from the user databases.

2. Generate the scripts for all the objects in the database.

3. Re-create the master database with the appropriate collation.

4. Create the new databases. The new databases are automatically created with the new default collation.

5. Run the previously saved scripts to re-create the objects, and then import the data that you previously exported.

Back to the top

REFERENCES

For more information about collations, visit the following Microsoft Web sites:

· http://msdn2.microsoft.com/en-us/library/aa214408(SQL.80).aspx

· http://msdn2.microsoft.com/en-us/library/aa174903(SQL.80).aspx

· http://msdn2.microsoft.com/en-us/library/aa258237(SQL.80).aspx

How to transfer logins and passwords between instances of SQL Server

http://support.microsoft.com/kb/246133/en-us

View products that this article applies to.

This article was previously published under Q246133

On This Page

· SUMMARY

o How to transfer logins and passwords between servers that are running SQL Server 7.0

o How to transfer logins and passwords from SQL Server 7.0 to SQL Server 2000 or between servers that are running SQL Server 2000

o How to transfer logins and passwords between instances of SQL Server 2005

o A complete resolution to transfer logins and passwords between different versions of SQL Server

o Method 1

o Method 2

o Remarks

Expand all | Collapse all

SUMMARY

After you move databases to a new server, users may not be able to log in to the new server. Instead, they receive the following error message:

Msg 18456, Level 16, State 1
Login failed for user '%ls'.

You must transfer the logins and passwords to the new server. This article describes how you transfer logins and passwords to a new server.

Back to the top

How to transfer logins and passwords between servers that are running SQL Server 7.0

The SQL Server 7.0 Data Transformation Services (DTS) Object Transfer feature transfers logins and users between two servers, but it does not transfer the passwords for SQL Server authenticated logins. To transfer logins and passwords from a server that is running SQL Server 7.0 to another server that is running SQL Server 7.0, follow the steps in the "A complete resolution to transfer logins and passwords between different versions of SQL Server" section.

Back to the top

How to transfer logins and passwords from SQL Server 7.0 to SQL Server 2000 or between servers that are running SQL Server 2000

To transfer logins and passwords from a SQL Server 7.0 server to an instance of SQL Server 2000, or between two instances of SQL Server 2000, you can use the new DTS Package Transfer Logins Task in SQL Server 2000. To do this, follow these steps:

1. Connect to the SQL Server 2000 destination server, move to the Data Transformation Services in SQL Server Enterprise Manager, expand the folder, right-click Local Packages, and then click New Package.

2. After the DTS package designer opens, click Transfer Logins Task on the Task menu. Complete the information about the Source, Destination and Logins tabs as appropriate.

Important The SQL Server 2000 destination server cannot be running the 64-bit version of SQL Server 2000. DTS components for the 64-bit version of SQL Server 2000 are not available. If you are importing logins from an instance of SQL Server that is on a separate computer, your instance of SQL Server will must be running under a Domain Account to complete the task.

Note The DTS method will transfer the passwords but not the original SID. If a login is not created by using the original SID and user databases are also transferred to a new server, the database users will be orphaned from the login. To transfer the original SID and bypass the orphaned users, follow the steps in the "A complete resolution to transfer logins and passwords between different versions of SQL Server" section.

Back to the top

How to transfer logins and passwords between instances of SQL Server 2005

For more information about how to transfer the logins and passwords between instances of SQL Server 2005, click the following article number to view the article in the Microsoft Knowledge Base:

918992 How to transfer the logins and the passwords between instances of SQL Server 2005

Back to the top

A complete resolution to transfer logins and passwords between different versions of SQL Server

To do this, use one of the following methods.
Notes

· The scripts in the following methods create two stored procedures that are named the sp_hexadecimal stored procedure and the sp_help_revlogin stored procedure in your master database.

· The scripts are dependent on SQL Server system tables. The structure of these tables may change between versions of SQL Server. Selecting directly from system tables is discouraged.

· Review the remarks at the end of this article for important information about the steps in the methods.

· Method 2 assigns logins to roles.

Back to the top

Method 1

This method applies to the following scenarios:

· You transfer logins and passwords from SQL Server 7.0 to SQL Server 7.0.

· You transfer logins and passwords from SQL Server 7.0 to SQL Server 2000.

· You transfer logins and passwords between servers that are running SQL Server 2000.

To transfer logins and passwords between different versions of SQL Server, follow these steps:

1. Run the following script on the source SQL Server. Continue to step 2 when you finish creating the sp_help_revlogin stored procedure.

----- Begin Script, Create sp_help_revlogin procedure -----

USE master

IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL

DROP PROCEDURE sp_hexadecimal

CREATE PROCEDURE sp_hexadecimal

@binvalue varbinary(256),

@hexvalue varchar(256) OUTPUT

DECLARE @charvalue varchar(256)

DECLARE @i int

DECLARE @length int

DECLARE @hexstring char(16)

SELECT @charvalue = '0x'

SELECT @i = 1

SELECT @length = DATALENGTH (@binvalue)

SELECT @hexstring = '0123456789ABCDEF'

WHILE (@i <= @length)

BEGIN

DECLARE @tempint int

DECLARE @firstint int

DECLARE @secondint int

SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))

SELECT @firstint = FLOOR(@tempint/16)

SELECT @secondint = @tempint - (@firstint*16)

SELECT @charvalue = @charvalue +

SUBSTRING(@hexstring, @firstint+1, 1) +

SUBSTRING(@hexstring, @secondint+1, 1)

SELECT @i = @i + 1

END

SELECT @hexvalue = @charvalue

IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL

DROP PROCEDURE sp_help_revlogin

CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS

DECLARE @name sysname

DECLARE @xstatus int

DECLARE @binpwd varbinary (256)

DECLARE @txtpwd sysname

DECLARE @tmpstr varchar (256)

DECLARE @SID_varbinary varbinary(85)

DECLARE @SID_string varchar(256)

IF (@login_name IS NULL)

DECLARE login_curs CURSOR FOR

SELECT sid, name, xstatus, password FROM master..sysxlogins

WHERE srvid IS NULL AND name <> 'sa'

ELSE

DECLARE login_curs CURSOR FOR

SELECT sid, name, xstatus, password FROM master..sysxlogins

WHERE srvid IS NULL AND name = @login_name

OPEN login_curs

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd

IF (@@fetch_status = -1)

BEGIN

PRINT 'No login(s) found.'

CLOSE login_curs

DEALLOCATE login_curs

RETURN -1

END

SET @tmpstr = '/* sp_help_revlogin script '

PRINT @tmpstr

SET @tmpstr = '** Generated '

+ CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'

PRINT @tmpstr

PRINT ''

PRINT 'DECLARE @pwd sysname'

WHILE (@@fetch_status <> -1)

BEGIN

IF (@@fetch_status <> -2)

BEGIN

PRINT ''

SET @tmpstr = '-- Login: ' + @name

PRINT @tmpstr

IF (@xstatus & 4) = 4

BEGIN -- NT authenticated account/group

IF (@xstatus & 1) = 1

BEGIN -- NT login is denied access

SET @tmpstr = 'EXEC master..sp_denylogin ''' + @name + ''''

PRINT @tmpstr

END

ELSE BEGIN -- NT login has access

SET @tmpstr = 'EXEC master..sp_grantlogin ''' + @name + ''''

PRINT @tmpstr

END

ELSE BEGIN -- SQL Server authentication

IF (@binpwd IS NOT NULL)

BEGIN -- Non-null password

EXEC sp_hexadecimal @binpwd, @txtpwd OUT

IF (@xstatus & 2048) = 2048

SET @tmpstr = 'SET @pwd = CONVERT (varchar(256), ' + @txtpwd + ')'

ELSE

SET @tmpstr = 'SET @pwd = CONVERT (varbinary(256), ' + @txtpwd + ')'

PRINT @tmpstr

EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT

SET @tmpstr = 'EXEC master..sp_addlogin ''' + @name

+ ''', @pwd, @sid = ' + @SID_string + ', @encryptopt = '

END

ELSE BEGIN

-- Null password

EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT

SET @tmpstr = 'EXEC master..sp_addlogin ''' + @name

+ ''', NULL, @sid = ' + @SID_string + ', @encryptopt = '

END

IF (@xstatus & 2048) = 2048

-- login upgraded from 6.5

SET @tmpstr = @tmpstr + '''skip_encryption_old'''

ELSE

SET @tmpstr = @tmpstr + '''skip_encryption'''

PRINT @tmpstr

END

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd

END

CLOSE login_curs

DEALLOCATE login_curs

RETURN 0

----- End Script -----

2. After you create the sp_help_revlogin stored procedure, run the sp_help_revlogin procedure from Query Analyzer on the source server. The sp_help_revlogin stored procedure can be used on both SQL Server 7.0 and SQL Server 2000. The output of the sp_help_revlogin stored procedure is login scripts that create logins with the original SID and password. Save the output, and then paste and run it in Query Analyzer on the destination SQL Server. For example:

EXEC master..sp_help_revlogin

Back to the top

Method 2

This method applies to the following scenarios:

· You transfer logins and passwords from SQL Server 7.0 to SQL Server 2005.

· You transfer logins and passwords from SQL Server 2000 to SQL Server 2005.

· You assign logins to roles.

To transfer logins and passwords between different versions of SQL Server and then assign logins to roles, follow these steps:

1. Run the following script on the source SQL Server.

USE master

IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL

DROP PROCEDURE sp_hexadecimal

CREATE PROCEDURE sp_hexadecimal

@binvalue varbinary(256),

@hexvalue varchar(256) OUTPUT

DECLARE @charvalue varchar(256)

DECLARE @i int

DECLARE @length int

DECLARE @hexstring char(16)

SELECT @charvalue = '0x'

SELECT @i = 1

SELECT @length = DATALENGTH (@binvalue)

SELECT @hexstring = '0123456789ABCDEF'

WHILE (@i <= @length)

BEGIN

DECLARE @tempint int

DECLARE @firstint int

DECLARE @secondint int

SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))

SELECT @firstint = FLOOR(@tempint/16)

SELECT @secondint = @tempint - (@firstint*16)

SELECT @charvalue = @charvalue +

SUBSTRING(@hexstring, @firstint+1, 1) +

SUBSTRING(@hexstring, @secondint+1, 1)

SELECT @i = @i + 1

END

SELECT @hexvalue = @charvalue

IF OBJECT_ID ('sp_help_revlogin_2000_to_2005') IS NOT NULL

DROP PROCEDURE sp_help_revlogin_2000_to_2005

CREATE PROCEDURE sp_help_revlogin_2000_to_2005

@login_name sysname = NULL,

@include_db bit = 0,

@include_role bit = 0

DECLARE @name sysname

DECLARE @xstatus int

DECLARE @binpwd varbinary (256)

DECLARE @dfltdb varchar (256)

DECLARE @txtpwd sysname

DECLARE @tmpstr varchar (256)

DECLARE @SID_varbinary varbinary(85)

DECLARE @SID_string varchar(256)

IF (@login_name IS NULL)

DECLARE login_curs CURSOR STATIC FOR

SELECT sid, [name], xstatus, password, isnull(db_name(dbid), 'master')

FROM master.dbo.sysxlogins

WHERE srvid IS NULL AND

[name] <> 'sa'

ELSE

DECLARE login_curs CURSOR FOR

SELECT sid, [name], xstatus, password, isnull(db_name(dbid), 'master')

FROM master.dbo.sysxlogins

WHERE srvid IS NULL AND

[name] = @login_name

OPEN login_curs

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

IF (@@fetch_status = -1)

BEGIN

PRINT 'No login(s) found.'

CLOSE login_curs

DEALLOCATE login_curs

RETURN -1

END

SET @tmpstr = '/* sp_help_revlogin script '

PRINT @tmpstr

SET @tmpstr = '** Generated '

+ CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'

PRINT @tmpstr

PRINT ''

PRINT '/***** CREATE LOGINS *****/'

WHILE @@fetch_status = 0

BEGIN

PRINT ''

SET @tmpstr = '-- Login: ' + @name

PRINT @tmpstr

IF (@xstatus & 4) = 4

BEGIN -- NT authenticated account/group

IF (@xstatus & 1) = 1

BEGIN -- NT login is denied access

SET @tmpstr = '' --'EXEC master..sp_denylogin ''' + @name + ''''

PRINT @tmpstr

END

ELSE

BEGIN -- NT login has access

SET @tmpstr = 'IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE [name] = ''' + @name + ''')'

PRINT @tmpstr

SET @tmpstr = CHAR(9) + 'CREATE LOGIN [' + @name + '] FROM WINDOWS'

PRINT @tmpstr

END

ELSE

BEGIN -- SQL Server authentication

EXEC sp_hexadecimal @SID_varbinary, @SID_string OUT

IF (@binpwd IS NOT NULL)

BEGIN -- Non-null password

EXEC sp_hexadecimal @binpwd, @txtpwd OUT

SET @tmpstr = 'CREATE LOGIN [' + @name + '] WITH PASSWORD=' + @txtpwd + ' HASHED'

END

ELSE

BEGIN -- Null password

SET @tmpstr = 'CREATE LOGIN [' + @name + '] WITH PASSWORD='''''

END

SET @tmpstr = @tmpstr + ', CHECK_POLICY=OFF, SID=' + @SID_string

PRINT @tmpstr

END

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

END

IF @include_db = 1

BEGIN

PRINT ''

PRINT '/***** SET DEFAULT DATABASES *****/'

FETCH FIRST FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

WHILE @@fetch_status = 0

BEGIN

PRINT ''

SET @tmpstr = '-- Login: ' + @name

PRINT @tmpstr

SET @tmpstr = 'ALTER LOGIN [' + @name + '] WITH DEFAULT_DATABASE=[' + @dfltdb + ']'

PRINT @tmpstr

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

END

IF @include_role = 1

BEGIN

PRINT ''

PRINT '/***** SET SERVER ROLES *****/'

FETCH FIRST FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

WHILE @@fetch_status = 0

BEGIN

PRINT ''

SET @tmpstr = '-- Login: ' + @name

PRINT @tmpstr

IF @xstatus &16 = 16 -- sysadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''sysadmin'''

PRINT @tmpstr

END

IF @xstatus &32 = 32 -- securityadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''securityadmin'''

PRINT @tmpstr

END

IF @xstatus &64 = 64 -- serveradmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''serveradmin'''

PRINT @tmpstr

END

IF @xstatus &128 = 128 -- setupadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''setupadmin'''

PRINT @tmpstr

END

IF @xstatus &256 = 256 --processadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''processadmin'''

PRINT @tmpstr

END

IF @xstatus &512 = 512 -- diskadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''diskadmin'''

PRINT @tmpstr

END

IF @xstatus &1024 = 1024 -- dbcreator

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''dbcreator'''

PRINT @tmpstr

END

IF @xstatus &4096 = 4096 -- bulkadmin

BEGIN

SET @tmpstr = 'exec master.dbo.sp_addsrvrolemember @loginame=''' + @name + ''', @rolename=''bulkadmin'''

PRINT @tmpstr

END

FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd, @dfltdb

END

CLOSE login_curs

DEALLOCATE login_curs

RETURN 0

exec sp_help_revlogin_2000_to_2005 @login_name=NULL, @include_db=1, @include_role=1

2. Save the output, and then paste and run the output in SQL Server Management Studio on the destination SQL Server 2005.

Note If the source SQL Server contains a login that has a blank password, the output contains a statement that resembles the following.

CREATE LOGIN LoginName WITH PASSWORD = '', CHECK_POLICY = OFF, SID = MySID

Back to the top

Remarks

· Review the output script carefully before you run it on the destination SQL Server. If you have to transfer logins to an instance of SQL Server in a different domain than the source instance of SQL Server, edit the script generated by the sp_help_revlogin procedure, and replace the domain name with the new domain in the sp_grantlogin statements. Because the integrated logins granted access in the new domain will not have the same SID as the logins in the original domain, the database users will be orphaned from these logins. To resolve these orphaned users, see the articles referenced in the following bullet item. If you transfer integrated logins between instances of SQL Servers in the same domain, the same SID is used and the user is not likely to be orphaned.

· After you move the logins, users may not have permissions to access databases that have also been moved. This problem is described as an "orphaned user". If you try to grant the login access to the database, it may fail indicating the user already exists:

Microsoft SQL-DMO (ODBC SQLState: 42000) Error 15023: User or role '%s' already exists in the current database.

For instructions about how to map the logins to the database users to resolve orphaned SQL Server logins and integrated logins, see the following article in the Microsoft Knowledge Base:

240872 How to resolve permission issues when you move a database between servers that are running SQL Server

For instructions about using the sp_change_users_login stored procedure to correct the orphaned users one-by-one (this will only address users orphaned from standard SQL logins), see the following article in the Microsoft Knowledge Base:

274188 "Troubleshooting Orphaned Users" topic in Books Online is incomplete

· If the transfer of logins and passwords is part of a move of databases to a new server running SQL Server, see the following article in the Microsoft Knowledge Base for a description of the workflow and steps involved:

314546 How to move databases between computers that are running SQL Server

· You can do this because of the @encryptopt parameter in the sp_addlogin system stored procedure, that allows a login to be created by using the encrypted password. For more information about this procedure, see the "sp_addlogin (T-SQL)" topic in SQL Server Books Online.

· By default, only members of the sysadminfixed server role can select from the sysxlogins table. Unless a member of the sysadmin role grants the necessary permissions, end users cannot create or run these stored procedures.

· This approach does not try to transfer the default database information for a particular login because the default database may not always exist on the destination server. To define the default database for a login, you can use the sp_defaultdb system stored procedure by passing it the login name and the default database as arguments. For more information about using this procedure, see the "sp_defaultdb" topic in SQL Server Books Online.

· During a transfer of logins between instances of SQL Server, if the sort order of the source server is case-insensitive and the sort order of the destination server is case-sensitive, you must enter all alphabetical characters in passwords as uppercase characters after the transfer of logins to the destination server. If the sort order of the source server is case-sensitive and the sort order of the destination server is case-insensitive, you will not be able to log in with the logins transferred using the procedure outlined in this article, unless the original password contains no alphabetical characters or unless all alphabetical characters in the original password are uppercase characters. If both servers are case-sensitive or both servers are case-insensitive, you will not experience this problem. This is a side effect of the way that SQL Server handles passwords. For more information, see the "Effect on Passwords of Changing Sort Orders" topic in SQL Server 7.0 Books Online.

· When you run the output from the sp_help_revlogin script on the destination server, if the destination server already has a login defined with the same name as one of the logins on the script output, you may see the following error upon execution of the output of the sp_help_revlogin script:

Server: Msg 15025, Level 16, State 1, Procedure sp_addlogin, Line 56
The login 'test1' already exists.

Likewise, if a different login exists with the same SID value on this server as the one you are trying to add, you receive the following error message:

Server: Msg 15433, Level 16, State 1, Procedure sp_addlogin, Line 93
Supplied parameter @sid is in use.

Therefore, you must carefully review the output from these commands, examine the contents of the sysxlogins table, and address these errors accordingly.

· The SID value for a particular login is used as the basis for implementing database level access in SQL Server. Therefore, if the same login has two different values for the SID at the database level (in two different databases on that server), the login will only have access to that database whose SID matches the value in syslogins for that login. Such a situation might occur if the two databases in question have been consolidated from two different servers. To resolve this problem, the login in question would have to be manually removed from the database that has a SID mismatch by using the sp_dropuser stored procedure, and then added again by using the sp_adduser stored procedure.

Back to the top

本文链接

Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connect

2011-02-25T02:10:00Z

[ZT]Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connection.”

2 May 2008 8:28 PM

Comments 29

Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connection.”

This exact Login Failed error, with the empty string for the user name, has two unrelated classes of causes, one of which has already been blogged about here: http://blogs.msdn.com/sql_protocols/archive/2005/09/28/474698.aspx. In addition to an extra space in the connection string, the other class of causes for this error message is an inability to resolve the Windows account trying to connect to SQL Server. This list is not intended to be exhaustive, but here are several known root causes for this error message.

1) If this error message occurs every time in an application using Windows Authentication, and the client and the SQL Server instance are on separate machines, then ensure that the account which is being used to access SQL Server is a domain account. If the account being used is a local account on the client machine, then this error message will occur because the SQL Server machine and the Domain Controller cannot recognize a local account on a different machine. The next step for this is to create a domain account, give it the appropriate access rights to SQL Server, and then use that domain account to run the client application. Note that this case also includes the special accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\NETWORK SERVICE” trying to connect to a remote SQL Server, when authentication uses NTLM rather than Kerberos.

One very common case where this can occur is when creating web applications with SQL Server and IIS; often, the web page will work during development, then errors occur with this message after deploying the web site. This occurs because the developer’s account has access to SQL Server, but the account IIS runs as does not have access. To fix this specific problem, refer to this kb article about impersonating a domain user in ASP.NET: http://support.microsoft.com/kb/306158

2) Similar to above: this error message can appear if the user logging in is a domain account from a different, untrusted domain from the SQL Server’s domain. The next step for this is either to move the client machine into the same domain as the SQL Server and set it up to use a domain account, or to set up mutual trust between the domains. Setting up mutual trust is a complicated procedure and should be done with a great deal of care and due security considerations.

3) This error message can appear immediately after a password change for the user account attempting to login. This occurs because of caching of the client user’s credentials. The next step here is to log out the application user with the old password, and re-login with the new password before running the application.

4) If this error message only appears sporadically in an application using Windows Authentication, it may result because the SQL Server cannot contact the Domain Controller to validate the user. This may be caused by high network load stressing the hardware, or to a faulty piece of networking equipment. The next step here is to troubleshoot the network hardware between the SQL Server and the Domain Controller by taking network traces and replacing network hardware as necessary.

5) This error message can appear consistently for local connections using trusted authentication, when SQL Server’s SPN is not interpreted by SSPI as belonging to the local machine. This can be caused either by a misconfiguration of DNS, or by a machine having multiple names. If your machine has multiple names, try to work around the need for multiple names and give it a unique name. If the machine just has one name, then check your DNS configuration.

本文链接

	简介
	基础结构的要求
	Windows 身份验证方案
	配置 Kerberos 委派
	诊断委派问题：四个清单
	总结
	附录 A：诊断工具
	附录 B：常见方案的配置示例
	附录 C：网络监视器捕获到的网络记录的示例
	附录 D：相关信息

•	Microsoft Windows Server 2003 技术参考，位于：http://go.microsoft.com/fwlink/?LinkId=21711
•	Microsoft 知识库中的“Windows 2000 中的 Kerberos 用户身份验证协议概述”，位于：http://go.microsoft.com/fwlink/?LinkId=24922

•	DNS 必须运行以使客户端可以获得 FQDN。
•	为了得到最好的结果，不要使用具有 DNS 的 Hosts 文件。

•	服务的类型，正式的名称是服务类。此信息段使用户可以区分在同一个帐户下运行的多项服务。
•	服务在其下运行的帐户。
•	运行服务的计算机，包括指向此计算机的所有别名。
•	服务在其上运行的端口。

•	ServiceClass 是 SPN 的服务类。
•	Host 是 SPN 所属的计算机的名称。
•	Port 是注册 SPN 的服务所运行的端口。

•	本地用户帐户。服务器将检查它的安全帐户管理器 (SAM)。如果服务器计算出一个相似的结果，它将验证用户的响应，构建一个访问令牌，并为用户建立一个会话。
•	域用户帐户。服务器将质询和客户端的响应一起转发到域控制器。域控制器对响应进行验证，并将客户端的组信息发送到服务器计算机。服务器使用此信息构建一个访问令牌，并为用户建立一个会话。图 2 使用 NTLM 验证到后端服务器

•	无法确定用户是谁。
•	无法区分两个用户的身份以确定哪个用户向前端服务器发出了请求。
•	无法根据用户的身份提供对资源的不同的访问控制。

•	Kerberos 身份验证
•	使用约束委派的 Kerberos 身份验证
•	使用约束委派和协议转换的 Kerberos 身份验证

•	应用程序的域用户不能选中敏感帐户，不能被委派选项。
•	必须为中间层服务器上的服务注册 SPN。如果此服务帐户是一个域用户帐户，则此服务的 SPN 必须由域管理员注册。如果此服务帐户使用计算机的帐户，则此过程可以自己注册或者由本地管理员使用 Setspn 来注册。有关 Setspn 的更多信息，请参见“附录 A：诊断工具”中的“Setspn”。
•	必须为委派信任中间层服务帐户。
•	必须在后端服务器上为服务注册一个 SPN。
•	如果使用了约束委派，则中间层服务和后端服务必须位于同一个域中。

•	清单 1 — Active Directory。正确地配置 SPN 和帐户。
•	清单 2 — 客户端应用程序。正确地配置应用程序并使用 Kerberos 身份验证。
•	清单 3 — 中间层。为委派正确地配置服务并使用 Kerberos 身份验证。
•	清单 4 — 后端。为 Kerberos 身份验证配置服务。

•	客户端。用户由其提出请求的应用程序。
•	中间层。位于中间的以用户方式提出请求的服务。
•	后端。最终与模仿用户的中间层服务进行通信的服务。

•	ServiceClass/Host:Port，其中 ServiceClass 是适当的服务类，Host 是主机的名称，Port 是运行服务的端口。
•	ServiceClass/FQDN，其中 FQDN 是主机的完全合格域名。

•	如果服务器正在运行 SQL Server，则客户端应用程序可以是 Query Analyzer、osql.exe 或使用 ADO 的 VB Script。
•	如果服务器正在运行 IIS，则客户端应用程序可以是 Internet Explorer。

1.	打开“Active Directory 用户和计算机”。
2.	右键单击“DomainName”，然后单击“属性”。
3.	确认在“域功能级”下列出了 Windows Server 2003。

1.	打开“Active Directory 用户和计算机”。
2.	右键单击“UserAccount”，然后单击“属性”。
3.	单击“帐户”选项卡。图 12 用户帐户选项
4.	在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

•	作为操作系统的一部分（在 Windows 2000 或 Windows Server 2003 中可用）
•	在身份验证之后模仿一个客户端（在 Windows Server 2003 中新增）

1.	通过依次单击“开始”、“程序”、“管理工具”和“域安全策略”来打开域安全策略。（参见上方过程中的“注意”部分。）
2.	单击“本地策略”，再单击“用户权限分配”，然后单击“在身份验证之后模仿一个客户端”。
3.	添加所有需要委派凭据的帐户（例如 IIS 帐户）。
4.	由于更改是在域控制器上的域安全策略中进行的，接着在命令提示符下对客户端计算机运行 gpupdate /force，以立即传播策略的更改。

1.	打开“Active Directory 用户和计算机”。
2.	右键单击 UserAccount，然后单击“属性”，
3.	再单击“帐户”选项卡。图 19 用户帐户选项
4.	在“帐户选项”框中，确认未选中“敏感帐户，不能被委派”。

•	为 NTLM 成功审核检查中间层服务器上的安全日志。有关启用审核和使用安全日志的更多信息，请参见“附录 A：诊断工具”中的“安全事件日志”。
•	在连接到服务器之前使用 Kerberos Tray 清除票证，然后观察票证以找到一个连接到服务器的票证。更多信息请参见“附录 A：诊断工具”中的“Kerberos Tray”。
•	使用网络监视器观察在 Kerberos 端口 88 上从客户端到域控制器的流量。如果拥有一个 Kerberos 分析程序，则可以很容易地观察流量并从流量中找出错误消息。此外，从域控制器到客户端的较大的流量表示一个成功的 Kerberos 连接。更多信息请参见“附录 A：诊断工具”中的“网络监视器”。

1.	打开“Active Directory 用户和计算机”。
2.	右键单击 DomainName，然后单击“属性”。
3.	验证在“域功能级”下列出了 Windows Server 2003。

2	Interactive（交互登录）
3	Network（通过网络访问系统）
4	Batch（作为批处理作业启动）
5	Service（由服务控制器启动的 Windows 服务）
6	Proxy NT or Windows（代理登录；在 Windows 2000 中未使用）
7	Unlock（解除对工作站的锁定）
8	NetworkCleartext（使用纯文本凭据的网络登录）
9	NewCredentials（由 RunAs 在使用 /netonly 选项时使用）

1.	通过依次单击“开始”、“程序”、“管理工具”和“本地安全策略”，打开本地安全策略。注意此过程假定域控制器没有实施审核策略。如果情况是这样，则必须在域控制器上打开域安全策略或合适的组策略。
2.	单击“本地策略”，然后单击“审核策略”。
3.	右键单击“审核帐户登录事件”。
4.	选择“定义这些策略设置”。
5.	在“审核这些尝试：”下确保选中了“成功”和“失败”选项。
6.	单击“确定”。
7.	重复步骤 3 到 6 以使“审核登录事件”记录成功和失败事件。
8.	如果更改是在域控制器上的域安全策略中进行的，在命令提示符下对客户端计算机运行 gpupdate /force，以传播策略的更改。

博客园_我思故我在我有我精彩--liangqihui

word替换回车 替换换行 替换空格

[ZT]C# 代码实现设置用户"NETWORK SERVICE"具有对文件夹的读取权限。

[ZT]用sqlserver的sqlcmd、osql、isql的备份与还原

运用PMI主义

Kerberos 委派故障诊断

VPN 拨号，出现错误721,800的处理方案

This article provides a fix for the error: Login failed for user “. The user is not associated with a trusted SQL Server

灾难恢复：当SQL Server 2005的sa密码丢失后

How to move databases between computers that are running SQL Server

Understanding the error message: “Login failed for user ''. The user is not associated with a trusted SQL Server connect

word替换回车替换换行替换空格

•	Windows 中的 Kerberos 密钥分发中心 (KDC) 的票证授权票证 (TGT)。
•	UNIX 上的 Ksserver 的票证授权票证 (TGT)。

选项	描述
结束时间	票证失效的时间。在票证经过这段时间之后，将不能用于身份验证到服务。
KerbTicket 加密类型	用于加密 Kerberos 票证的加密类型。
更新时间	更新的票证的最大生存期（参见下面的表中的 TicketFlags）。为了继续使用此票证，必须在到达已建立的结束时间之前以及在 RenewUntil 中建立的过期数据之前对其进行更新。
服务器	票证的服务器和域。

选项	描述
AltTargetDomainName	为生成此票证的 InitializeSecurityContext 提供的名称，通常是一个 SPN。
DomainName	服务的域名。
结束时间	票证失效的时间。在票证经过结束时间之后，将不能用于身份验证到服务。
FullServiceName	服务的帐户主体的规范名称。
KeyExpirationTime	来自 KDC 应答的过期时间。
RenewUnitil	更新的票证的最大生存期（参见 TicketFlags）。为了继续使用一个票证，必须对其进行更新。必须在结束时间和 RenewUntil 中设置的过期时间之前更新票证。
ServiceName	TGT 是密钥分发中心 (KDC）服务的票证。TGT 的服务名称是 krbtgt。
StartTime	票证生效的时间。
TargetDomainName	对于跨领域的票证，此领域是票证有效的领域，而不是发出票证的领域。
TargetName	请求票证的服务名称。这是目录中的一个帐户的 servicePrincipalName 属性的名称。
TicketFlags	在当前的票证上设置的十六进制的 Kerberos 票证标记。Kerberos Tray 在“标志”选项卡上显示了这些标志。
TimeSkew	票证的客户端计算机和服务器计算机之间的报告时间之差。

1.	为运行 Kerberos Tray，双击 Kerbtray文件。Kerbtray 图标将出现在通知区域中。
2.	为了在运行 Kerberos Tray 之后打开主 Kerbtray 窗口，双击它在通知区域中的图标。将显示有关当前用户的所有票证的信息。在“标志”选项卡中将显示每个票证的票证选项。
3.	为了清除票证，在通知区域中右键单击 Kerbtray 图标并单击清除票证。

•	在林中有多个对象具有相同的 HOST/NetBIOSname SPN，可能会造成 Kerberos 身份验证故障。
•	在帐户上注册了多个（因此无效）MSSQL SPN。

•	对象已是组的成员
•	违反对象类（即指定的对象类不存在），如果导入的对象没有其他属性
•	对象已存在
•	违反约束条件
•	属性或值已存在
•	没有这样的对象

1.	在驱动器中插入 Windows XP CD-ROM。
2.	双击“我的电脑”，右键单击光盘驱动器，然后单击“资源管理器”。
3.	转到Support\Tools，然后双击Setup.exe。
4.	当“Windows 支持向导”启动时，单击“下一步”。
5.	在最终用户许可协议上单击“我同意”。
6.	键入名称和组织，然后单击“下一步”。
7.	单击“典型”或“完全”安装类型，然后单击“下一步”。
8.	验证安装位置，然后单击“安装”。

1.	单击“开始”，指向“设置”，然后单击“控制面板”。
2.	双击“添加或删除程序”。
3.	单击“添加/删除 Windows 组件”。
4.	单击“管理和监视工具”，然后单击“详细信息”。
5.	单击以选中“网络监视工具”复选框，然后单击“确定”。
6.	单击“下一步”。重要在 Windows XP 上网络监视是由 Netcap.exe 工具完成的。此工具只允许网络流量的捕获。而捕获的结果不能使用同一个工具查看。必须使用 Windows 2003 家族上的网络监视器的 2000 或 Windows Server 完整版来查看捕获到的数据。

1.	依次单击“开始”、“控制面板”、“性能和维护”和“管理工具”，然后双击“网络监视器”。
2.	单击“启动”按钮开始捕获网络流量。
3.	复制错误。
4.	单击“停止”按钮以停止捕获网络流量。
5.	在右侧的捕获统计信息中，验证没有因为缓冲器溢出而丢失数据包。如果丢失了任何数据包，在“捕获”菜单上的“缓冲器设置”对话框中增加缓冲器的大小，并重新执行捕获。

1.	单击“捕获”，然后单击“显示捕获的数据”。
2.	单击“漏斗”按钮，然后双击协议 == 任何。
3.	单击“禁用全部”。