no longer able to use OfficeDevPnP.Core.AuthenticationManager OR PnP.Framework.AuthenticationManager().GetACSAppOnlyContext

I usually run those command inside my CSOM code to authenticate to Office 365 using ClientId + ClientSecret:-

using (ClientContext context2 = new PnP.Framework.AuthenticationManager().GetACSAppOnlyContext(siteUrl, clientId, clientSecret, AzureEnvironment.Production)) &

using (ClientContext context3 = new OfficeDevPnP.Core.AuthenticationManager().GetAppOnlyAuthenticatedContext(siteUrl, clientId, clientSecret, AzureEnvironment.Production))

But starting from yesterday the above commands are raising these errors:-

Unhandled Exception: Microsoft.IdentityModel.SecurityTokenService.RequestFailedException: Token request failed. —> System.Net.WebException: The remote server

any advice? i checked the expiry date for the app and it is still valid till july 2021… also i opened a ticket with Microsoft and they mentioned that they do not support these commands…

[nathan-swannet]

Since a few days, more and more of our customers are reporting this issue.

Sometimes the code which uses the Pnp.Framework and a client id and secret works and other times it doesn’t. We make use of the function GetACSAppOnlyContext in the AuthenticationManager.

When it fails, we get the same error stating the Token request failed.. In Fiddler we see that the tunnel to customer.sharepoint.com:443 fails on the TLS Handshake.

The windows server, which hosts the IIS site invoking the SharePoint calls is a Windows Server 2012 machine. We already took these steps to no avail:

• SchUseStrongCrypto and SystemDefaultTlsVersions set to 1 in both registry locations (as stated in the TLS Best Practices)
• Double checked the .NET Framework version of the code (which is .NET 4.8)

We also created a small test console app in .NET 4.8 to isolate the issue and we can reproduce it there. It still seems to occur at random times. We suspect this is the load balancer of SharePoint which sometimes results in a server where the TLS updates are not yet pushed to.

EDIT:

After more testing we discovered that none of these cyphers were supported on the Windows Server 2012 machine:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Only the above cyphers are supported by microsoft (as stated in this article). By using the IISCrypto tool we were able to select these extra cyphers which solved our issue:

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

[nathan-swannet]

You don’t need to change the order. It already prioritises the strongest supported cypher suite. The tool can be removed safely. The configuration is applied to the server itself with the help of the tool. If no group policy is active which can override the supported cyphers, you’re good to go.