SharePoint: SAML and FBA authentication fail from Word, Excel, Outlook, etc

Posted On November 17, 2020

Consider the following scenario:

  • You have a SharePoint web application that uses Trusted Provider (SAML) authentication.
  • When trying to open a Microsoft Office (Word, Excel, PowerPoint, etc) document from a SharePoint library, the Office app pops up a dialog with a “Sorry, something went wrong” error:

Outlook calendar sync behavior:

  • Users have SharePoint calendars that they synchronize to Outlook.
  • If the user browses to the site and is authenticated via Internet Explorer first, then they can sync the calendar without issue.
  • However, if their authentication cookie expires, or if they manually clear out their browser cookies, Outlook throws an error when trying to sync the calendar.
  • When they click Send and Receive, it pops up an error that says:

“Sorry, something went wrong” “An unexpected error has occurred”

  • If the user then browses to the site via Internet Explorer, and is authenticated, then Outlook can sync the calendar successfully again until the cookie expires.
  • In summary, if the client machine has a valid authentication (FedAuth) cookie, then Outlook can sync the SharePoint calendar. If it does not, then Outlook is unable to complete the authentication to SharePoint, and calendar sync fails.

Notes:

  • This can also happen when using Forms Based Authentication (FBA).
  • If you use Internet Explorer (IE) as your browser, the above behaviors may intermittent. If you use a non-IE browser, it should be pretty consistent.

 

Cause:

There is a question mark in the custom sign in page for the web application (Central Administration | Manage Web Applications | <theWebApp> | Authentication Providers | <theWebAppZone>)

For example: “/_Trust/?trust=ADFS”

When an Office client tries to authenticate to SharePoint, the question mark gets encoded to %3f like this: “/_Trust/%3Ftrust=ADFS?ReturnUrl=/_layouts/15/error.aspx”

This causes the Office client to fail during the authentication redirection and results in the “Sorry, something went wrong” error.

 

Resolution:

You’ll need to change your “Custom Sign in Page” value so that it does not contain a question mark. I can’t know what your reason is for setting it that way the first place, but you have a few options:

  • If SAML / Trusted Provider is the only authentication provider enabled within the web app zone, then the “Default Sign In Page” option should work.
  • If you have both Trusted Provider and Windows authentication enabled for that web app zone, and are trying to force users to Trusted Provider auth, then a value of “_trust/default.aspx” should work.
  • If you have multiple Trusted Providers enabled for the web application zone, and are trying to direct users to one of them, or if there is some other custom logic that needs to be applied at sign-in time, then the “Custom Sign in Page” value should point to a custom aspx page that contains that logic.

 

Why do I have to authenticate a second time when opening Office files?

Office clients need to authenticate to SharePoint separately from the browser because they run in a different process on the client machine, and in most cases (IE being the exception), they cannot share the authentication cookie with the browser.

 

Why is the behavior intermittent if I use Internet Explorer?

If you use Internet Explorer to browse the site, the authentication cookie (FedAuth) is stored in a location where the Office apps can simply “borrow” that cookie from the browser. In that case, the Office app is not forced to re-authenticate.  However, if you use Chrome, Edge, or pretty much any browser other than IE, then the Office apps cannot “borrow” the authentication cookie, and instead must get their own.  That’s why you’re being directed to authenticate a second time when you open Office docs.

 

You may see this is the SharePoint ULS logs during an Office app authentication failure:

This is another way to verify you’re hitting the above issue:

w3wp.exe (0x1920) 0x1028 SharePoint Foundation General 8nca Medium Application error when access /_Trust/?trust=ADFS, Error=A potentially dangerous Request.Path value was detected from the client (?). at System.Web.HttpRequest.ValidateInputIfRequiredByConfig() at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

w3wp.exe (0x1920) 0x1028 SharePoint Foundation Runtime tkau Unexpected System.Web.HttpException: A potentially dangerous Request.Path value was detected from the client (?). at System.Web.HttpRequest.ValidateInputIfRequiredByConfig() at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

w3wp.exe (0x1920) 0x1028 SharePoint Foundation General ajlz0 High Getting Error Message for Exception System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (?). at System.Web.HttpRequest.ValidateInputIfRequiredByConfig() at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

Add a Comment