I had this all too common problem hit me this weekend, but this was happening on my ADFS server, which I unfortunately was rebuilding. The most common reasons as you know have to do with some misconfigured Kerberos setting, or with using some name other than the server name for a web application (the 'ol disable loopback scenario). This one is different though, and is specific to an ADFS server so I thought I'd capture it for future reference.
AD FS 2.0 is actually pretty good about writing problems to the event log. When you open the Event Viewer you will see a separate node for AD FS 2.0 so look in there. In this particular case I did end up finding the culprit in there, it just took a fairly long time because it seems like there's so many different things that can give you the dreaded three login prompts anymore. Long story short, when I configured my ADFS server, I a) configured it to run as a domain account and b) I used a certificate I created just for ADFS for token signing. The problem as it turns out is that the service account I used for ADFS did not have rights to the private key for my token signing certificate. That, of all things, caused the 3 login prompts, which in interesting, amazing and frustrating all at the same time. To grant rights to the service account to the private key for the cert, you need to run the MMC, add the Certificates snap-in for the Local Computer, open up the Personal node, right-click on the token signing certificate and choose the Manage Private Key menu. From there you can get to a Security tab where you can add your ADFS service account with at least read rights to the private key.
Hope this saves someone some time down the road.
Today I experienced the 3 login prompts problem but checking the certificates, I didn't see signing cert in the place suggested above.
In my case it turned out that when I was attempting to sign-in, I was being correctly redirected to the ADFS machine (fs.contoso.com) which was running on the default website yet in the hosts file on the machine I was connecting from I has this:
192.168.1.200 realhostname fs.contoso.com
I think this must have been breaking Kerberos as suggested in the top of the original posting. My fix was to remove the "realhostname" entry.