Troubleshooting: Links to IdP Realms Embedded in Office Documents Fail

Version Affected: All
 
 

Overview

When an Office document (such as Word or Excel) contains a link to an IdP realm, or to a resource protected behind SecureAuth IdP authentication (such as a federated Service Provider), clicking that link can fail if the user's default system browser is not Internet Explorer. This typically returns an error to the user such as "System Error: We are unable to continue at this time":

Cause

Clicking a link inside an Office document triggers three separate HTTP requests:

1. A HEAD request is made to the realm. This is part of Office's "Safe Links" feature, which checks that a link is safe before allowing the user to open it. This request's user agent string includes Microsoft Office plus the application name, but the request behaves as Internet Explorer.
2. A GET request follows, which follows any redirects in the realm's workflow. If WindowsSSO or Transparent SSO is enabled on the realm, this request can end at a post-authentication page — on SAML realms, this is where the SAML response from the IdP is sent back to the browser (Internet Explorer). This request's user agent string includes ms-office.
3. A final GET request is made using the user's actual default system browser, going directly to the URL reached in step 2 — the workflow's ending URL, not the realm's actual starting URL. Unless the default browser is also Internet Explorer, this breaks the workflow: the new browser goes straight to that ending URL without going through the realm's authentication workflow, and because it's a different browser, it doesn't share Internet Explorer's session or cookies.

The following filtered IIS log shows an example of these three requests, where the default browser is Chrome (highlighted in red):

Resolution:

Because the problem is that the default system browser starts at the wrong URL in step 3, either of the following resolves it:

Server-Side Fix: Create an IIS URL Rewrite rule that responds to any request from an Office user agent with a 200 response. This makes the correct starting URL for the workflow — the one returned in step 2 — the URL the default system browser uses in step 3.

Client-Side Fix: Add the ForceShellExecute registry key so Office opens links using the default system browser directly, instead of its own built-in method (Internet Explorer). This way, in step 3 the default system browser already has the session and cookies obtained in step 2. See Microsoft's troubleshooting documentation for the registry key's exact location and value. The 32-bit version of the key may be needed instead of the 64-bit version, depending on the installed version of Office.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.