SharePoint is not broken - it just does't work

(Literally) Breaking: Changes to app authentication on SharePoint! 😵

Reading Time: 4 minutes.

This article explains how to get rid of sudden and unexplainable 401 Access Denied errors when trying to authenticate against a fairly fresh Microsoft 365 / SharePoint Online tenant. This issue seems to be caused by a long-ish project to finally retire ACS – Azure Access Control service) on SharePoint (it’s retired everywhere else already!)

Note: This is an updating story, as the situation with ACS is definitely… Developing. Yeah, let’s call it that. It’s a developing situation.

Problem

In the beginning of September, a lot of threads, chats and tickets started popping up about apps and scripts suddenly failing to authenticate against SharePoint Online.

One way to reproduce this issue is to use app-only authentication in OfficeDevPnP’s AuthenticationManager:

var authman = new OfficeDevPnP.Core.AuthenticationManager();
using (Microsoft.SharePoint.Client.ClientContext ctx = authman .GetAppOnlyAuthenticatedContext(appUrl, clientId, clientSecret))
{
  Web web = ctx.Web;
  context.Load(web, w => w.Id, w => w.Title);
  context.ExecuteQueryRetry();
}

The very low-key and non-descriptive error was simply:

"The remote server returned an error: (401) Unauthorized."

Sometimes with an additional insult to injury:

{"error":"invalid_request","error_description":"Token type is not allowed."}

The weirdest part? The same code or script might work just fine for other tenants. The only difference should be the age of the tenant you’re authenticating against – it should be provisioned in or after August 2020.

Reason

This has been a long time coming I suppose, but Microsoft is pushing users away from ACS and using Client Id & Client Secret -combo to authenticate against Microsoft 365. Some time during 2020, Microsoft added a new tenant-level property called “DisableCustomAppAuthentication” to SharePoint Online. This property was first surfaced in the August 2020 release of SharePoint Online CSOM. This release is available as a NuGet package with version 16.1.20412.12000.

This property should be pretty useful for a gradual move away from ACS – your organization can approach whatever deadline Microsoft sets for disabling ACS completely by “soft-disabling” it first with this property, and seeing if something breaks. Furthermore, disabling ACS is definitely a security improvement, as leaking a client id and client secret might’ve lead to anyone being able to access the tenant from anyone with zero oversight and very bad governance in general.

However, this is soiled pretty badly by the weird rollout. Unfortunately, someone at Microsoft made the decision to set this property to be true by default, and it’ll affect any tenants provisioned after sometime late August, 2020.

That’ll break a lot of custom functionality like apps or PowerShell scripts that work on any older tenants.

And obviously, the whole security aspect is also completely destroyed by the fact that since you’ll now have to use Azure AD, which doesn’t contain granular, site-level permissions for app authentication. At all. So any app registration either gets everything, or nothing.

With ACS, you could assign permissions on a per- site collection level.

So much for security improvements!

But at least good folks at Microsoft seem to be aware of the issues with this default setting:

Solution

Well, essentially, you’ve got 2 options. Let me explain them below!

Time needed: 15 minutes.

How to fix “401 Unauthorized” when using app authentication on a SharePoint tenant that was provisioned after August 2020?

  1. Move away from the old, app-only authentication using Client Id and Client Secret

    This would be the way forward – for an application authentication scenarios, you’d need to register your app in Azure Active Directory, but in that case you can’t manage permissions granularly, at all.

  2. Set the property DisableCustomAppAuthentication to false.

    You’ll need to have at least SharePoint Administrator permissions to run this.

    First of all, update your SharePoint Online PowerShell module to the latest version. After that, authenticate, and then run this below:

    Set-SPOTenant -DisableCustomAppAuthentication $false

    This’ll enable you to still use the ACS for the time being.

… aaand you should be done! Until it breaks again.

References

Also worthwhile to see this Twitter conversation by my colleague Vardhaman:

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