SharePoint 2013 – Office + Claims

With newer releases of IE and Office, we’re seeing more and more of our SharePoint sites using claims authentication present users with login prompts directly in Office applications. As a security best practice, we avoid leaving persistent cookies around on end user devices. The only issue with this is that when a user attempts to click on a link to an office document, Office will often try to directly open up the file directly from the SharePoint site as opposed to local cached or downloaded copy. When it does so, it will not be able to “share” the authentication session and there will a fresh login prompt. Depending on the level of customization of your SharePoint site, and the inner workings of your trusted identity provider; your user may never get to the document. In any case there are a lot of extra clicks and a poor user experience.

So, how do we get back to the old ways where a user is prompted with the download dialog, Open/Save/Cancel.

Block all of the “enhancements” that have been added to IIS to let IE and Office “discover” that you’re on a SharePoint site.

In IE9 and IE10, IE will see that the mimetype is an office document, launch said office prodcut, and send along the document URL.  At this point Office says, well, lets check this URL to see if it really is SharePoint.  Office will execute direct http requests with the HTTP Verbs Options and Propfind which (assuming you login) SharePoint responds well to and says, yeah sure I’m a SharePoint site.  Office then gives the user options for checking in and out directly from the Office client

Fix: Block the HTTP verbs Options and Propfind HTTP Verbs

IE11 makes use of a newer response header called X-MS-InvokeApp.  This tells IE hey, this is an Office Document, hosted on SharePoint, and you should invoke whatever office application you have.  If it happens to the full MS Office suite, lets go ahead and try to open in integrated mode.  On top of that, just to be sure Office will also execute a HEAD http request and check the response headers itself.

Fix: Remove/rename the X-MS-InvokeApp response header in IIS and also block the HEAD tag. (in addition to the IE9/IE10 fixes)

Leave a Reply