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.<\/p>\n
So, how do we get back to the old ways where a user is prompted with the download dialog, Open\/Save\/Cancel.<\/p>\n
Block all of the “enhancements” that have been added to IIS to let IE and Office “discover” that you’re on a SharePoint site.<\/p>\n
In IE9 and IE10, IE will see that the mimetype is an office document, launch said office prodcut, and send along the document URL. \u00a0At this point Office says, well, lets check this URL to see if it really is SharePoint. \u00a0Office 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. \u00a0Office then gives the user options for checking in and out directly from the Office client<\/p>\n
Fix: Block the HTTP verbs Options and Propfind HTTP Verbs<\/p>\n
IE11 makes use of a newer response header called X-MS-InvokeApp. \u00a0This tells IE hey, this is an Office Document, hosted on SharePoint, and you should invoke whatever office application you have. \u00a0If it happens to the full MS Office suite, lets go ahead and try to open in integrated mode. \u00a0On top of that, just to be sure Office will also execute a HEAD\u00a0http request and check the response headers itself.<\/p>\n
Fix: Remove\/rename the X-MS-InvokeApp response header in IIS and also block the HEAD tag. (in addition to the IE9\/IE10 fixes)<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading SharePoint 2013 – Office + Claims<\/span>