SharePoint is not broken - it just does't work

How to fix “The web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized'”

This post was most recently updated on May 14th, 2019.

Reading Time: 5 minutes.

While running some SharePoint Online -PowerShell commandlets, or connecting to a SharePoint Online site from your app, you get a following (or similar) error about your SharePoint Online credentials being unauthorized for something you should definitely be authorized to do:

Cannot contact web site ‘https://[tenant]’ or the web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized’.

And that’s not all – by digging into the full error message, you find the underlying internal error:

MSDAVEXT_Error=917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.

What awakens my curiosity, is this line:

Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.

However, when you open your browser, you can actually log in without a hitch. If that’s the case, this might be a weird internal error in SharePoint Online. Nothing you can do permissions/configuration-wise, but luckily – there’s a hazy and weird, but simple PowerShell-based fix! 

Description of the issue

The whole error might be something like this:

Cannot contact web site ‘https://[tenant]’ or the web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized’. The response headers are ‘X-SharePointHealthScore=0, X-MSDAVEXT_Error=917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically., SPRequestGuid=, request-id=, MS-CV=[i_don’t-even-know], Strict-Transport-Security=max-age=31536000, X-FRAME-OPTIONS=SAMEORIGIN, SPRequestDuration=64, SPIisLatency=1, MicrosoftSharePointTeamServices=, X-Content-Type-Options=nosniff, X-MS-InvokeApp=1; RequireReadOnly, … .

Out of these values, most of the headers are well known – basic stuff. What’s sparking my interest is this one:


That is a WebDAV (Web Distributed Authoring and Versioning) protocol returning an error for your request. While the error code isn’t (to my knowledge) officially documented anywhere, it’s commonly recognized to be a permissions -related issue. And obviously the error text describes that as well.

This might be a symptom of a weird, internal authentication issue in SharePoint Online, caused by someone tripping on a wire in Microsoft’s nearest datacenter. Or it might actually come from Azure AD in the background. It’s either one of those two, or something else :)

What’s important, is how to fix it. And that’s described below!


Running a couple of magic PowerShell spells (or commandlets, if you wish) might start a weird, internal background process, that will eventually enable the login for your SharePoint Online credentials. To be fair, I don’t even know 100% what these 2 switches do. Below, I’m offering my best guesses, on why this works like this. Proceed with caution and at your risk.

Before proceeding, though, it’s worth to mention the point that Maciej brings up in the comments section. If you’re using outdated version of PowerShell commandlets, it’s perfectly possible that a simple module update will resolve your issue. So, before flipping any of the more exotic PowerShell switches, run the commands below and see if they help:

# Uninstall your current versions of SharePoint PnP Powershell Online and install the latest
Uninstall-Module SharePointPnPPowerShellOnline
Install-Module SharePointPnPPowerShellOnline
# Uninstall your current version of SharePoint Online Management module
Uninstall-Module Microsoft.Online.SharePoint.PowerShell
Install-Module Microsoft.Online.SharePoint.PowerShell

Then try to log in again. If that didn’t help, proceed!

Flipping the switch

Next, fire up your SharePoint Online Management Shell, and run these commandlets (if you want to be careful, first run Get-SPOTenant with switches to see the values before the changes – and check with the environment’s IT and/or security team if they are other than defaults):

Set-SPOTenant -LegacyAuthProtocolsEnabled $True
Set-SPOTenant -RequireAcceptingAccountMatchInvitedAccount $False

It’s a bit weird, but seems to do the trick! It might take a moment for the changes to be propagated to all systems – or, like I suspect, the background job that gets started by “updating” these values (even if you just save them with their default values) to do whatever it does.

The two times that I’ve had to do it, it took overnight for the authentication to then start to work. I’ve heard from others, that for them it’s been updated in 30 minutes. Bottom line seems to be not to fret until some 12 hours after the change has been made.


Admittedly, the documentation for these 2 switches hasn’t been that good. On the right hand, you can see the documentation as it was in early 2018 – community contributors (myself included) have improved it since, though!

The following list offers possible explanations why these switches might help:

Microsoft's official explanation of what "LegacyAuthProtocolsEnabled" switch does
Figure 1: Microsoft’s official explanation of what “LegacyAuthProtocolsEnabled” switch does :) Not very thorough and detailed!

