Crystal Reports 2008, ASP.Net and impersonation

We have created our perfect reporting solution using Crystal Reports 2008 viewer control, tested everything, and  deployed it into production environment… and it is working… until Friday night… 🙁

Information below is provided for both IIS 6 and IIS 7 along with 32 and 64 bit Windows environment. Make sure that proper reference is used.

For some strange reasons, things usually happen when nobody anticipate it anymore (usually about a week after an initial deployment).
In addition, Project creep situation may occurs: after usual management meeting, requirements are changed and some security measures are to be introduced.

Easy! <IMPERSONATE> option of ASP.Net… and this is where it become interesting.

There is slight small issue, locally developer is usually an administrator of the machine, where in production, s/he just regular user.

More testing… everything would be fine in development infrastructure and not cause any problems. But being released some strange errors may occur.

Examples:

• “Load Report Failed”
• “System.Runtime.InteropServices.COMException: Invalid file name”
• “Exception Details: System.Runtime.InteropServices.COMException: Access is denied.”

Hint: When reviewing ASP.Net Stack Trace (debug/trace mode needs to be enabled), first line may contain the following text “CrystalDecisions … ReportClientDocumentClass.Open”.

What is going on here?

ASP.Net impersonation

In default situation, ASP.NET impersonation is turned off and the resources can be accessed using a “local system process” account. Nothing needs to be done here, since initial installation of the IIS would have addressed it.
But when impersonation is turned on, ASP.NET executes every resource using the account of a specified user who is authenticated when the user makes the request. If you specify the IUSR_machinename account to be used as the user account, then ASP.NET will behave like previous versions of ASP, in providing access to the resources (more).

IIS impersonates users with its own IUSR account.
In the case of ASP.NET, impersonation is used to decide whether the user’s request should be executed using the account of the requested user, or that of a local system-process account that ASP.NET uses for anonymous requests.

There are some rules applied when combination of impersonation and anonymous access is used in ASP.Net application:

1. Impersonation is enabled:
   • Anonymous access is enabled in IIS – the request is made using the IUSR_machinename account.
   • Anonymous access is disabled in IIS – the request is made using the account of the authenticated user.
2. Impersonation is disabled:
   • Anonymous access is enabled in IIS – the request is made using the system-level process account.
   • Anonymous access is disabled in IIS – the request is made using the account of the authenticated user.
3. In either case – permissions for the account are checked in the Windows Access Control List (ACL) for the resource(s) that a user requests, and a resource is only available if the account they are running under is valid for that resource.

Lets assume that the following settings are used

<system.web>
  <identity impersonate="true" />
 <!-- WS: Allow only Authenticated users -->
 <authorization>
 <!-- allow users="*"/ -->
    <deny users="?" />
  </authorization>
</system.web>

In this mode ASP.NET impersonates the current Web user. It gets this token from IIS which passes this account token on the ISAPI thread that originally fires off this request.

We can go further and impersonate the process directly by specifying its identity:

<identity impersonate="true" password="password" userName="username" />

In this case access to any resource would be performed in the context of the user specified, instead of user associated with the session.
To ensure the proper context, it can be verified with the following code:

// Returns the security identity of the current running thread
System.Security.Principal.WindowsIdentity.GetCurrent().Name

// Returns the identity of the user which session is belong to
WindowsIdentity.GetCurrent().Name

As you can see, we need to ensure that all accounts involved have sufficient rights to access resources involved.

Before going further, check if including an impersonation account in the default IIS_WPG user group would be sufficient before setting more complex scenario.

Crystal Reports effect

Being an insight process, Crystal Reports engine would also require access to some additional file resources:

1. Location of the report files
2. Local TEMP folder as described below

Why User TEMP folders is involved? Why would Crystal Reports control in IIS need to access it?

Short answer – because CR engine keeps cache of report files for the session.
Do a little experiment, without impersonation enabled, check Temp folders when report is visible in the Viewer.
You would notice files appear and disappear there:

• <Report Name> {GUID}.rpt is a cache of the report file for the session
• ~cpe{GUID}.rpt is a cache of the report data view

The location of TEMP folder may vary: C:\WINDOWS\Temp for older versions of Windows, or more elaborate “C:\Documents and Settings\…” and “C:\Users\…” in latest versions.
And in case of user account specific variation, one would have to guess which user related folder has to checked.  With impersonation enabled and finding context of the call, we can now properly determine the location and required access level:

• Associated account should be allowed create/modify/delete files in TEMP folder.
• For IIS 7.0, Temp folder location would be different.
  Proper default location would be %windir%\serviceprofiles\networkservice\AppData\Local\Temp as described here.

Limit CR Engine access to TEMP folder

 Described is default behavior, which could be adjusted to limit access to more relevant location.

Visit the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\Report Application Server\InprocServer

or in case of 64 bit Vista (not being familiar at first with new registry structure you may be surprised about this)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Business Objects\Suite 12.0\Report Application Server\InprocServer

then add/update the following value

TempDir: String = “your folder”

This will tell engine which folder to use. And then by granting proper permissions as discussed above it would solve the grand problem. Restart your web server and you should be good to go.

To validate that account has proper permissions for the folder specified, the following command can be used

CACLS * /T > output.txt
being executed from command prompt it will create output.txt which contains list of permissions for the current folder

Notes:

1. Solution above can be used for any prior version of Crystal Reports, but may require minor adjustments.
2. Problem with permissions could also cause broken image links in the Viewer
3. Depend on configuration, permissions could be required for NETWORK SERVICE account and/or IIS_WPG group.