By Jack Poehlman | Service Engineer on the Enterprise Mobility and Customer Experience Engineering Team
We’ve heard from a few customers that they received a company portal temporarily unavailable error. As shared in this blog post, and through several Office Message Center posts, Apple is moving to require Application Transport Security enablement for apps in the App store. ATS requires TLS 1.2 with Forward Secrecy Ciphers therefore the iOS Company Portal now has ATS enabled. We have also been communicating across multiple Microsoft services about the move to TLS 1.2 as that protocol will provide best-in-class encryption, ensure our service is more secure by default, and align with other Microsoft services such as Microsoft Office 365.
In this post, we’ll walk through what you might experience if you’re still using TLS 1.0, TLS 1.1, or weak ciphers, and also point to the troubleshooting you can do to determine if you are impacted by the Apple ATS change.
1 – First, when you launch the company portal in every day experiences, you’ll see the following screen where you’ll select “Sign in”:
2 – Then, as shown in the second screen shot below, you enter login and password. In this case, I entered iwuser@Contoso.com. If the user is on a federated domain, this screen will be forwarded to the Federation Server’s login page after selecting “Next.” For context and comparison, on Cloud managed domains, this will progress to “Enter Password” and the Microsoft logo will remain as the sign-in library (ADAL) is still on the Azure AD Login site.
3 – Now, this is where you may have seen a failure. After entering credentials and selecting “Next” as shown in the above screen shot, you see the “Company Portal Temporarily Unavailable” and “The Company Portal app encountered a problem. If the problem persists, contact your system administrator”. Below you can see a screen shot of that error. An end user could hit this message due to multiple reasons. For example, it could be due to intermittent network issues, it may have displayed because a user was not Intune licensed, or it may be because there’s a problem in the end-to-end workflow. The message is displayed when sign in failure is a primary cause.
To see if the error your end users are getting is related to the Apple ATS change, there are several free sites and services that will test SSL connections against a URL. One example of such a site is: https://www.ssllabs.com/ssltest/. We use it in this example as it provides a comprehensive report.
In the continuing example below, we’ve caused the failure against our ADFS server by disabling TLS 1.2 and 1.1 to mimic not having ATS TLS 1.2 or higher for Apple.
In this state, after going to the ssllabs website, our ADFS server scores a “C” rating. Looking at the details, you can see that Apple ATS 9 was “not simulated” due to the protocol mismatch / lack of TLS 1.2 support:
At this point in time, a “C” rating is not actually a passing rating. If you’ve got a network admin, this is a good time to bring them in for resolution, but if not, there is a wide variety of documentation out there including a collection of whitepapers on the docs site here, including Solving the TLS 1.0 problem.
Continuing with this example, in looking at the details the Cipher Suites, you can dive into whether any traffic can get through using TLS 1.2.
In looking at the details, the ADFS service with the network inspection device enabled, did not have support any of these TLS 1.2 packets. In a network packet capture, looking at the SSL communications, we could see the following error when trying to send a Client Hello offering the cipher list above. The federation service URL’s response was not the expected Server hello, instead it was:
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Level: Fatal (2)
Description: Handshake Failure (40)
Moving our ADFS server back to enable TLS 1.2 then resolved the problem. Hopefully this helps to troubleshoot this error specific to iOS enrollment.