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'” error

This post was most recently updated on July 11th, 2018.

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, ...  .

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 hell if I know, it might actually come from Azure AD in the background.


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.

Then, 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.


The following 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!
  • LegacyAuthProtocolsEnabled $True
    • This should be $True by default, otherwise a lot of apps (probably all but those using Modern authentication flow) will fail in authentication. From Figure 1, you can find Microsoft’s description of this switch…
    • 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!
  • 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. 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,, 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

Hope it helps! It did for us.

More info

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial 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.

5 thoughts on “How to fix “- – the web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized'” error

    1. Hi SM,

      Awesome, happy to hear that! It is a really weird fix, and I don’t know what kind of scheduled job it’s kickstarting (and hence the delay)… But at least it solves the issue :)

      Let me know if you encounter any side effects though! Would love to document them, too.

Leave a Reply

Your email address will not be published. Required fields are marked *