悠悠博客 关注Ajax技术与web开发

问：我有一个企业内部网站，我希望所有通过验证的用户可以访问另一台服务器上的一个目录。我已经将远程服务器的内容映射到 Web 服务器的驱动器上，并且为了测试，为 Everyone 组授予了对这个共享资源的完全控制 NTFS 权限然后我们的应用程序通过引用驱动器盘符来访问内容。

当我们为这个目录配置集成的 Windows 身份验证时，所有用户都无法访问远程位置，但是如果我们使用基本身份验证，并指定域，用户则可以访问远程内容。我的问题是，集成的 Windows 身份验证为什么会无法记住用户访问远程服务器的凭证，而基本身份验证则可以？

答：尽管这看起来像是因为集成的 Windows 身份验证无法记住凭证而引起的问题，但事实并非如此。在确保任何站点或服务器的安全时，问题的关键在于在功能与安全性之间进行权衡。基本身份验证使用本地登录类型，也称为“交互式”登录。这种凭证类型可以委派给其他服务器。因此，可以使用通过基本身份验证获得的凭证成功地访问远程系统。访问 SQL 服务器也是如此。您可以使用基本身份验证来验证客户端，并将凭证转发给配置为使用 SQL 身份验证的 SQL 服务器。但是，当您使用集成的 Windows 身份验证来验证 IIS 服务器时，将会使用“网络”登录类型。这种登录类型的安全性远远高于基本身份验证，但是除非在企业内部网中使用 Kerberos，否则凭证无法转发至其他服务器。一旦使用了 Kerberos（且正确配置后），用户凭证就可以在整个目录林中委派（请参见 Microsoft 知识库文章 326089）。

为了方便且可靠地访问远程内容，且无需考虑身份验证类型，在配置虚拟目录来访问远程内容时，将会提示您提供对 IIS 服务器和远程服务器均有效的用户名和密码。当您访问虚拟目录时，请求将会传递至指定用户，不管该用户使用何种验证方式，都可以访问远程内容。

除非您可以使用 Kerberos，否则我建议您修改应用程序，改为使用标准的虚拟目录，而不是映射的驱动器。这样可以可靠地访问远程内容。另外，不建议使用映射的驱动器，这是因为映射驱动器包含在创建映射的用户的配置文件中。如果其他用户登录这台 IIS 服务器，映射驱动器将不存在，它们和您的应用程序之间不再存在关联关系。