Gathering trace/event logs in ADFS is not a trivial task. The following article will show you how to gather these logs to further help investigate relying party trust issues or issues with end users authenticating to the service. This tutorial will be leveraging ADFS v3.0 on Server 2012 R2. The same steps should apply for v2.0 on Server 2008 R2. This process does change slighting in ADFS on Server 2016 as the logging engine was rewritten. Depending on demand, a second article will be released for ADFS on Server 2016.
Before beginning, as a side note, debugging in ADFS v2-3 is honestly a total PITA (pain in the... butt). The problem with ADFS logging is logs are stored on the machines serving the requests, not centrally. In this case, you will likely have to enable tracing on each ADFS server, or configure your load balancer/host file to temporarly route requests to a specific machine so you know which server to hunt down for the logs. Likewise, as you will find at the end of the tutorial, the logs gathered from ADFS are very verbose. Take some time to familiarize yourself with the logs of a working request vs a failure to get used to what logs are actually meaningful.
Enable list of events/audits to be logged
- Login to one of your ADFS servers that you believe will be authenticating the end users
- Open Server Manager
- In Server Manager, select Tools -> AD FS Management
- In AD FS Management, select AD FS in the top left and select Edit Federation Service Properties...
- Click on the Events tab and check all the items you wish to log and click OK
- Open Server Manager
- Select Tools -> Event Viewer
- In Event Viewer, select View in the top menu, and select Show Analytic and Debug Logs
- Expand Applications and Services Logs, expand AD FS Tracing, and select Debug
- Note: In ADFS v2, the AD FS Tracing folder will be called AD FS 2.0 Tracing
- When you are ready to begin collecting logs, right click on Debug and select Enable Log
- Click OK when prompted to write over the existing event logs
- Note: Each time you enable/disable AD FS Tracing, Event Viewer will purge your last results. I highly recommend you export your logs if you need them for comparison at a later time.
- At this point, recreate the issue, error, or login to the relying party you want to debug.
- Once you have recreated the error or logged in, go back to Event Viewer, right click on Debug and select Disable Log
- At this point, you should have some events captured to further analyse 🙂
- Optional Step: Right click on Debug and select Save All Events As... This will export to a evtx file, in which this can be sent to another team for analysis or you can reference the logs at a later time.
- Note: If you are sending the events over to another team for analysis, zip the logs as it will greatly decrease the file size 🙂
Common error when enabling Debug logging
One error I typically see is the following:
AD FS Debug - The requested operation cannot be performed over an enabled direct channel. The channel must first be disabled before performing the requested operation
This error is caused by a misconfiguration on the logging properties of the Debug log. Please verify that you have not manually enabled the debug log nor have the maximum log file size set to Overwrite events as needed.
To fix, right click on Debug and select Properties
Typically, the screenshot below is an example of the incorrect settings used; make sure that Enable Logging is unchecked and is Do not overwrite events ( Clear logs manually ) is checked
Here is a picture of the correct settings for the AD FS Tracing Debug Logs; at which point, once the settings are applied, you should no longer receive this error when conducting your debug/trace logging.
Many applications want to federate with leverage certain attributes like nameid (nameidentifier), but the problem is the format is wildly different from one application to another. In this case, one application might use a unique value like an employee ID, another UPN, another email address, and so on. Or maybe it isn't an attribute, but you are leveraging SHA1 as your signature hashing algorithm and the application is looking for MD5.
In this case, sometimes you may not be sure what you are sending to the application and are looking to the vendor to help you understand what you need to change in ADFS or if you are working on a custom application, need help debugging your claims rules to integrate into that application. In this case, I will show you how to leverage Fiddler to acquire the SAML Tokens issued by ADFS to validate what attributes/values you are passing to the federate application.
- Grab the latest copy of Fiddler from their website (it is a free download)
- Install Fiddler on your local machine
- Double click fiddlersetup.exe
- Agree to the End User License Agreement
- Set the installation directory and click Install
- Close the setup wizard
- Launch Fiddler
- Click Cancel if prompted about AppContainers
- With Fiddler open click on Tools -> Telerik Fiddler Options...
- Click on the HTTPS tab and check Decrypt HTTPS traffic and click OK
- Note: you may be prompted to trust a certificate. You must trust the certificate so Fiddler can intercept your encrypted traffic and decrypt it. Fiddler will not permanently capture traffic when the application is closed.
- Close out of Fiddler
- Open Fiddler
- Open up Internet Explorer in one window and Fiddler side-by-side. Drag the Crosshair icon onto Internet Explorer. This will target only traffic in this process (browser window) to help filter down intercepted traffic.
- Select the X icon with a dropdown and click Remove all to clear your trace
- Go to the url of the federated application and login. In this case, I am going to use https://outlook.com/owa/jackstromberg.com; once you have logged into the application or received the error to your application upon login, click File - Capture Traffic to stop the logs
- Within your logs, look for the last 200 response from your ADFS server before being redirected to your application (which will not show up as a 302, since we are posting to the new URL)
- Click on the Inspectors tab, and select the Raw tab at the bottom and copy the value from the hidden input tag with the name of wresult
- Paste the encoded HTML into my HTML Encoder/Decoder in the Encoded text box and click Decode.
- Copy the Decoded HTML and paste it into an XML formatter of your choice. Here I am using Bing:
- Copy the result into Notepad and you can now read the information
Going into the claim and how it works is outside the scope of this tutorial, but as you can see in the last screenshot above we have the raw SAML token we will send to the relying party trust to consume. At this point, the vendor can be involved to help troubleshoot any values or attributes that are in an incorrect format.