- You are redirected to a logon page or an error page
- You are prompted for authentication information.
- You open the Office document in edit mode outside the Web browser.
- The Web site in the hyperlink uses a Single Sign-On (SSO) authentication system that relies on HTTP session cookies for client identification. Even if you have already provided user credentials, you are prompted to provide the user credentials again.
Because the sessions are independent, session cookies are not shared. If the SSO system exclusively relies on session cookie information, the SSO system may not appear to work because the same user moves from more than one session. This behavior is a fundamental design limitation of an SSO system when the SSO system is not designed to support SSO authentication across more than one browser or Web-aware application on the client desktop. Because Office is a fully Web-aware application, the issue may appear unique to Office applications if they are the only Web-aware clients that are installed by the client. However, the root cause of this issue is not limited to Microsoft Office, and this problem may occur when you use third-party software.
Hyperlinks from Internet Explorer to OfficeIf this issue occurs when hyperlinks on a Web page open an Office file and the Web page is hosted in Internet Explorer, you can avoid this issue by explicitly marking the content as a read-only download instead of as an inline navigation.
To do this, add a custom HTTP header to the GET response for the Office file contents. Add the "Content-Disposition: Attachment" header. When a GET response contains this header, Internet Explorer prompts the user to open or save the download. If the user chooses to open the download, the file opens from the Internet Explorer Temporary File cache read-only. The user may choose to modify and save the file locally. However, the user will not be able to save the file to the server or collaborate with Web services for the Web site. Therefore, this solution only works if you intend to make the file read-only.
You can set the "Content-Disposition" header by using code in Microsoft Active Server Pages (ASP), in Microsoft ASP.NET, or in ISAPI when you work with dynamically generated content. If the content is static, you can configure the header for a given file or folder by using IIS Manager and the IIS metabase.For more information about the Content-Disposition HTTP header, click the following article number to view the article in the Microsoft Knowledge Base:
Hyperlinks from Office to Internet Explorer or to another Web browserIf this issue occurs when you click hyperlinks in Office documents that either directly open HTML Web content or are redirected to HTML content, client users can avoid the problem by enabling a registry key to send the hyperlink navigation to the browser instead of directly binding to the hyperlink from Office. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
When you use this registry setting, the HLINK component that is used by Office opens the hyperlink in the default Web browser. This registry setting affects all HLINK clients, not just Office. Therefore, use this registry key carefully. For more information about issues that may occur if you use this workaround, click the following article number to view the article in the Microsoft Knowledge Base:
Additionally, Microsoft is investigating how end users use Office to better predict and manage the following scenarios:
- The user intends to open a hyperlink in read-only mode. In this scenario, the hyperlink is opened in browse mode.
- The user wants to modify the content. In this scenario, a new session is required for authoring and collaboration.
If you are an SSO designer or developer, you can add support for multiple-session clients. For example, you may use the following methods:
- Use persistent cookie information and session cookie information to identify when a single client has crossed sessions between applications on the desktop. Then, provide Web responses either to transfer the client back into single session or to authenticate the new session.
- Use a client-side component to create an integrated authentication system. Use this integrated authentication system to authenticate all processes that are started under the same user authentication token.
- Use certificates or another security-enhanced but persistent identification method to authenticate the client.
- For an HTTP request that may be a multiple-session client request, issue a client-side redirect response instead of a server-side redirect response. For example, send an HTTP script or a META REFRESH tag instead of an HTTP 302 response. This change forces the client back into the default Web browser of the user. Therefore, the default browser session can handle the call and can keep the call in a single, read-only session.
This method does not allow for authoring. However, this method makes it clear that the SSO system does not handle multiple-session clients and wants the client to stay in the default browser session only.
Article ID: 899927 - Last Review: Mar 29, 2017 - Revision: 2