现象
单击Microsoft 办公室文档中的超链接时，可能会遇到以下行为，然后才能打开请求的页面：
- 重定向到登录页或错误页
- 系统会提示输入身份验证信息。
通常，如果满足以下条件，则会发生此行为：
- 在 Web 浏览器外以编辑模式打开 Office 文档。
- 超链接中的网站使用依赖于 HTTP 会话 Cookie 进行客户端标识的单一登录（SSO）身份验证系统。 即使已提供用户凭据，系统也会提示你再次提供用户凭据。
原因
如果服务器支持 Web 创作和协作，Office 允许编辑和创作网站上的文档。 首先，Office 尝试与 Web 服务器通信。 然后，Office 会尝试使用Microsoft超链接库（Hlink.dll）和 URLMON API 直接绑定到资源。
当 Office 发送网页请求时，可能会重定向到 SSO 系统的网站登录页。 发生此行为的原因是 Office 会话独立于你可能已提供用户凭据的 Web 浏览器会话。
由于会话是独立的，因此不会共享会话 Cookie。 如果 SSO 系统完全依赖于会话 Cookie 信息，则 SSO 系统可能不会正常工作，因为同一用户从多个会话移动。 当 SSO 系统未设计为在客户端桌面上的多个浏览器或 Web 感知应用程序中支持 SSO 身份验证时，此行为是 SSO 系统的基本设计限制。 由于 Office 是一个完全感知 Web 的应用程序，因此，如果问题是唯一由客户端安装的 Web 感知客户端，则Office 应用数据删除可能是唯一的。 但是，此问题的根本原因不限于Microsoft 办公室，在使用第三方软件时可能会出现此问题。
解决方法
问题是 Web 服务器使用的 SSO 系统的一个限制。 但是，可以使用下列方法之一来减少受 SSO 保护的网站的当前影响。
从 Internet Explorer 到 Office 的超链接
如果在网页上的超链接打开 Office 文件并且网页托管在 Internet Explorer 中，则可以通过将内容显式标记为只读下载而不是内联导航来避免此问题。
为此，请将自定义 HTTP 标头添加到 Office 文件内容的 GET 响应。 添加“Content-Disposition： Attachment”标头。 当 GET 响应包含此标头时，Internet Explorer 会提示用户打开或保存下载。 如果用户选择打开下载，该文件将从 Internet Explorer 临时文件缓存只读打开。 用户可以选择在本地修改和保存文件。 但是，用户无法将文件保存到服务器，也无法与网站的 Web 服务协作。 因此，仅当打算将文件设为只读时，此解决方案才有效。
可以使用 Microsoft Active Server Pages （ASP）、Microsoft ASP.NET 中的代码或在 ISAPI 中使用动态生成的内容时设置“Content-Disposition”标头。 如果内容是静态的，则可以使用 IIS 管理器和 IIS 元数据库为给定的文件或文件夹配置标头。 有关 Content-Disposition HTTP 标头的详细信息，请参阅 如何为已知的 MIME 类型引发文件下载对话框。
从 Office 到 Internet Explorer 或其他 Web 浏览器的超链接
如果在 Office 文档中单击直接打开 HTML Web 内容或重定向到 HTML 内容的超链接，则客户端用户可以通过启用注册表项将超链接导航发送到浏览器而不是直接从 Office 绑定到超链接来避免此问题。 有关详细信息，请参阅在 Office 中单击超链接时显示的错误消息：“找不到 Internet 服务器或代理服务器”。
注意
无论安装的 Office 版本如何，在 Office 中单击超链接时，在错误消息中指定的确切位置添加注册表项：“找不到 Internet 服务器或代理服务器”。
使用此注册表设置时，Office 使用的 HLINK 组件将在默认 Web 浏览器中打开超链接。 此注册表设置影响所有 HLINK 客户端，而不仅仅是 Office。 因此，请仔细使用此注册表项。
更多信息
为了完全解决此问题，我们鼓励 SSO 提供程序开发一个系统，允许 Web 创作和使用多个会话的客户端。 此配置增加了 SSO 系统的复杂性。 但是，此配置还提供客户端最的可用性选项。 Microsoft目前正在与长期解决方案的关键 SSO 提供程序合作。
此外，Microsoft正在调查最终用户如何使用 Office 更好地预测和管理以下方案：
- 用户打算在只读模式下打开超链接。 在此方案中，超链接在浏览模式下打开。
- 用户想要修改内容。 在此方案中，创作和协作需要新的会话。
这些配置更改可能会减少“症状”部分中描述的问题的影响。 当用户访问不支持包含多会话客户端的配置的 SSO 站点时，这些更改也可能为用户增添灵活性。
如果你是 SSO 设计器或开发人员，则可以添加对多会话客户端的支持。 例如，可以使用以下方法：
使用持久性 Cookie 信息和会话 Cookie 信息来标识桌面上的应用程序之间何时有单个客户端跨会话。 然后，提供 Web 响应，将客户端传输回单个会话或对新会话进行身份验证。
使用客户端组件创建集成身份验证系统。 使用此集成身份验证系统对在同一用户身份验证令牌下启动的所有进程进行身份验证。
使用证书或其他安全性增强但持久性标识方法对客户端进行身份验证。
对于可能是多会话客户端请求的 HTTP 请求，请发出客户端重定向响应，而不是服务器端重定向响应。 例如，发送 HTTP 脚本或 META REFRESH 标记，而不是 HTTP 302 响应。 此更改强制客户端重新进入用户的默认 Web 浏览器。 因此，默认浏览器会话可以处理调用，并且可以将调用保留在单个只读会话中。
此方法不允许创作。 但是，此方法明确表示 SSO 系统不会处理多会话客户端，并且希望客户端仅保留在默认浏览器会话中。
此配置更改的确切方法取决于设计目标和要与客户端桌面集成的级别。