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.
We started getting this error, when requesting list items using SharePoint SOAP Web Services (namely, Lists.asmx):
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?
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?
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”?
- Fire up your PowerShell console
If you have SharePoint Online Management Shell, feel free to use that. If not, just use PowerShell instead.
- 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 your current version of SharePoint Online Management module and install the latest
Then try to log in again. If that didn’t help, proceed!
- 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):
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.