This post was most recently updated on March 4th, 2019.Reading Time: 3 minutes.
This post is about 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 an issue where you suddenly started getting exceptions for Unauthorized Access (-2147024891, System.UnauthorizedAccessException), no matter if you had access to the list or not.
We started getting this error, when requesting list items using SharePoint SOAP Web Services (namely, Lists.asmx):
<m:code>-2147024891, System.UnauthorizedAccessException</m:code> <m:message xml:lang="en-US"> Access denied. You do not have permission to perform this action or access this resource. </m:message>
This error gets thrown at you even if your user account has Global Admin permissions.
“Wait! SOAP is still around in SharePoint?”
Haha, yes, yes it is. SharePoint Web Services is built on SOAP.
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 my 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.
So, in short – the PowerShell commandlets below should help you out:
Connect-SPOService Set-SPOTenant -LegacyAuthProtocolsEnabled $True
Then wait 24 hours and try again :)
- How to fix a Teams team with no Owners? - March 31, 2020
- How to fix “HTTP Error 500.32 – ANCM Failed to Load dll” - March 25, 2020
- Why you shouldn’t attach files from other channels in Microsoft Teams? - March 19, 2020