Most articles you will find on the internet, which provide instructions about installing your AD FS server (farm) in Azure, will advise you to publish the external DNS record as CNAME. There is some advantages in doing so – since Azure is public cloud service, the VIP of the service (the virtual machine, or the farm) hosting your AD FS might change. Configuring the record as CNAME pointing to the FQDN of the Azure service will make sure that your users will always be redirected to the correct server.
But, and that’s a big BUT, using a CNAME record will also give you some trouble with SSO. Let’s start with the officially published article: KB 2461628. While it’s a bit general, it mentions this specific cause:
Domain Name System (DNS) resolution of the AD FS service endpoint was performed through CNAME record lookup instead of through an A record lookup.
And here’s the specific resolution:
Use DNS management tools to replace each DNS Alias (CNAME) record that’s used for the federation service with a DNS address (A) record. Also, check or consider corporate DNS settings when a split-brain DNS configuration is implemented.
Still not convinced? Let’s discuss a real example I recently assisted with on the Office 365 community forums. The admin was complaining that after moving a user mailbox to Office 365, he started experiencing Autodiscover issues. Internally everything was working as expected, and OWA and the O365 portal were accessible for the migrated users via SSO. The first advice was of course to make sure that he is hitting the correct Autodiscover endpoint, so comparing tests from on-prem and ExRCA was required. Both resulted in “HTTP 503 – Service Unavailable” response from Exchange Online servers.
I then advised the user to open the https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml endpoint directly in the browser and try to authenticate there. A normal response in such case would be error 600, Invalid request. This was not the case. Since the user did post a screenshot with the domain name visible, I took the opportunity to do some tests myself. You do not need to have a valid username and password to test some steps of the authentication flow, and in this case this was just enough. I opened the O365 portal and entered random username for that domain, in order to get the redirect to the AD FS server. And there it was, the login prompt that caught my attention – the browser address was adfs.domain.com, however the prompt was listing xxxx.cloudapp.net as the source. Azure! Quick check in the DNS console confirmed that the external record was indeed published as CNAME. After changing it to A record on the next day, the admin was able to resolve the issue.
You can find the forum thread here: http://community.office365.com/en-us/f/156/p/261854/800191.aspx#800191. Here’s also a nice guide on installing AD FS 3.0, which at least bothers to warn you of the issues CNAME will cause: http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx.
Hope this post will help you avoid doing such mistakes!