Partager via

The Azure Access Control service is unavailable in a Provider Hosted App on prem after disabling SSL 3.0

  • Article

The short answer…

If you disable SSL 3.0 on your remote web server and you are using remote event receivers then you must also disable SSL 3.0 on your SharePoint WFE’s.

The long answer…

This is a complicated one with a lot of moving parts and I’m still not sure about the root cause.  There are other reasons for this error that I’ve researched, but this is my tale.

There are some prerequisites that must be in place in order to see this behavior

1)       You're running on prem (or possibly a cloud VM that has not had it's SCHANNEL settings changed from the default) and the SharePoint WFE is running on a different machine than is your Provider Hosted App.

2)      You are using Remote Event Receivers

Recently, the project I’m working on underwent an information security review, one of the issues raised was that SSL 3.0 was enabled on our remote web server.  SSL 3.0 is prone to the POODLE attack, a pretty tough hack to throw but a vulnerability nonetheless. Now in the environment that we were using for the review we had no control over the SharePoint farm but we did have control over the remote web server where the Provider Hosted App runs.  Ok, no big deal, we’ll just shut off SSL 3.0 on our web server and be done with it.  There are plenty of posts detailing the process for enabling and disabling different SCHANNEL protocols, this is one.

Everything seemed to be working well, the app itself was fine, pages rendering and data through the high trust connection was retrieved with no problem.  But then I noticed that our Remote Event Receivers (RERs) weren't firing, we do some data entry validation in our RERs and I was not seeing the validation error messages that it sends back to SharePoint.  So a colleague started looking though the ULS and found this

App token requested from appredirect.aspx for site: 11111111-1111-1111-1111-111111111111 but there was an error in generating it.
This may be a case when we do not need a token or when the app principal was not properly set up.
LaunchUrl:https://app-myapp.mydomain.net/Pages/DataEntry.aspx?SPHostUrl=https://myapp.mydomain.net&SPLanguage=en-US&SPClientTag=0&SPProductNumber=15.0.4631.1000&SPAppWebUrl=https://App-11111111111111.mydomainpphost.net/myapp&SPListItemId=1&SPListId={11111111-1111-1111-1111-111111111111}
Exception Message:The Azure Access Control service is unavailable.
Stacktrace: at Microsoft.SharePoint.ApplicationServices.SPApplicationContext.GetApplicationSecurityTokenServicesUri(SPServiceContext serviceContext)
at Microsoft.SharePoint.ApplicationServices.SPApplicationContext..ctor(SPServiceContext serviceContext, SPIdentityContext userIdentity, OAuth2EndpointIdentity applicationEndPoint)    
at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForApplicationContext(SPIdentityContext userIdentityContext, String applicationId, Uri applicationRealm, SPApplicationContextAccessTokenType applicationTokenType, SPApplicationDelegationConsentType consentValue)    
at Microsoft.SharePoint.SPServerToAppServerAccessTokenManager.GetAccessTokenPrivate(SPServiceContext serviceContext, String appId, Uri appEndpointUrl, SPAppPrincipalInfo appPrincipal, SPApplicationContextAccessTokenType tokenType, Boolean useThreadIdentity, SPUserToken userToken)    
at Microsoft.SharePoint.SPServerToAppServerAccessTokenManager.GetAccessTokenFromThreadIdentityOrUserToken(SPServiceContext serviceContext, String appId, Uri appEndpointUrl, SPApplicationContextAccessTokenType tokenType, SPAppPrincipalInfo appPrincipal, Boolean useThreadIdentity, SPUserToken userToken)
at Microsoft.SharePoint.ApplicationPages.AppRedirectPage.ValidateAndProcessRequest().
Since this is a nonfatal error, it will be sanitized and posted to the app as part of the app launch.

We are on prem and not using ACS, the error message is misleading.  So I tested the scenario in a farm where I had full control of all machines and tried the same steps with the same result.  I then disabled SSL 3.0 on the SharePoint WFE as well and then everything started working.  All good but I’m still at a loss as to why the SCHANNEL connection would not start with or at least fail over to TLS 1.0, which was enabled on both servers and is more secure.  It may be that weak ciphers need to be disabled, etc., etc.  I just haven’t had the time to pursue it.

What I ended up with was TLS 1.0,1.1,1.2 enabled and SSL 2.0,3.0 disabled on SP WFE’s and remote web servers.

Before I close out I did test unsuccessfully with some other SCHANNEL settings as well and here are some of the results

1)      SSL 3.0, SSL 2.0, TLS 1.0 disabled and TLS 1.1, 1.2 enabled on WFE and remote web server.

SharePoint responds with a blank page, login is not requested.  Non starter here, not sure if this is possibly a cert issue.

2)      SSL 3.0, SSL 2.0, TLS 1.0 are disabled, TLS 1.1, 1.2 are enabled on remote web server,
SSL 2.0 is disabled, SSL 3.0 TLS 1.0, 1.1, 1.2 are enabled on SharePoint WFE.

ERROR: The client and server cannot communicate, because they do not possess a common algorithm

TLS 1.0 at least must be enabled, when TLS 1.0 is disabled on the remote web server the connection through the high trust cert to SharePoint is trying to find a common algorithm and I'm assuming the cert cannot do TLS 1.1 or 1.2 or the SharePoint server cannot handle TLS 1.1, 1.2.

I've gone so far as to decompile the SharePoint assemblies and begin jumping through the code but there is more research to be done here and I hope to have some time soon, but until then hopefully this information will help somebody.  Please chime in if you have any input.

Comments

  • Anonymous
    February 05, 2015
    Doh! I had TLS 1.0,1.1,1.2 DISABLED and SSL 2.0,3.0 ENABLED!Thanks BoodaBlog!