Category: iOS

Microsoft Company Portal temporary unavailable error troubleshooting

Recently was assisting the Intune team to troubleshoot “Company Portal Temporary Unavailable” error for the iOS devices.

The Azure AD was federated with AD FS.

Looking at the Company Portal logs from mobile device the following detailed error message was discovered (extracted the part we are interested in):

InAppProcess : {context = “Failed to fetch aad service token! Error: Optional(Error with code: -1005 Domain: NSURLErrorDomain ProtocolCode:(null) Details:The network connection was lost.. Inner error details: Error domain: NSURLErrorDomain\nCode: -1005\nDescription: The network connection was lost.\nUser info: {\n   NSErrorFailingURLKey = \”https://sts.domain.com/adfs/ls/?

This error pointed us to Network/SSL issues, not Authentication.

As always used the great SSL test portal https://www.ssllabs.com/ssltest/ to check SSL settings for the AD FS public host name.

In the Handshake Simulation section we saw the following:

TLSciphers2

Looking at the supported TLS Cipher Suites saw this:

TLSciphers

Looking at the following Apple Developer site we get following information about one of the requirements for Connecting Using ATS:

The connection must use either the AES-128 or AES-256 symmetric cipher. The negotiated TLS connection cipher suite must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange, and must be one of the following:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

In this environment the Load Balancer was installed in front of Web Application Proxy (WAP) and SSL offloading was configured for AD FS farm host name.

Adjusting the supported cipher suit settings to the recommended above values has addressed the issue.

There is another great blog post about this issue troubleshooting.

And this is Intune What’s New page describing new ATS requirement.

AD FS 2.0 and Safari (iOS 9 and iOS 10) sign in issue (authentication cookies size issue)

Recently have been working on the issue when the users on iOS 9 and 10 were not able to complete the authentication from outside of corporate network (via AD FS Proxy). The users were getting the error – “There was a problem accessing the site. Try to browse to the site again. Reference number: XXX”.

The same users from iOS 11 had no issues signing in via the same AD FS farm.

The users were the members of 150-200 on premises AD security groups.

It took me some time to go over basic troubleshooting and making sure the AD FS servers have all needed patches installed – https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/updates-for-active-directory-federation-services-ad-fs, but the issue persisted.

Turned out to be a known issue, when the older Safari versions have cookies size limitation.

Looking at the captured Fiddler trace we saw the AD FS was issuing 5 MSISAuth cookies (total size around 9 Kb) and when Safari was redirected to ADFS to get the access token, only 4 MSISAuth cookies were posted to ADFS (around 8 Kb). In this case Safari was dropping the cookies.

In order to work around this issue, the customer decided to do not pass all 200 security groups in the claims.

In order to achieve this, the default “Pass through all Group SID claims” was replaced with following claim rule since the customer was using these groups in his Authorization claim rules:

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid“, Value =~ “S-1-5-21-XXXXXXXX-XXXXXXXXXX-XXXXXXXXX-XXX840|S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-124XXXX”, Issuer == “AD AUTHORITY”] => issue(claim = c);