The Problem :

An intranet application requires support for authentication using a Windows Identity and this identity needs to be used to control access to reports . In a  scenario where the Web Server hosting the application resides on a different machine to the Report Server the authentication process is required to do a ‘Double Hop’ (Web Client -> Web Server -> Report Server) in order to access the remote resources (the reports) on the Report Server.

The ‘Double Hop’ issue to access these remote resources means that delegation is required.

Standard impersonate-level impersonation tokens that are usually created when you enable impersonation allow you to access local resources only. To be able to access remote network resources, you require a delegate-level token. To generate a delegate-level token when you impersonate, you need to use Kerberos authentication and your process account needs to be marked as trusted for delegation in Active Directory.

(Taken from http://msdn.microsoft.com/en-us/library/ms998358.aspx#paght000025_configuringwindowsauthentication)

The Investigation :

Having set up the necessary servers to simulate the client environment I researched numerous other solutions to the problem as this is  a common issue encountered by other web developers using the ReportViewer control from the web site to access a remote report server. All the research pointed to the issue of delegation and ensuring that the machines are trusted for delegation.

If you access this Web site from a browser while logged onto a different machine in the same domain and the Web site attempts to access network resources, you end up with a null session on the remote server and the resource access will fail. To access remote resources, you need delegation.

(Taken from the same article listed above)

Since delegate-level tokens when impersonating requires Kerberos authentication I came to the conclusion that the missing link in our server configuration was the ‘Trust for delegation’ setting. Having got the IT department to make the relevant changes to the servers in the AD and rebooted the machines our web application was able to display reports from within the application.

The Solution :

The solution comes in two parts;

–     Internet Explorer security settings must be configured to enable Integrated Windows authentication. By default, Integrated Windows authentication is not enabled in Internet Explorer 6 (or above). To enable the browser to respond to a negotiate challenge and perform Kerberos authentication, select the Enable Integrated Windows Authentication check box in the Security section of the Advanced tab of the Internet Options menu, and then restart the browser. It is also advisable to make sure the server running the web application is added to the list of Intranet Sites in the security settings for the browser and that ‘Automatic Logon only in Intranet Zone’ is also set.

–     If this server running IIS is a member of the domain but is not a domain controller, the computer must be trusted for delegation for Kerberos to work correctly. This information is taken from the following article – http://support.microsoft.com/kb/907272 .

Supporting Documents:

For information on what changes are required to the AD please see the following article – http://technet.microsoft.com/en-us/library/cc738491(WS.10).aspx