Opening links to SSO knowledge bases from Microsoft Office

Some customers who require SSO login for their knowledge bases have run into some odd behaviors when they include links to their knowledge base articles within Microsoft Office files, including:

  • Word
  • Excel
  • Powerpoint
  • Visio

When links to KO articles behind SSO are included in MS Office files like these, some customers report that clicking on the links doesn't take them to the article that's linked. Instead, they might be navigated to:

  • Their knowledge base homepage
  • Their SSO login page--logging in just sends them to the homepage

In both cases, the specific article in the hyperlink isn't opened.

The exact same links will work properly when clicked in PDFs and Microsoft Outlook.

If you've run into this issue, it is not a KnowledgeOwl issue. It is a question of Microsoft Office not playing nicely with your Single Sign-On solution. You'll need to talk to your IT department to get it resolved. We've written this page so you can send the entire link to your IT department to provide background on the situation. There is no one-size-fits-all solution (even Microsoft doesn't officially offer one), but there are a variety of solutions that may work.

What causes this issue?

Short answer: Microsoft Office, by design, does some pre-fetching of links to try to prevent errors when clicking links. In most cases, this happens faultlessly behind the scenes, but when SSO is involved, it can strip out URL parameters or redirects, which can shorten the URL that's actually requested from Office to KnowledgeOwl to get stripped down to a login or homepage screen. You don't see this behavior in Outlook because Outlook, unlike the rest of the Office suite, doesn't do that pre-fetching; it just tries to open the URL you clicked on.

Longer answer: Microsoft discusses the issue here:

However, if you don't speak Microsoft-technicalspeak well, Wimpy Programmer's explanation of the behavior is easier to understand. Here are the most relevant sections directly quoted:

Microsoft Office and Link Pre-fetching

Now we'll look at Microsoft Office and its peculiar handling of links. When you click a hyperlink in an Office file (Word document, Excel spreadsheet, PowerPoint presentation, etc.), the URL is not immediately passed to your browser. First, Office will internally fetch the address. If the link returns a 3xx Redirection code, Office will request the new address and repeat. If the link returns a 4xx Client Error code, Office will abort the request and tell the user that the link is unavailable, having never opened a browser (I'm guessing that's the whole point of this "feature"). And if the link returns a 2xx Success code, the URL is finally opened in a browser. Only the final URL is passed to the browser; any redirects are masked by Office.

Microsoft Office and SSO

Microsoft Office conflicts with Shibboleth (and other SSO systems, I expect) because of cookies. When Office requests the protected resource, the SP redirects to the IdP login page. Office follows the redirect and the IdP login page returns a 200 response, waiting for the user's credentials. Office opens the IdP login page address in the user's browser, but the cookies describing the request are lost. After the user authenticates, the IdP doesn't know how to return the user to their SP and displays an error. Thus hyperlinks in Office files never load.


There is no single, agreed-upon solution to this issue. Your IT department will need to decide how they'd like to handle it, based on the SSO setup, their security protocols, and so on. Common solutions include:

We are not explicitly recommending or advocating for a specific solution from the above options--what is "right" varies based on your SSO, security setup, and so on. Your IT department is best positioned to decide on the right solution for you and to implement it. Hopefully these resources help them begin that process, though!