AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In

AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In

This article's purpose is to demonstrate how to utilize Fiddler Web Debugger to analyze traffic in a WS-Federation sign-in conversation, specifically for AD FS 2.0. If you are looking for Fiddler debugging information for another protocol such as WS-Trust or
SAML 2.0, please see the More Information section of this article for possible links.

Fiddler will automatically start capturing. We're not quite ready for that yet, so click
File -> Capture Traffic to stop the capture.

Configure Fiddler to decrypt HTTPS traffic

Within Fiddler, click Tools -> Fiddler Options

Select the HTTPS tab

Check the checkbox to Decrypt HTTPS traffic

You will receive a few pop-ups that are required in order to install the Fiddler root certificate, which allows Fiddler to sit as a man-in-the-middle to your HTTPS session. Click
Yes to these prompts.

Click OK to close Fiddler Options

Understanding the view of the Fiddler tool

The left side of the vertical divider will show a sequential flow of the HTTP conversation.

The right side of the vertical divider is where the data is viewed.

I recommend splitting the left and right panes into a 50%/50% view so that you can work through both panes.

The right pane is split by a horizontal divider, which separates the request from the response. Unlike a network trace where you typically get a frame for a request and another frame for a reponse, Fiddler provides one frame that contains both the request
and the reponse.

We will be interested in the Inspectors tab data, so go ahead and select
Inspectors at the top of the right pane.

You'll notice that we have sub-tabs under the Inspectors main tab, such as
Headers, TextView, WebView, Auth, Raw, etc. We will be toggling through these sub-tabs as we work through our trace.

Configure AD FS 2.0 to allow Fiddler to act as a man-in-the-middle to the HTTPS session

Click the Launch IE button in the ribbon bar near the top (this will take you to the about:blank page, which helps to keep the trace clean)

Browse to the relying party (RP) application and authenticate to the Federation Service

When you have finished signing in or reproducing your failure, in Fiddler, click
File -> Capture Traffic to stop the trace

Analyze the captured WS-Federation sign-in data

We browsed, first, to your RP application, so let's find that frame in the trace. In the example, my
HTTP GET to the RP was in frame 2

The URL is http://contosoweb1.contoso.com:8085/

The action is a HTTP GET

The response is a HTTP 302 (Redirect), and the Response -> Headers sub-tab Transport data shows us where we are being redirected to. In this case, we are redirected to the AD FS server whose URL is https://sso.contoso.com/adfs/ls/

Notice we have query string parameters on the URL to the AD FS server:
wa, wtrealm, etc. wa=wsignin1.0 shows us that our RP application has built a WS-Federation sign-in request for us, and sent this to the AD FS server's
/adfs/ls/ endpoint. This is known as using the Redirect binding.

The next frame of interest is where we first contact the AD FS server in frame 5

This is a HTTP GET to the AD FS server's /adfs/ls/ endpoint accompanied by a WS-Federation sign-in request (wa=wsignin1.0)

Notice that the client is presenting a browser cookie named MSISIPSelectionPersistent. This cookie is the persistent cookie which is written to the file system on the client that shows who should be the identity provider (IDP) for this
client. If the client does not already have this cookie set, and there are multiple IDPs to choose from, AD FS will prompt the user to select an IDP through a process called Home Realm Discovery (HRD).

The MSISIPSelectionPersistent cookie data is base64 encoded, so you can use your favorite base64 decoder to see the value of the identity provider. Fiddler has a base64 decoder built into its Decoders menu.

This is what my MSISIPSelectionPersistent cookie data looks like: http://sso.contoso.com/adfs/services/trust
(this is my Federation Service Identifier. This is a URI, not a URL!)

This HTTP GET results in another HTTP 302 to the /adfs/ls/auth/integrated/ endpoint of AD FS 2.0. This shows me that the authentication type set for this Federation Server is Windows authentication. You can figure out which authentication
type you are using by reading through this article:
AD FS 2.0: How to Change the Local Authentication Type

