Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I’m not sure how to condense 3 days of pain and desperation into a tip of the day but I shall try.
Do not use the same base domain for ADFS and CRM if you have other applications (e.g. a web site) requiring Single Sing-On (SSO) with CRM.
If you ever set up Internet Facing Deployment for CRM On-premises, you know that it is generally a small PITA. Some even make a living out of solving mysteries of IFD configurations. All you need is a CRM server, say crm.contoso.com, and an ADFS server, say adfs.contoso.com, both accessible from the outside (whatever outside means to you, it does not need necessarily to be public). Then a bit of magic grease and it’s all up and running.
The problems begin when you try to create a website that uses the same ADFS for user authentication. Thanks to Owin and Katana, it’s now a point-and-click exercise. Why would you want an SSO between CRM and the website? Well, how about hosting an ASP.NET page in IFRAME inside CRM form and passing the information between the form/CRM and the site? All without asking people to authenticate twice. (While we’re on the subject – the SDK sample is awfully out of date, don’t try this at home, I’ll get to it in a separate tip.)
In the configuration above, all works fine in ADFS 2.0 but fails in ADFS 3.0 (Windows Server 2012 R2). Both web site and CRM can authenticate independently, if you authenticate to the web site first, CRM will honor that authentication and won’t prompt, however, going from authenticated CRM session to the web site (the scenario that we actually need) fails miserably in an endless “please login” loop.
In the end I managed to trace it down to the web site sending existing cookies (that CRM authentication process has created) to ADFS but ADFS logs an obscure and exceptionally brief error “Ignore corrupted SSO cookie” and promptly redirects the web site to login. I even checked the cookies by hand. Yep, the very first one MSISAuth cookie (the one holding authentication information) is not a valid base64 string. Huh?
Digging deeper; there are two MSISAuth cookies, one for .contoso.com domain and another for adfs.contoso.com, latter being the invalid one. Huh?!
Long string of coffee cups, trials and errors followed by almost accidental discovery:
Using different domain name for ADFS server allows flawless SSO in both directions between your CRM and the web site
In the scenario above replacing adfs.contoso.com with adfs.osotnoc.com, for example, would do the trick. Of course you’ll need a domain and an SSL certificate but those can be had for less than all those cups of coffee put together. Changing name of your ADFS service is a bit tricky but can also be done.
To be honest, I still have no idea why it was happening but in the absence of any other information I squarely blame it on ADFS 3.0. People who actually know a thing or two about claims, authentication, tickets, cookies and goblins are more than welcome to drop a note or two shedding some light on the behavior.
Business Applications communities