我已将我的服务帐户(不是托管服务帐户,只是常规用户帐户)添加到AD组(例如sql Server),并且我已将ACE添加到我的域计算机容器的ACL,对于该组,选择：
>适用于：Descendant Computer对象
>验证写入服务主体名称：允许
>阅读servicePrincipalName：允许
>写servicePrincipalName：允许
我已将此复制到所有域控制器,并使用“有效权限”选项卡和dsacls CN = SERVER01,CN = Computers,DC = fabrikam,DC = local,后者确认新ACE对特定计算机对象的继承性现在包括：
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服务时,我仍然看到无法注册服务主体名称消息.我也重新启动了服务器,结果相同.
我使用Sysinternals Process Explorer来检查正在运行的sqlservr.exe; “安全”选项卡清楚地显示了正确的服务用户及其sql Server组的成员身份.
我知道我可以手动添加带有setspn -A的SPN,但这不是重点.
我还需要做些什么来确保服务帐户(以及我在sql Servers组中的任何未来帐户)可以自动注册自己的SPN而无需人工干预？
AND / OR
如何进一步诊断此处缺少哪些权限/权限？
解决方法
我手动将SPN注册到服务帐户,然后使用ADSIEdit检查AD,却发现手动注册的SPN未存储在计算机帐户的servicePrincipalName字段中,而是存储在特定用户帐户的servicePrincipalName字段中.
因此,我(无意中)授予他们更改由作为该计算机上的本地系统/网络服务帐户运行的服务注册的SPN的权限,而不是授予我的sql Server组权限以注册他们自己的SPN.
我现在已经从Computers容器中删除了新的ACE,而是创建了一个新的sql Server组织单元.我已将SELF添加到此OU,并将其限制为应用于后代用户：
> sql Server OU ACL
>自我
>应用于：Descendant User对象
>阅读servicePrincipalName：允许
>写servicePrincipalName：允许
现在,当我启动sql Server实例时,我看到预期的sql Server网络接口库已成功注册了服务主体名称,而Kerberos现在正用于我的远程连接.
(现在更新我们的内部流程文档,因此需要在新OU下创建新的sql Server服务帐户,而不是添加到组中)
编辑：请注意,域管理员还可以使用setspn.exe手动将SPN注册到域帐户.
setspn -S MSsqlSvc/myhost.redmond.microsoft.com:1433 DOMAIN\User setspn -S MSsqlSvc/myhost.redmond.microsoft.com DOMAIN\User
Register a Service Principal Name for Kerberos Connections (TechNet).
编辑2：如果在ACE列表中看不到Read servicePrincipalName和Write servicePrincipalName属性,请转到对象属性对话框的“属性编辑器”选项卡,单击“过滤器”按钮并确保以下内容：
>仅显示具有值的属性未选中
>未显示仅显示可写属性
>显示属性：检查是否必需
>显示属性：选中可选
>显示只读属性：检查构造
>显示只读属性：检查反向链接
>显示只读属性：仅选中系统
(其他组合可能有用,但这对我来说是什么)
