0

我有一个 BizTalk 接收位置，指向一个远程 UNC 文件共享，当我打开接收位置时它会立即关闭，并抱怨它对该目录没有读/写权限。过去看到这种情况，难免是因为 BizTalk 服务帐户没有被授予“完全控制”权限，或者是因为 unix 权限问题。

但是，在这种情况下，它是一个 Windows 文件服务器，BizTalk 服务帐户可以完全控制该目录。所以这些似乎都不是问题。另外，在另一台机器上，我创建了一个共享，授予服务帐户权限，包括 UNC 和 NTFS，将 BizTalk 指向它，它就像一个魅力一样工作。

我能说的唯一区别是，他们为 BizTalk 服务帐户所在的组提供了目录结构中更高的权限。但这只是意味着服务帐户在该机器上拥有更大程度的权限，而不是更少。

  • 有什么想法可能导致这种情况吗？
  • 是否有任何工具或此类工具可以帮助追踪 Windows 身份验证问题？
4

1 回答 1

1

有什么想法可能导致这种情况吗？

然而，什么都没有立即浮现在脑海中：

  • 为了保持一致性，我会将目录权限更改为组权限或服务帐户权限。
  • 您在帖子中提到了 UNC 共享和 NTFS 权限，我会仔细检查您有问题的共享上的内容，以确保它们与组或服务帐户权限一致。
  • 我还将检查以确保运行您的文件适配器的 BizTalk 主机正在使用您希望它使用的凭据，并且是预期组的成员。

如果这些检查不起作用，我会考虑将 FILE 适配器设置为使用不同的身份验证凭据-您知道可以使用的东西-覆盖 BizTalk 服务凭据以降低 BizTalk 的问题。

是否有任何工具或此类工具可以帮助追踪 Windows 身份验证问题？

关于工具，我不知道有什么可以帮助解决这个特定问题，但是SysInternals 的Process Explorer可能会提供一些关于正在发生的事情的见解。

于 2013-03-25T20:15:23.290 回答