我正在尝试配置全新安装的 SQL Server 以在域帐户下运行。但是,当我尝试使用另一个域帐户连接到服务器时,我收到间歇性错误,并且The SQL Server Network Interface library could not register the Service Principal Name
在搜索 ERRORLOG 文件时仍然会看到这些错误。
我已将我的服务帐户(不是托管服务帐户,只是普通用户帐户)添加到 AD 组(例如SQL Servers
),并且已将 ACE 添加到我的域Computers
容器的 ACL 中,对于该组,选择:
- 适用于:后代计算机对象
- 已验证写入服务主体名称:允许
- 读取 servicePrincipalName:允许
- 写入 servicePrincipalName:允许
我已将其复制到所有域控制器,并使用“有效权限”选项卡和确认新 ACE 继承到特定计算机对象,dsacls CN=SERVER01,CN=Computers,DC=fabrikam,DC=local
后者现在包括:
Allow FABRIKAM\SQL Servers
SPECIAL ACCESS for Validated write to service principal name <Inherited from parent>
WRITE SELF
Allow FABRIKAM\SQL Servers
SPECIAL ACCESS for Validated write to service principal name <Inherited from parent>
WRITE SELF
WRITE PROPERTY
READ PROPERTY
但是,当我重新启动 SQL Server 服务时,仍然会看到该could not register the Service Principal Name
消息。我还重新启动了服务器,结果还是一样。
我已经使用 Sysinternals Process Explorer 来检查正在运行的程序sqlservr.exe
;那里的“安全”选项卡清楚地显示了正确的服务用户及其SQL Servers
组成员身份。
我知道我可以手动添加 SPN setspn -A
,但这不是真正的重点。
我还必须做什么才能确保服务帐户(以及我放入该SQL Servers
组的任何未来帐户)无需人工干预即可自动注册自己的 SPN?
和/或
我如何进一步诊断这里缺少哪些特权/权限?
答案1
我找到了。
我手动将 SPN 注册到服务帐户,然后使用 ADSIEdit 检查 AD,却发现手动注册的 SPN 并未存储servicePrincipalName
在电脑帐户,但servicePrincipalName
具体用户帐户。
因此,SQL Servers
我没有授予我的团队注册他们自己的 SPN 的权限,而是(无意中)授予他们更改在该计算机上作为本地系统/网络服务帐户运行的服务注册的 SPN 的权限。
我现在已从容器中删除了新的 ACE Computers
,而是创建了一个新的SQL Servers
组织单位。我已向此 OU 添加了 ACE SELF
,并将其限制为应用于后代用户:
SQL Servers
组织单位访问控制列表SELF
- 适用于:后代用户对象
- 读取 servicePrincipalName:允许
- 写入 servicePrincipalName:允许
现在,当我启动我的 SQL Server 实例时,我看到了预期的The SQL Server Network Interface library successfully registered the Service Principal Name
,并且 Kerberos 现在正用于我的远程连接。
(现在更新我们的内部流程文档,因此需要在新的 OU 下创建新的 SQL Server 服务帐户,而不是将其添加到组中)
编辑:请注意,域管理员还可以使用 手动将 SPN 注册到域帐户setspn.exe
。
setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 DOMAIN\User
setspn -S MSSQLSvc/myhost.redmond.microsoft.com DOMAIN\User
为 Kerberos 连接注册服务主体名称 (TechNet)。
编辑2:如果ACE 列表中没有显示Read servicePrincipalName
和属性,请转到对象的Write servicePrincipalName
Attribute Editor特性对话框中,单击Filter按钮并确保以下内容:
- 仅显示具有值的属性是未选中
- 仅显示可写属性是未选中
- 显示属性:必填是已检查
- 显示属性:可选是已检查
- 显示只读属性:已构造是已检查
- 显示只读属性:反向链接是已检查
- 显示只读属性:仅限系统是已检查
(其他组合可能也行,但对我来说这是有效的)
答案2
您没有说明运行的是哪个版本的 SQL Server,也没有说明服务帐户的权限(除了它不是托管服务帐户并且具有写入 SPN 权限),但根据您提供的信息,我认为该帐户无权将自身注册为 SPN。尽管您已明确授予了该权限。
显然,SQL 2012需要Server 2008 上的虚拟帐户或托管服务帐户:
当数据库引擎服务启动时,它会尝试注册服务主体名称 (SPN)。如果启动 SQL Server 的帐户没有在 Active Directory 域服务中注册 SPN 的权限,则此调用将失败,并且将在应用程序事件日志和 SQL Server 错误日志中记录警告消息。要注册 SPN,数据库引擎必须在内置帐户(如本地系统(不推荐)或 NETWORK SERVICE)或有权注册 SPN 的帐户(如域管理员帐户)下运行。当 SQL Server 在 Windows 7 或 Windows Server 2008 R2 操作系统上运行时,您可以使用虚拟帐户或托管服务帐户 (MSA) 运行 SQL Server。虚拟帐户和 MSA 都可以注册 SPN。如果 SQL Server 未在这些帐户之一下运行,则启动时不会注册 SPN,域管理员必须手动注册 SPN。
我希望这能有所帮助。
答案3
如果 SQL 服务使用的 AD 帐户名称超过 20 个字符,则 SetSpn.exe 将无法在 AD 中找到它,而让您的 SQL 会话使用 Kerberos 进行身份验证的唯一方法是重新配置 AD 权限并重新启动 SQL。不要试图通过缩短名称参数来欺骗 SetSpn.exe -S:SetSpn.exe 随后会找到该帐户,但它会使用与 Kerberos“不匹配”的名称来注册它
答案4
@凯瑟琳·维利亚德
当数据库引擎服务启动时,它会尝试注册服务主体名称 (SPN)。如果启动 SQL Server 的帐户没有在 Active Directory 域服务中注册 SPN 的权限,则此调用将失败,并且将在应用程序事件日志和 SQL Server 错误日志中记录警告消息。要注册 SPN,数据库引擎必须在内置帐户(如本地系统(不推荐)或 NETWORK SERVICE)或有权注册 SPN 的帐户(如域管理员帐户)下运行。当 SQL Server 在 Windows 7 或 Windows Server 2008 R2 操作系统上运行时,您可以使用虚拟帐户或托管服务帐户 (MSA) 运行 SQL Server。虚拟帐户和 MSA 都可以注册 SPN。如果 SQL Server 未在这些帐户之一下运行,则启动时不会注册 SPN,域管理员必须手动注册 SPN。
所以我现在发现重复的 SPN setspn -x
一个与服务器关联,另一个与域管理员帐户关联。计算机属性显示读/写 SPN 为有效权限,而管理员帐户则没有。尽管如此......我如何确定要从哪个帐户中删除关联的 SPN?
谢谢。如果我的问题听起来有点傻,请介意。
问候 Rajen