In this post I will cover the expected traffic flow of a request to IAG that requires ADFS Authentication.  Understanding the flow of a normal request is key to understanding where to focus troubleshooting efforts when things don’t go according to plan.  Finally I will mention the different logging options that can assist with troubleshooting any problems you may encounter.

Traffic flow of a successful ADFS authentication

In my lab environment I have the following hostnames:

sp2portal.contosopb.com – the IAG Portal trunk

adfs-r.contosopb.com – the public hostname of my IAG FS trunk (and also the internal name of my ADFS Resource server)

adfs-a.adatum.com – The ADFS Account server.

Here is a filtered HTTP Watch trace that shows the key requests for a successful login using ADFS:

Your environment may generate a slightly different flow if you disable the IAG client components, or if you use ADFS Client Realm Discovery for example, but it will be largely identical to the above.  Let’s break down what is happening:

·         The client accesses the Portal URL

·         IAG performs EndPoint Detection then redirects back to the portal for login

o   Internally IAG redirect to /ADFS/Login.asp

·         The ADFS Web Agent intercepts this request and redirects to the local ADFS Resource server

o   This request passes through the IAG FS trunk

·         The ADFS-R redirects to the ADFS Account server in the remote Forest

·         The ADFS-A performs authentication of the client (using HTTP 401 in my example)

·         The ADFS-A sets a cookie (_WebSSOAuth) and directs the client to POST back to the ADFS-R including the SAML token.

o   This POST passes through the IAG FS trunk

·         The ADFS-R sets a cookie (also _WebSSOAuth) and directs the client to POST back to the web server (IAG)

·         The client sends this POST to the IAG Portal URL

o   Internally IAG redirects to ADFS/Login.asp

·         The ADFS Web Agent intercepts this request, processes the SAML token, then sets a cookie (_WebSSOAuth once more) and redirects the client back to the URL that was originally requested

·         The client is passed through IAG login and validation

o   /ADFS/Login.asp

o   /ADFS/auth/validatetrampoline.asp

o   /ADFS/Validate.asp

o   /RedirectToOrigURL.asp

·         The client accesses the portal

When troubleshooting, it is useful to start by gathering a client trace to see how far through this flow you are getting before failure.  There are numerous tools that are useful for gathering client side data in this way.  I tend to use either HTTP Watch or Fiddler.  If you want to see what is going on inside IAG then synchronise this client trace with a URLFilter trace from the IAG

Logging:

Depending on the problem you are seeing, you may want to gather logs from 1 or more of the elements of the architecture.  The following logs are typically useful for troubleshooting ADFS authentication issues

Client:

HTTP Watch (www.httpwatch.com) or Fiddler (www.fiddler2.com) traces

Personally I find HTTP Watch traces easier to analyse, but you cannot do detailed analysis with only the free version.  This allows data capture and basic analysis only.  If you want to be able to see exactly what is happening (request/response headers and body, cookies etc) then Fiddler is a better (free) option.  Fiddler also lets you see traffic that originates from sources other than the browser such as ActiveX controls and Java applets (useful for seeing what the IAG client components are doing).

IAG:

URL Filter

This log allows you to see how HTTP traffic flows between the client and the Real Web Server (RWS) via IAG and can be very useful for all web publishing scenarios with IAG.  In the ADFS authentication scenario it can be used to confirm that internal redirection to /ADFS/login.asp is happening correctly on the portal trunk, and is also useful if a request to the ADFS-R is failing, as you need to confirm if the failure happens on the ADFS-R itself, or if the IAG FS trunk blocked it.

The log is quite verbose, but don’t be put off – it’s a very useful troubleshooting tool.

To enable URLFilter logging:

·         Open Regedit and locate the following key

HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\UrlFilter

·         Change the logflag value from 0 to 4.  Logging will start within 60 seconds.

·         The logs will be located at e-Gap\von\conf\WebSites\<TrunkName>\Logs

·         Change the value back to 0 once you have gathered your logs.

ADFS Web Agent logs

If the failure appears to be occurring when the request gets to the ADFS Web Agent then you may need to enable detailed debug tracing as follows:

·         Open Regedit and locate the following key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS\WebServerAgent

·         Add a new DWORD Value ‘DebugPrintLevel’ and set it to FFFFFFFF (hex)

Event logs

The ADFS Web Agent will log events to the Windows Application Event log if it encounters a problem.

ADFS Servers (FS-A and FS-R):

ADFS logs

To enable logging on the ADFS servers:

·         Open the ADFS MMC

·         Right click on the Federation Service node and select Properties

·         Enable debug logging on the Troubleshooting tab as required.

Event logs

ADFS will log events to the Windows Application Event log if it encounters a problem.