Cracking the AD FS Token from another AD FS Claims Provider

  • Article

Hello everyone!  Its about time I dust off the blog and get back to the business of writing some things down that may be useful to you and my customers. But before I start up a new Tangent thought totally unrelated to any of my previous posts, I want to do a shameless plug.  As a consultant in Microsoft Services, doing a lot of work lately with Web Application Proxy, I am now part of that TechNet Blog group also.  So stay tuned as a few of us will be making contributions in the upcoming months.  My first post "Paths to Success in Web Application Proxy" is currently under review and should go live in the summer of 2014.  Check out Application Proxy Blog and sees what's going on to publish your applications while protecting your network!  Now, back to this tangent thought.

Frist, some reference materials to cite before I begin.  The infamous Adam Conkle did a beautiful and detailed breakdown (as always) of How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In. If you have never used Fiddler before, then get it, walk through his Wiki and learn away!  But I come and go on federation projects.  Then every once in awhile, I bump back into the old scenario below.  So I do not need to learn how to setup and use Fiddler, as I use that quite often to trace the web traffic.  But then the moment arises when ... bum bum bahhhhh ...I need to crack open that token.  While I have cheat sheets all over my OneNote's, they are not as neat and tidy as I wish, so I wanted to come up with a faster method than I have done before. Also, since I am "Allergic to Code ©"" and don't have cool tools like Visual Studio that I am friendly or acquainted with, I use a very simple and lightweight XML reader to make a nice xml token format to share with the customer, XML Notepad.  

To begin, I'll start with this Scenario: You want to capture and decode a Token Sent from one AD FS Server to yours. Therefore, this example is not a SAML Identity Provider like Oracle, but a WS-Federation claims provider,as in our case another AD FS server.  As a real world example, my customer has multiple claims providers in their AD FS 2012 R2 instance.  In this case, my customer's AD FS server is the man in the middle, so to say.  This is because my customer's AD FS also passes tokens inbound to their Relying Party Trusts, which is a Policy Agent that then connects to applications internally that are not yet federated by translating the claims sent from AD FS into Application headers. For my customer, at the Policy Agent side, they can easily see the content of the token.  But often, we need to validate the token that is sent from one of my customer's external customers i.e. from those Claims Provider (CP) Trusts, so that we can map them properly for the internal application to consume.  This is what I often refer to as the "finessing" of federation.  The external party tells you they will send one thing.  You application on the inside requires something else as connected via your RP Trust.  Now, you as the AD FS administrator need to properly map the incoming claims to the inbound claims. By looking at the incoming token from the external CP, you can validate that 1. The external entity (CP) actually sent you what they said you would send you (yes, sometimes they don't)  and 2. That you are actually passing through or transforming the claims coming in from the CP through to the RP trust so the internal applications will be happy! 

DISCLAIMER:   this may not be the best, fastest or cheapest method, but it just works reliably for me.  If you have a better method, let's share it with the world. Just reply at the bottom of this post.  This method, for this Scenario, using Fiddler, just works for me all the time.  So I'm sticking with it.  Why Fiddler?  Well for starters, previously one of MCS's own, originally created it.  And it typically is the de facto tool of MCS consultants and also Microsoft support.  So therefore, if I can get my customers to use it, then if and when they have to have a support call with Microsoft, one of the first things support will ask is to have them send a fiddler trace file.  I now do this with my customers to help analyze the web traffic and also the token.  So on with the Token!

SUMMARY OF STEPS TO CRACK THE INCOMING AD FS TOKEN!

  1. Open Internet Explorer in "InPrivate" Browsing mode (Ctrl + Shift + P,  once open) or Chrome in "incognito" mode (Ctrl + Shift + N, once Chrome is open). Firefox uses Private Browsing and Safari uses Private Browsing, a similar feature. 
  2. Open Fiddler. Make sure you had enabled it to decrypt traffic! Once opened, it is running by default.
  3. Type your URL, press ENTER, and you hit your destination application, or not i.e. it fails, press F12 to stop the fiddler trace.
  4. While still in Fiddler, use the Search feature by clicking Ctrl + F, and type RequestSecurityTokenResponse and then click the "Find Sessions" button. You should see several lines highlighted in yellow.
  5. Look for the 200 Result coming from the AD FS server's URL that is the Claims Provider (CP Trust) where you are trying to capture the token that they are sending you.  It should be followed by a 302 redirect heading towards your AD FS Server HOST name.
  6. Once you select that 200 response coming from the CP, click TextView, in the lower right hand window of fiddler.  The text will start with  <?xml version="1.0" encoding="utf-8" ?>
  7. Clicking in that same window, select all text by typing Ctrl + A. Right Click on the highlighted text and select Send to TextWizard
  8. In the TextWizard window, click the Send output to input button in the middle right of that window
  9. At the top of that window, delete the first few lines until it starts exactly with &lt;wst:RequestSecurityTokenResponse
  10. In that same window, delete the last couple of lines so that it ends exactly with wst:RequestSecurityTokenResponse>
  11. On the radio buttons on the left of the TextWizard click HTML Decode
  12. Clicking in the lower window in the TextWizard, select all the text, copy it, open XML Notepad (or your favorite tool) and paste it.  In XML Notepad, right click on the left side of that window and select paste from the pop-up menu. If it fails, check steps 9 and 10 above to make sure the correct parts are included and not included.
  13. If you expand everything in your XML on the left, you will see all the saml:Attributes.  This will prove to you what is or is not being sent to your AD FS server!

When you get a good XML token, save it so you have a reference point if needed to make your AD FS claim rules on the Relying Party trust, so that you can properly send the attributes into your applications. With some more free time I'll add pictures.  With even more free time I'll add a video.  Who has free time?  Hmmm....

So now when the customer says, may I see the token please, and you want to have it ready in a jiffy, you don't want to be, ahem, fiddling around! Pun intended.

Till the next time, gotta crossover and write another Blog on the Application Proxy Blog for this summer. This will correspond, a little, to my internal MS presentation on PS your way through AD FS and Web Application Proxy. If I can package that presentation all up nicely and I may try to get it into TechEd so it can be shared with you all!