A quick post, which if it gets enough Search Engine love will save someone else time…
In response to a customer issue in which an iPad on the corporate network could not log on an ADFS 3.0 (Windows Server 2012 R2) secured resource, I saw the above error in my Event Viewer on the federation servers. The federation farm was setup in a typical architecture:
http://i.technet.microsoft.com/dynimg/IC698143.jpg
In this architecture, combined with a split DNS entry for the ADFS endpoints, external clients will resolve to the proxy servers and internal clients (on the corporate network) the federation servers.
The default authentication policy for ADFS 3.0 is Forms Authentication for the Extranet and Windows Authentication (IWA) for the Intranet. You can see these settings in AD FS Manager under Authentication Policies:
In PowerShell:
If you recall, the scenario that was failing was iPad on the intranet. Since the iPad is not domain-joined, Windows Authentication will fail. AD FS does provide for "falling back" to a different authentication method – you can see the property WindowsIntegratedFallbackEnabled is set to True. However, in the Intranet, there is no other provider configured, so there is no other provider to fall back on. (For more information about which browsers/clients will use Windows Authentication, refer to Configuring intranet forms-based authentication for devices that do not support WIA.)
To resolve my issue, I enabled Forms Authentication on the Intranet. Even though the authentication provider name is "FormsAUthentication" – this is not the FBA approach that you may remember from .Net/SharePoint. In IIS terms, this is Basic Authentication with TLS/SSL.
Now that there is another authentication method available, AD FS logic for using IWA will apply. And since the User Agent for the iPad is not configured for IWA, the server renders a login form.
HTH!