The mobile world is still a fragmented world, where various versions of Apple’s iOS and Google’s Android compete for usage share. With people still getting accustomed to today’s throw-away society and handset manufacturers and vendors tailoring to their needs, there’s people using three years old Operating Systems on mobile phones they just purchased.

The situation

When you implement Azure Multi-Factor Authentication (MFA) Server in a Hybrid Identity scenario, you’d be wise to use your Web Application Proxy infrastructure to publish Azure MFA Server’s User Portal and Mobile Portal.

The issue

With default settings, Web Application Proxies and Active Directory Federation Services (AD FS) Servers running Windows Server 2012 R2 (and up) don’t support Server Name Indication (SNI).

Server Name Indication (SNI) is an extension to the TLS protocol that allows any connecting device to indicate which hostname it is attempting to connect to at the start of the TLS handshake process. This allows a server to present multiple SSL/TLS certificates on the same IP address and TCP port. It allows multiple secure websites to be served by the same IP address without requiring all those sites to use the same certificate.

Therefore, when you try to activate a mobile device running Android 5.x, while accessing the Mobile Portal through a Web Application Proxy with default settings or any proxy, firewall and/or load balancer that doesn’t offer Server Name Indication), you receive the following error:

Unable to add the account

We couldn’t add the account as
your device does not trust the
activation URL. Please contact your
IT administrator.

 

CANCEL REPORT

The cause

Android 5 supports SNI, according to Qualys, but the official Microsoft Authenticator App on Android 5.x does not support it.

This is a piece of missing functionality in the Microsoft Authenticator App. There are no indications that indicate Microsoft is spending resources on fixing this issue in the Microsoft Authenticator App on this platform.

The workaround

To workaround this issue, accommodate non- Server Name Indication (non-SNI) capable devices on your Web Application Proxies by specifying a fallback TLS certificate, following these steps:

• Log on interactively on a Windows Server that acts as a Web Application Proxy with an account with local administrator privileges.
• Open a command prompt as an administrator, by either:
  • Typing in cmd and then right-clicking on the Command Prompt search result and selecting Run as administrator from the context menu, or
  • Pressing Windows + R simultaneously, typing cmd.exe and hitting Ctrl + Shift + Enter all at the same time.
• Enter the following command at the command prompt:

netsh http show sslcert

• This will output the certificate bindings in use. Copy the application globally unique identifier (GUID), including its brackets and the certificate thumbprint hash of the federation service.
• Now construct the following command at the command prompt:

netsh http add sslcert ipport=0.0.0.0:443 certhash=CertThumbPrint
appid={ApplicationGUID}

• Next, run the following command:

net stop appproxysvc && net start appproxysvc

• Close the command prompt window.
• Log off.

Concluding

This challenge with Microsoft’s Authenticator App will go away, because Android 5.x devices will, eventually, go away. Until that time, accommodate non-SNI capable devices on your Web Application Proxies by specifying a fallback TLS certificate.

Further reading

Azure Authenticator App on Android – your device does not trust the activation url 
Server Name Indication 
Server Name Indication (SNI) 
How to support non-SNI capable Clients with Web Application Proxy and AD FS 
Federation with ADFS 3.0 and SNI Support 
ADFS 3.0, WAP, SNI and Network Load Balancing