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.
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 :)
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.
Latest posts by Antti K. Koskela (see all)
- Azure DevOps – how to package a simple DLL? - October 17, 2019
- How to use UriHelper or NavigationManager in .NET Core 3.0 & Blazor? - October 17, 2019
- Azure DevOps build fails with “The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages.” - October 16, 2019