【问题标题】:IIS application writing to a remote file shareIIS 应用程序写入远程文件共享
【发布时间】:2013-12-03 20:48:45
【问题描述】:

我们在 DMZ 中有 2 台服务器。第一个是应用服务器,我们称之为APP机器。另一个是文件服务器,我们称之为FILE。在 IIS 下的 APP 机器上运行的网站试图在位于 FILE 服务器的共享目录中创建文件。

当应用程序池与 IUSR_IUSRS 中的某些用户一起运行时,或者网络服务写入远程位置失败。我不能在共享文件夹中授权这个用户,因为那个 FILE 机器只能看到本地用户。

我在 APP 机器 (APP/X) 上创建了一个用户 X,并在 FILE (FILE/X) 上创建了另一个具有相同用户名的用户。然后我将 FILE/X 用户添加到 APP 机器上的凭据管理器。当 APP/X 和 FILE/X 用户密码不同时,再次写入失败。但是,当密码相同时,编写就可以了。

我不明白为什么密码很重要。归根结底,他们是两个不同的用户 APP/X 和 FILE/X。有人可以澄清这种现象吗?

【问题讨论】:

  • 现在,关于凭证管理器项,当你添加的时候,你是在APP上以X用户身份登录的吗?
  • @ChrisLively 是的。我知道每个用户在保险库中都有自己的凭据。

标签: asp.net iis windows-server-2012


【解决方案1】:

当 APP 上的本地用户帐户尝试连接到 FILE 服务器时,它会传递其凭据(用户名和密码)。如果该组合与 FILE 机器上的用户不完全匹配,那么它将失败。

有多种方法可以“正确”地做到这一点。最常见的是有一个域设置,在其中运行 APP 服务器上的站点。这样你就可以授权用户在 FILE 服务器上拥有权限。

如果你不能有域控制器,那么用户名和密码必须在两台机器上保持同步。

【讨论】:

  • 所以机器名被忽略了?所以它不是 APP/X 确实只是 X?
  • 没错。当服务尝试连接到远程机器时,它不会在用户字段中发送它自己的机器名称。它只是发送实际的用户名。原因是为了方便这样的情况。否则,如果没有像 AD 这样的通用身份验证存储,要让事情正常工作会有点困难。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-05-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多