Ms Dynamics NAV服务主体配置异常及域信任问题求助

我来一步步帮你排查解决这个问题——这种NAV服务器和AD域信任失效引发的SPN配置错误很常见，咱们按顺序来处理：

第一步：确认Server2与AD域的信任关系是否真的失败 #

先验证你的推测是否正确：

• 登录Server2，以管理员身份打开命令提示符，运行：

  nltest /sc_query:你的域名
  

  如果返回“信任关系失败”或类似提示，那就坐实了是域信任问题；如果显示“成功”，再去看系统事件日志（事件查看器→Windows日志→系统），有没有ID为5722的事件，这是典型的域信任断裂标志。

第二步：修复Server2与AD的域信任关系 #

有两种常用修复方式，选适合你的就行：

方式1：移除再重新加入域（最稳妥） #

1. 在Server2上右键「此电脑」→「属性」→「更改设置」→「更改」，选择「工作组」，随便输入一个临时工作组名称（比如TEMP-WORKGROUP），点击确定后重启服务器。
2. 重启完成后，回到同样的路径，选择「域」，输入你的AD域名（Server1所在的域），用拥有域加入权限的管理员账号完成加入操作，再次重启服务器。

方式2：用命令快速修复（无需移除域） #

以管理员身份在Server2的命令提示符中运行：

netdom reset Server2 /domain:你的域名 /userd:域管理员账号 /passwordd:*

然后输入域管理员的密码，执行完成后重启Server2即可。

第三步：重新配置SPN与委派权限 #

修复信任关系后，原有的SPN注册可能失效，需要重新检查并配置：

1. 检查并注册SPN：
   登录Server1（AD服务器），用域管理员账号打开命令提示符，先查看Server2已注册的SPN：

   setspn -L Server2$
   

   你需要确保存在与Dynamics NAV相关的条目，比如DynamicsNAV/Server2或DynamicsNAV/Server2.你的域名。如果缺少，用以下命令注册（替换成你的NAV服务账号）：

   setspn -A DynamicsNAV/Server2 DOMAIN\NAVServiceAccount
   

   如果你NAV使用的SQL服务器也在Server2上，还要确保SQL的SPN（比如MSSQLSvc/Server2:1433）也正确注册。

2. 配置服务账号的委派权限：
   在Server1的「Active Directory用户和计算机」中找到你的NAV服务账号，右键→「属性」→「委派」选项卡：

   • 如果是全委派需求，选择「信任此用户以委派到任何服务（仅Kerberos）」；
   • 如果是约束委派，选择「信任此用户以委派到指定服务」，然后添加对应的NAV和SQL服务条目。

第四步：验证修复效果 #

• 重启Server2上的Microsoft Dynamics NAV Server服务（以及SQL Server服务，如果在同一台服务器上）。
• 让客户端用户先运行klist purge清除本地Kerberos缓存，再重新打开Dynamics NAV测试错误是否消失。

内容的提问来源于stack exchange，提问作者Alfred Kimotho