If you could just fix SharePoint... That would be great.

Fixing “-2147024891, System.UnauthorizedAccessException” when accessing SharePoint SOAP Web Services

This post was most recently updated on March 10th, 2022.

4 min read.

This article explains how to fix error 2147024891 (or sometimes -2147024891), “System.UnauthorizedAccessException” when accessing functionality in SharePoint that’s built on top of SOAP Web Services. In a sense, we’re delving into some legacy stuff – Microsoft has still kept SOAP-based SharePoint Web Services included in the product, since a lot of functionality has been built on top of them.

We encountered the issue where you suddenly started getting exceptions for Unauthorized Access (-2147024891, System.UnauthorizedAccessException) for accessing list items, no matter if you actually had access to the list or not.

Error description

We started getting this error, when requesting list items using SharePoint SOAP Web Services (namely, Lists.asmx):

-2147024891, System.UnauthorizedAccessException

Access denied. You do not have permission to perform this action or access this resource.

SharePoint Online might throw this error at you, even if your user account has Global Admin permissions!

“Wait, wait, wait… Is SOAP still available in SharePoint?”

Haha, yes, yes it is (I say, as I’m laughing through my tears). SharePoint Web Services is built on SOAP, and it’s still not going anywhere.

While you probably shouldn’t build anything new using these services, there’s bound to be a lot of legacy stuff that uses them.

Microsoft puts it this way:

Two API sets are still supported in the SharePoint framework for backward compatibility, but we recommend that you not use them for new projects: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

Deprecated API sets

The asmx – SOAP – Web Services generally speaking should not be used anymore.

Marc D Anderson puts it this way (already in 2014):

I am not aware of any official specific time frames for the SOAP services going away, and the Product Group would need to give us a good, long lead time because lots of code depends on it, SPServices or not. Many people have built managed code-based solutions which use the SOAP Web Services as well. GetListItems is a workhorse operation no matter how you build your solutions.

SPServices: What About Deprecation of the SOAP Web Services?

Microsoft’s old stance on the matter is well described in the picture below – while Silverlight APIs, JavaScript APIs (namely JSOM) and in a lot of cases Server APIs as well are more or less already gone, the purple box (REST/OData Endpoints) is the API set replacing SOAP Web Services almost entirely.

As we can see today, the APIs were still there – and they started throwing errors our way!

Can’t deny it, though – my first thought was, that now it finally happened: Microsoft just shut down the service it deprecated already in 2013(?). But it actually only happened on one tenant, so I guess that wasn’t the case after all :)

But what was it, then?

Reason

Okay, this is basically magic. It’s a bit weird, but the resolution here is the same as in this case:

Surprising, but the underlying error is apparently the same. So enabling “Legacy Auth Protocols” fixes the issue for the SOAP Web Service authentication.

Next, let’s see how to do that!

Solution to SOAP Web Service authentication issues in SharePoint Online

Let’s jump to the solution, then!

The “How-to” below is basically copied from my other blog post, here: How to fix “The website does not support SharePoint Online credentials. The response status code is ‘Unauthorized’” as the solution is the same.

Time needed: 12 hours.

How to fix “The website does not support SharePoint Online credentials. The response status code is ‘Unauthorized'” or “MSDAVEXT_Error=917656”?

  1. Fire up your PowerShell console

    If you have SharePoint Online Management Shell, feel free to use that. If not, just use PowerShell instead.

  2. Verify you’re using the latest module versions

    Before doing anything more drastic, it’s worth verifying you have the latest versions of the necessary PowerShell modules available. If you’re using an outdated version of PowerShell commandlets, it’s quite 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 and install the latest
    Uninstall-Module Microsoft.Online.SharePoint.PowerShell
    Install-Module Microsoft.Online.SharePoint.PowerShell


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

  3. Flip ’em switches!

    Next, run these commandlets (if you want to be careful, first-run Get-SPOTenant with switches to see the value before the change – and check with the environment’s IT and/or security team if they are other than defaults):

    Connect-SPOService
    Set-SPOTenant -LegacyAuthProtocolsEnabled $True


    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.

    On the two occasions that I have 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. The bottom line seems to be not to fret until some 12 hours after the change has been made.


Further reading

mm
5 1 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments