ADFS site configured for Integrated Auth continually prompts for password when DNS hostname is a CNAME
I have bad habits by some accounts. I like CNAMEs. In my mind, they allow for easy changes to the DNS namespace without having to remember IPs, and in that way create simplicity. But they are invariably frowned upon for various reasons, they create additional DNS traffic, aren’t compatible with other record types on the same namespace (MX for instance).
I’ve run into a case where use of a CNAME breaks expected functionality. In an environment using Active Directory Federation Services, if the hostname of the federation service resolves to a CNAME, Windows Integrated Authentication will not work. As an example:
CNAME federation.example.com -> adfs.example.com A adfs.example.com -> 192.168.1.10
The federation service hostname as configured in ADFS is federation.example.com and the actual servername of the federation server is adfs.example.com. You attempt to access a URL of the federation service under the federation.example.com namespace, and instead of being authenticated transparently you are prompted for a username and password as below.
Repeated attempts to enter the password fail, eventually resulting in a 401 page. Replacing the DNS CNAME with an A that points to the same IP resolves this issue. Config as below:
A federation.example.com -> 192.168.1.10 A adfs.example.com -> 192.168.1.10
This is documented, though not as a bug, and I would not expect it to be fixed.
KB2461628 – Note resolution #4