Recently had an issue where a user could not log into his Office 365 account. The organization was using Azure AD Sync and SAML based login. The user could successfully authenticate to the ADFS login, but once they tried to access the Office 365 resources they would receive an error. Below is a screen shot of the error when they tried to login to OWA.

 

Troubleshooting SAML can be a bit complicated, so I’ll go through some of the steps that I used to determine what the SAML server was providing to Office 365, and where the breakdown was in this specific case.

First, I downloaded and installed Fiddler on a test machine – https://www.telerik.com/download/fiddler-wizard.

After the install, I needed to configure Fiddler to decrypt my HTTPS traffic.

Go to Tools -> Options->HTTPS

Ensure that Decrypt HTTPS traffic and Ignore server certificate errors are selected

You will get some warnings about trusting the local certificate. You want to click accept and yes to this warnings. What happens is Fiddler acts as a Man in the Middle proxy so that it can decrypt your traffic. You allowing it to install a certificate to the machines local store so that it trusts this certificate. You can view it in Local Computer -> Trusted Root Certificate Authorities

 

Next, open your web browser (I use Edge for this since it utilizes the local machine’s certificate store) and open it to a blank page. In Fiddler, clear the tracing results that are already present:

 

Now, browse to the OWA site for your organization in Office 365. Its in the format https://outlook.office.com/domainname.com. So for my test I’m using https://outlook.office.com/abacusflex.net. This should land you on the login page for your SAML provider. Log in as normal:

Next, get to a place where your login breaks, or you get the error, in our case, it is the original error message:

 

In Fiddler, go to File -> Capture Traffic to stop the capture.

Now, in the results section, find the last entry that has your SAML host name, and the URL beginning with /adfs/ls. In our example below we are looking at line 41.

We want line 41 because this is the last entry from our SAML provider before we are pushed back to login.microsoftonline.com so this has our SAML session ticket in the response.

Select that entry, and on the right hand side, select Inspectors along the top row, and Raw along the bottom row:

Now copy out the line underneath Content Length to a text editor

You will have a big blog of text. In the first few lines, find the entry name=”wresult” value=

You want to copy everything AFTER the equals sign in value:

Until the string ends with RequestSecurityTokenResponse>”

In our example, that leaves us with the following string (adjusted for formatting reasons):

“<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"><t:Lifetime><wsu:Created …/t:RequestSecurityTokenResponse>”

So the string you have, isn’t that nice or easy to ready, so lets run it through some HTML decoders.

I used the one on opinionatedgeek.com – https://opinionatedgeek.com/Codecs/HtmlDecoder

Copy the decoded result to a text editor. Now we want to format that for XML. I used the one from WebToolKitOnline – http://www.webtoolkitonline.com/xml-formatter.html

Okay, now we have readable XML data that we can paste into our favorite XML viewer.

So for us, we can now see the SAML response that we are sending to Office 365. In our case we are interested in the UPN attribute and the Immutable ID values:

We suspected that the Immutable ID we were getting from ADFS was not matching with the Immutable ID we have stored in Office 365. We can see here that the values we are getting from ADFS are:

UPN – pponzeka@abacusflex.net

ImmutableID – xPPblRWKMkqRDhd6jO4O4Q==

So if we check in Microsoft Online we can get the UPN and ImmutableID through powershell:

Get-Msoluser -UserPrincipalName pponzeka@abacusflex.net | select userprincipalname,immutableid

This gives us the following output:

We can see that the ImmutableID value’s do not match between ADFS and Office 365. In this case, the client was syncing a custom attribute that was not converting the value correctly. They fixed their back end process and then the user was able to log in.

I hope this article helps some of you with using Fiddler to troubleshoot SAML login issues with ADFS.