Version Affected: All
When an Office document (e.g. Word, Excel etc.) contains a link to an IdP Realm (e.g. https://idp.domain.com/SecureAuth123), or a link to a resource that is protected behind authentication via SecureAuth IdP (e.g. a Service Provider federated with SecureAuth IdP) and the default system browser on the users workstation is not set to Internet Explorer, clicking on the link can fail.
This can manifest in different ways depending on how the workflow and any redirection between realms is configured but commonly results in an error being returned to the end user e.g.
"System Error: We are unable to continue at this time"
Analysis of the IIS logs showing the traffic generated when a link is clicked from within an Office application shows that there are 3 requests made:
- a HEAD request is made to the realm, this is part of the "Safe Links for O365 Applications" functionality, which checks links are safe before allowing the user to request them: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/safe-links?view=o365-worldwide#safe-links-settings-for-office-365-apps
This will have a User Agent containing Microsoft+Office plus the name of the application but is most likely Internet Explorer masquerading the user agent, e.g.:
- a GET request is then made which will follow any redirects within the realm workflow. If WindowsSSO or Transparent SSO is enabled on the realm then it's likely this will end up on a post authentication page. On SAML realms this means the SAML response from the IdP is successfully sent back to to the browser (IE).
This time the masqueraded user agent will contain "ms-office" e.g.
- A final GET request is now made using the default system browser going directly to the final URL landed on in step 2, e.g. direct to the post authentication page. Unless the default browser is Internet Explorer, this breaks the workflow because the new browser is going directly to the final URL without going through any of the prior workflow and because it's a different browser it will not share the session or any cookies with Internet Explorer (which did go through the workflow properly).
This filtered IIS log shows an example of the above 3 steps where the default browser is set to Chrome (in red):
Because the problem arises from the default system browser not starting at the correct URL there are 2 options available to resolve it:
Create an IIS rewrite rule that responds to any requests from Office user agents with a 200 response. This will mean that the correct starting URL for the workflow (returned in Step 2) will be used by the default system browser in Step 3.
Here is an example of a rule found to successfully work:
Add the ForceShellExecute registry key to make Office use the default system browser when clicking the links inside Office documents instead of the built-in method (Internet Explorer).
This will mean that in Step 3 the default system browser will already have the session and cookies obtained in Step 2::
Note It may be necessary to use the 32 bit version of the registry key if the 64 bit version doesn't work for the version of Office installed.
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.
Please sign in to leave a comment.