Frame 6 shows a HTTP GET to the /adfs/ls/auth/integrated/ endpoint of AD FS 2.0

Selecting the Auth sub-tabs, you can see that the client is performing a GET to this endpoint, and the server is responding with a credential challenge in a HTTP 401. You can see on the
Response -> Auth sub-tab that the server is offering an authentication header
Negotiate and NTLM.

Frame 7 shows that we are, again, performing a GET to the /adfs/ls/auth/integrated/ endpoint

This results in a HTTP 200 (OK) which means that AD FS (IIS, really) has authenticated the user based on the credentials provided

The Response -> Headers sub-tab is especially interesting here because we see AD FS 2.0 is setting 5 cookies back to the client.

These cookies are used to fascilitate the single-sign-on process (SSO), and they are session cookies which means they are lost once the browser session has ended or the cookies are cleared in some other way such as invoking WS-Federation sign-out.

MSISAuth and MSISAuth1 are the encrypted cookies used to validate the SAML assertion produced for the client. These are what we call the "authentication cookies", and you will see these cookies ONLY when AD FS 2.0 is the
IDP. Without these, the client will not experience SSO when AD FS 2.0 is the IDP.

MSISAuthenticated contains a base64-encoded timestamp value for when the client was authenticated. You will see this cookie set whether AD FS 2.0 is the IDP or not.

MSISSignout is used to keep track of the IDP and all RPs visited for the SSO session. This cookie is utilized when a WS-Federation sign-out is invoked. You can see the contents of this cookie using a base64 decoder.

MSISLoopDetectionCookie is used by the AD FS 2.0 infinite loop detection mechanism to stop clients who have ended up in an infinite redirection loop to the Federation Server. For example, if an RP is having an issue where it cannot consume
the SAML assertion from AD FS, the RP may continuously redirect the client to the AD FS 2.0 server. When the redirect loop hits a certain threshold, AD FS 2.0 uses this cookie to detect that threshold being met, and will throw an exception which lands the
user on the AD FS 2.0 error page rather than leaving them in the loop. The cookie data is a timestamp that is base64 encoded.

Frame 11 is where we are POSTing the SAML assertion back to the RP

AD FS 2.0 scripts a HTTP POST to cause the client to POST the SAML assertion to the RP. AD FS 2.0 will POST to the WS-Federation endpoint defined in the RP Trust. In this case, AD FS 2.0 is POSTing to https://contosoweb1.contoso.com:8085/

The Request -> TextView will show you the WS-Federation response which is a
RequestSecurityTokenResponse (RSTR). The SAML assertion is in this
TextView area as well, and may be encrypted if token encryption is configured for the RP Trust. For troubleshooting, you may wish to disable token encryption for the RP so you can see the SAML assertion in transit.

The TextView data is URL-encoded, so passing this through a URL-decoder will make it easier to look through. Fiddler has a built-in URL-decoder under
Encoder.

The Response -> Headers sub-tab shows that the RP is setting two cookies to the client:
FedAuth and FedAuth1. These are authentication cookies used to fascilitate SSO for a
Windows Identity Foundation (WIF) RP. Your trace will likely look different at this point if your RP is not a WIF RP. We should expect to see some browser cookie(s) set by the RP so that SSO is achieved.

The Response from the RP is a 302 redirect to the default.aspx page of the RP.

Finally, in frame 12, the client performs a HTTP GET to the default.aspx page of the RP

The Request -> Headers sub-tab shows the the client is presenting the
FedAuth and FedAuth1 cookies to the RP so that the client can experience SSO to the
default.aspx page.

The response to the GET is a HTTP 200 (OK) which shows us that the FedAuth cookies were successful in allowing the client to access default.aspx

The Response -> WebView tab can be used to view what the client saw in the browser upon the HTTP 200 (OK) to default.aspx.