Month: December 2018

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.

Advertisements

AD FS 2016 Access Control Policies troubleshooting

The Access Control (AC) policies were introduced in AD FS 2016.

See this official documentation to get familiar with AD FS Access Control policies concept and settings.

Recently had to troubleshoot the following scenario.

Customer has Hybrid Exchange environment with email boxes located in on premises Exchange 2010 and archives located in Exchange Online.

Exchange on premises did not have Modern Authentication enabled.

Office 365 domain federated with AD FS 2016.

AD FS was configured to use Azure MFA.

The goal was to require MFA for all external users using Outlook 2016 and accessing their mailboxes and archives and skip MFA if the user is located inside corporate network.

At the beginning the following AD FS AC policy was configured for Office 365 Relying Party Trust (RPT).

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location;

Permit everyone
}

The issue with this policy is the “Permit everyone” at the second part, since this rule will allow anybody who didn’t meet requirement in first policy, to authenticate.

So the AD FS AC policy was modified the following way and applied to O365 RPT.

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location
}

And that’s where the unexpected authentication pop-up windows and MFA prompts started to happen when users inside corporate network were opening Outlook to access their email.

User continuously was receiving the Windows Security pop-up window that didn’t except correct user credentials and there was a second pop-up asking to authenticate again and that was triggering the MFA call to the user’s phone.

Analyzing the authentication flow based on the Exchange layout mentioned above, it was confirmed that its expected to have following authentication events to happen:

  1. User accessing email box located in on premises Exchange must authenticate via AD FS using legacy authentication from Intranet.
  2. When accessing email archive, Exchange Online has to authenticate user as well and since the legacy authentication was used, Exchange Online was authenticating on behalf of the user from outside of the corporate network.

By the way, due to the fact of legacy authentication flow we were not able to use Microsoft Claims X-Ray service.

To reduce the impact to production users, it was recommended to change the Access Control policy to contain these settings:
1. Permit users from the security group with MFA and exclude Intranet
2. Permit users from the security group with MFA and exclude Internet if the client IP (public IP of the office) matches the regex.
3. Permit all.

AD FS Access Control policy now looked like this.

{
Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'intranet' location;

Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'extranet' location
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit everyone
}

Applied this AD FS AC policy to Office 365 RPT and still there were two prompts when the Outlook 2016 is opened – basic authentication window when accessing on premises email box and Modern Authentication prompt with MFA when accessing EXO archive.

In the AD FS Admin logs we saw the error: “MSIS5007: The caller authorization failed for caller identity XXX for relying party trust urn:federation:MicrosoftOnline.”

And in the AD FS Debug logs see the MFA is still required regardless the fact that the authentication attempt is coming from Intranet.

After multiple additional tests and getting better understanding how the Access Control policies are applied the following AD FS AC Policy was crafted that has addressed the issue completely.

{
Permit users 
	from 'extranet' location
	and from ‘TEST’' group
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'extranet' location
	and from 'TEST' group
	and when authentication includes MFA
except 
	with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'intranet' location
	and from 'TEST' group;

Permit everyone
} 

The AD FS Access Control polices above work the following way:
1. Permits authentication coming from Internet if its EXO legacy authentication protocol on behalf of the user in the test security group coming from office public IP address;
2. Permits any other authentication for the test group coming from Internet if the MFA completed, but excludes office public IP from this rule (to make sure the first rule works as expected);
3. Permits authentication from the Intranet with no MFA for the test group (authentication to on premises Exchange)
4. And the last one catch Permit All group to make sure prod users are not affected during testing.

ADFS Access Control Policy

When the AD FS AC policy was successfully tested with the users added to the TEST group, the policy was applied to the rest of the production users by removing the TEST group condition from the first three policies and removing “Permit everyone”.