Recently had very interesting issue to troubleshoot. This (long 😊 ) troubleshooting description for sure will help many to understand the ADFS Single Sign-On (SSO) flow and how to read the Fiddler traces.
Environment: ADFS 3.0, CRM 2013, IIS 8.5 running a site. Both the CRM and the IIS site are federated with the ADFS.
The CRM and the IIS site were accessed from outside of the corporate network, so only Form Based Authentication was taking place when redirected to the ADFS.
Problem: If the user accesses the IIS site first, completes authentication to the ADFS, then the user browses to the CRM site (using the same browser), the ADFS SSO takes place and user do not have to authenticate second time (put user name and password) via ADFS to access the CRM.
But if the user accesses the CRM first, completes authentication to the ADFS and then browses to the IIS site, the ADFS SSO doesn’t take place and the user is presented with the ADFS Form Based Authentication (FBA) page.
Another variable added to the puzzle was the fact that the CRM and the IIS belong to one Active Directory domain (lets call it EXTERNAL) and the ADFS belongs to other (call it PUBLIC). The two-way trust was configured between these domains. As troubleshooting continued, the issue was replicated if all three services (ADFS, CRM, IIS) were placed in the same AD, so the issue was NOT about on-premises AD location and which domain the services belonged to (more details explained below).
Troubleshooting: As always in such cases, the Fiddler trace was captured to get better understanding of browser redirections and sign in processes.
Here is a non-working SSO attempt (Note: in some screenshots I’m not able to show all the details (but will do my best to provide good description).
Frame #2 – user accesses the CRM and is redirected to the ADFS;
Frame #3-8 – user completes the ADFS FBA (providing correct username/password) and browser gets the ADFS SSO cookie – MSISAuth=AAEAAJo…;
Frame #9 – the ADFS redirects the browser with the ADFS SSO cookie to itself, where the ADFS SSO cookie is exchanged to the ADFS access token (MSISAuthenticated) that will be presented to the application as a proof that the user was authenticated;
Frame #10 – browser is redirected to the CRM Ws-Fed endpoint configured in the ADFS CRM Relying Party, where MSISAuthenticated cookie is exchanged to two application session cookies (MSISAuth=77uj… and MSISAuth=VWJ0…). These two cookies will always be presented to the CRM by browser as a proof that this is “authenticated” session;
Frame #13 – user opens a new tab in the browser and goes to the IIS site. The browser presents two CRM session cookies to the IIS site and obviously, the IIS site doesn’t recognize them and redirects the browser to the ADFS for authentication;
Frame #14 (were all fun begins) – The browser presents 3 cookies to the ADFS – the ADFS SSO cookie we got in Frame #8 + 2 CRM application cookies;
Looks like regardless correct ADFS SSO cookie presented (MSISAuth=AAEAAJo…), it was not accepted by the ADFS and the Form Based Authentication sign in page is returned. No errors in the ADFS Admin logs.
In the ADFS Debug logs see the following error:
Log Name: AD FS Tracing/Debug
Source: AD FS Tracing
Date: 2/6/2018 1:52:20 PM
Event ID: 67
Task Category: None
Level: Error
Keywords: ADFSProtocol
User: S-1-5-21-1337953637-3591879799-2366245552-4020
Computer: XXX
Description:
Ignore corrupted SSO cookie.
Have confirmed that this is expected ADFS 3.0 behavior to parse all cookies through its code pipe. Since the browser was presenting 2 cookies with the same name (MSISAuth – one set by the ADFS, other by the CRM) only the last one in the pipe was treated as the ADFS SSO cookie. But as we see from previous screenshot, the last cookie in the pipe was MSISAuth=77uj… and was set by CRM and for sure is not a valid ADFS SSO cookie.
When looking at the trace when we access the IIS site first and the CRM second, the issue with non-working SSO is NOT present, because the IIS site was setting cookies with the name of FedAuth and that cookie name is not causing the issue during the ADFS cookies evaluation.
Explained the above flow to the owner of the environment and said that the solution is to see if we can make sure the CRM is not using MSISAuth name for its session cookie.
After that, the owner of the environment added another variable to this puzzle ☹. He said he has other CRM and IIS site federated with the same ADFS 3.0 farm, but there the issue we are troubleshooting is NOT present there!
Captured new Fiddler trace for working scenario.
Following screenshot is for working sign in.
The authentication flow is the same – user accesses CRM (#2), browser redirected to the ADFS, successfully authenticates (#3-8), the CRM WS-Fed endpoint sets the session cookies with name MSISAuth (#9-10), user opens new tab to the IIS site (#12), site redirects to the ADFS (#13).
But looking at the Frame #13 we see that the browser is sending ADFS only one MSISAuth cookie (the ADFS SSO cookie) which ADFS accepts and issues MSISAuthenticated cookie to the IIS site (SSO takes place to IIS).
So now the question was – why in one scenario the browser presents 3 cookies (ADFS SSO + 2 app session cookies), in other only one ADFS SSO cookie.
You might have already noticed the difference in the scenarios. As mentioned at the beginning, it was NOT about the local AD and what Active Directory domains each of three services belong to.
The explanation was discovered in the Frame #10 where the CRM was setting the application cookies. Going to the Raw tab in the response window and viewing the frame in Notepad, gave the explanation.
The domain scope was set for the cookie by the CRM.
Since in non-working scenario, all three services (ADFS, CRM, IIS) are located in the same domain name space (domainA.com), the browser was presenting the CRM cookies as well to the ADFS when redirected from the IIS site.
In the second scenario the CRM was specifying domainB.com in the session cookies and because ADFS belong to domainA.com, the browser was not presenting the CRM cookies with the ADFS SSO cookie when it was redirected from the IIS to the ADFS for authentication.
To resolve the issue, it was decided to move production ADFS host name to different domain name space than CRM and IIS by the owner of the described environment.
So far was not able to confirm with the CRM team if its possible to change the name of the session cookies or make sure the domain name is not specified (though think the last is not a valid option at all).
Sergii's Blog 
Hi, We are facing the same problem now. Have you found any other solution? Moving adfs to another domain is not an option for us. Thank you.
LikeLike
No other solution was discovered from AD FS side. You might need to work with CRM team.
LikeLike