Tip #546: Avoid using the same domain for ADFS and CRM

I’m not sure how to condense 3 days of pain and desperation into a tip of the day but I shall try.

tl;dr

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.

Please explain

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.

Tweet about this on TwitterShare on Facebook0Share on Google+0

9 thoughts on “Tip #546: Avoid using the same domain for ADFS and CRM

  1. Josh says:

    Sounds like a similar issue I had integrating with Experlogix on a demo environment, this is a KB article from Microsoft https://support.microsoft.com/en-us/kb/3045286. Not sure if this explains things

    • Brilliant. I wish I found that 3 days ago but my weak google-fu failed me. On the positive note, I’m glad I didn’t find it because I would have reconfigured CRM URL instead of simply using a different domain for ADFS. I’ve been observing a slightly different behavior though as my duplicate cookie was coming across to ADFS as invalid but the core reason seems to be the same – duplicate cookie. ADFS is off the hook, CRM to blame 🙂

      • So you sign on to CRM with a lullaby? Single-Sing On….

      • Luis says:

        Hi,

        In my opinion this is a 20/80 blame between CRM / ADFS

        The main problem is that when adfs issues the cookie it stores it under the /adfs/ location (from memory, actual location could be different).

        So you end up with two cookies on the contoso.com domain:
        /MSAuth -> created by CRM
        /adfs/MSAuth -> created by adfs

        When ADFS tries to read the cookie it does not read the cookie from the location where it created it but rather it takes the first one that it finds in the domain. In my opinion, it it bothers to store a cookie in a predetermined location in should then use it to retrieve it.

        It took me a few days to realise what was going on and come up with the same solution of changing the adfs domain.

        Not sure why CRM has the cookie name hard coded rather than using the web.config as any other .NET web app. so simple web.config change would have fixed the problem!

  2. Dan Park says:

    Thanks, this problem has haunted us for many days. We use ADFS extensively, so we’re changing the domain name of our CRM application. We’ll use a new domain name (*.mynewdomain.com) for our CRM application versus going another level deep (*.crm.mydomain.com). Wonder why Microsoft did this?

  3. Eric R says:

    We ran into this issue for a recent client we are working with. I had the opportunity to talk to the Microsoft PM that is responsible for Hybrid integration between AzureAD and on-Prem infrastructure. ADFS is a big part of that story and so I mentioned this issue to him. He was not aware of it and was going to reach out to the CRM team about why they issue a cookie with the same name, scoped to the domain which affects ADFS. I agree with Luis in that this is an 80% blame on CRM and 20% on ADFS for all the same reasons he noted.
    In the end changing your ADFS domain or your CRM domain will do the trick.

    Note that moving your ADFS Domain to a sub domain of say adfs.sub1.example.com will not do the trick when CRM is still issuing cookies as .example.com as browsers send domain scoped cookies to ALL hosts or sub domains in that domain. You have to get them on different domains, or in theory, move CRM to a sub domain of crm.sub1.example.com so that its cookies are then scoped to .sub1.example.com. I like moving to different domains as noted in this tip.

  4. Chris M says:

    Does anyone know if this is resolved with ADFS 4.0?

    • Hey Chris,

      as per the comments earlier, this smells like CRM issue and not ADFS. Having said that, ADFS 4.0 (Windows Server 2016) may or may not help but whatever the situation is, some re-testing will be due once Dynamics 365 On-premises is released

      George

      • Chris M says:

        Any chance you’ve had reason to test this with Dynamics 365 on-premise or with ADFS 4? Are you still force to use a different subdomain for CRM and SharePoint with the same ADFS namespace?

Leave a Reply

Your email address will not be published. Required fields are marked *