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.