What’s “LegacyAuthProtocolsEnabled” and “RequireAcceptingAccountMatchInvitedAccount” do?

  • LegacyAuthProtocolsEnabled $True
    • This is $True by default, (see “more info” for links to Microsoft’s documentation) since otherwise a lot of apps (probably all but those using Modern authentication flow) will fail in authentication.
    • Figure 1 shows Microsoft’s documentation for this switch before community contributions (such as mine) to the documentation.
    • Note also this: “[Setting this to $False] may also prevent third-party apps from accessing SharePoint Online resources. Also, this will also block apps using the SharePointOnlineCredentials class to access SharePoint Online resources. For additional information about SharePointOnlineCredentials, see SharePointOnlineCredentials class.”
    • If you can modify the code or script that causes this error, you can also migrate away from using legacy authentication – and use ClientId & ClientSecret or Web Login (for example) instead! And if your customer requires this switch to be $False, the code changes are going to be your only way forward.
  • RequireAcceptingAccountMatchInvitedAccount $False
    • This should be $False by default – but setting this property might, just like with the other one, cause some weird background service to start, and eventually fix the issue.
    • Verify your current setting first by running Get-SPOTenant -RequireAcceptingAccountMatchInvitedAccount
    • This is for external accounts, and shouldn’t matter if you have a * account, or even a federated domain account. It should work pretty much in any case.
    • Microsoft’s explanation:
      • Ensures that an external user can only accept an external sharing invitation with an account matching the invited email address.
      • Administrators who desire increased control over external collaborators should consider enabling this feature.
      • Note, this only applies to new external users accepting new sharing invitations. Also, the resource owner must share with an organizational or Microsoft account or the external user will be unable to access the resource.
    • The valid values are:

      • False (default) – When a document is shared with an external user, [email protected], it can be accepted by any user with access to the invitation link in the original e-mail.
      • True – User must accept this invitation with [email protected]

Since running these commands will change authentication behavior of the tenant, please don’t run them without running the changes by the customer’s IT. And most importantly, don’t tell I didn’t warn you!

Anyway, I hope it helps, even if you’re just setting the already existing values again. It did resolve the issue for us.

More info

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.

Leave a Reply

7 Comment threads
12 Thread replies
Most reacted comment
Hottest comment thread
7 Comment authors
Jenny WardPrachiAntti K. KoskelaPrabhaMaciej Recent comment authors
newest oldest most voted
Notify of

Awesome article!!! and it works for me!!!!

and, yes it takes 24 hours after setting “True”




[…] How to fix “- – the web site does not support SharePoint Online credentials. The respons… […]


Hi. This page still pop up in Google results. So if you have this error, as a first action update your PnP modele to the newest version. It resolved the case for me. I had issue with version 2.26.1805.0 PnP and after update to PnP 3.8.1904.0 error is gone.
Uninstall-Module SharePointPnPPowerShellOnline
Install-Module SharePointPnPPowerShellOnline


I’m using an app to read customer’s SharePoint file details after going through a OAuth authorization process for some monitoring. I’m using the SharePoint RestAPI call getFileById (with the Bearer Token). The app permissions for SharePoint have been set to Sites.Read.All. When I try to do getFileById, I get the above error which you have mentioned.

But when I change the app permission to Sites.FullControl.All (and reauthorize), it works like a charm.
My question is – since I’m doing a read operation, why do I get this error if I set the app permission to Sites.Read.All? I cannot take a FullControl permission, it has to be Read only. Can you help? Thank you.


I am trying to download an excel file from SharePoint online using a c# script task in ssis. When I am using the SharepointOnlineCredentials and hard coding the username and password it is working fine for me. But when I try CacheCredentials.DefaultCredentials I am getting the error:
The remote server returned an error: (403) Forbidden.
and after digging into it the following error as well:
X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.

Could you help me with this? Will the above solution solve this issue?
Thank you.

Jenny Ward
Jenny Ward

Good morning, and thank you for this helpful information! I have a client for whom we are getting this error, resulting in a data warehouse sync not working; LegacyAuthProtocolsEnabled IS set to False on their system; The problem only arose 3 days ago, which makes us believe they changed this from the default True to False, which they say did not occur, but I don’t know how to check that (or advise them to). Can you advise if there’s a way to determine when this setting was changed? It would go a long way to convince the client to set it back to True. Thank you!