This post is to document a known behaviour of ADFS 3.0 if your name resolution (DNS) is not configured correctly. If you attempt to sign in to Office 365 from a domain-joined Windows 8.1 computer (with all the SSO pre-reqs) you are faced with the following screen. The user is able to login correctly with their password, but this is not the desired experience.
It all pointed to name resolution and as this way my lab it did not surprise me (as it is a mess), so I first tested reverse lookups and as you can see it failed.
The reverse lookup failed because there was not a PTR record created for my Domain Controller under my Reverse Lookup Zones, so I created it. The nslookup test then worked correctly.
As my Office 365 tenancy was using my lab domain edin-networks.com all of my DirSync'd users had their UPN suffixes set to @edin-networks.com. I had however forgotten to create the Forward Lookup Zone for this domain name. I created this under DNS and ensured it was integrated with Active Directory.
The next step was to create an (A) record that pointed to the ADFS service name (in this example sso.edin-networks.com) this should be set to point to your internal ADFS server. This is of course not valid for internet name resolution as you would resolve to the external IP of the WAP server.
Now attempt to ping the internal ADFS service, depending on your DNS configuration you may have to flush the cache first or you run the risk of this resolving to the external sso.domain.com
Attempt to login again and it works first time.