ASP.NET application pool and identity

In an ASP.NET application, the IIS Web Server assigns an application pool under which an application will run. This application pool has associated settings regarding the execution environment like user, .NET framework version, etc. If an ASP.NET application is not developed with these application pool settings in mind, then this ASP.NET application will fail to run. Basically, these application pool settings determine how an ASP.NET application will be executed.

By default, many ASP.NET applications run under the “NETWORK SERVICE” identity (in other Windows environment, applications run under “ASPNET” by default) as assigned through the application pool context. This default identity has very limited permissions:

• Restricted access to file system
• Limited permissions to access or modify the Windows registry
• Cannot properly spawn a new process, etc.

The above list is only indicative of the restrictions that are of interest to the current topic, and is not a comprehensive list. These limited permissions to Windows resources under this identity are important for ASP.NET applications in order to ensure security.

Having a very limited access to Windows resources, calls to ToPdf will fail on an ASP.NET application if the application pool’s identity is set to “NETWORK SERVICE” or any lower (more restrictive) identity. It is a known issue that Microsoft Office Interop assemblies will not work under this identity. In most cases, when ToPdf is used under “NETWORK SERVICE” identity, the web application will show an error message about retrieving COM class factory failed. The simplest explanation for this error is that COM objects can only be activated by the following accounts:

• Administrator
• System
• Interactive

Using the PDFNet printer will also fail under the “NETWORK SERVICE” identity. This is because in order to print a document, the document will have to be opened first by an external application which will send the print job. Opening this document will spawn a new process. This new process will be the default application to open the document. As mentioned earlier, “NETWORK SERVICE” has limited permissions when spawning a new process. In most cases, many applications require a graphical interface to complete its initialization before execution continues. One example of which is notepad.exe. With these applications, if the graphical interface cannot be loaded, then it will look like the process appears to be stuck - even though there is an entry for this application in the process list where it seems like it is waiting for something. This is the case when attempting to spawn a new process under “NETWORK SERVICE”.

In most cases, elevating the application pool’s identity to “LOCAL SYSTEM” will allow an ASP.NET application to use the ToPdf method without any issues. It is important to keep in mind, however, that using this identity presents security risks on the web server machine. “LOCAL SYSTEM” has wider ranges of privilege access to Windows resources. It allows many resources to be accessed by the ASP.NET application assigned to the application pool. If an ASP.NET application is exploited, running under the “LOCAL SYSTEM” identity may allow the web server machine to be exploited as well.

Similar to a Windows Service application which may use the “LOCAL SYSTEM” account, there may be additional requirements in order to get the ToPdf method to function correctly. Please see the Windows Service page for more details.

ASP.NET impersonation allows ASP.NET applications to execute code under the context of the impersonated user. Using impersonation in ASP.NET allows Microsoft Office Interop to be used under the “NETWORK SERVICE” identity (for the application pool). In order to use ASP.NET impersonation, simply make the application’s web.config contain a line similar to below:

<configuration>
<system.web>
<identity impersonate=”true” username=”computer\myuser” password=”********” />
</system.web>
</configuration>

Using ASP.NET impersonation, however, will not allow an ASP.NET application to use the PDFNet printer. As such, under an ASP.NET impersonation, ToPdf will only work with Microsoft Office documents provided that a minimum version of Microsoft Office Suite is installed on the machine.

According to Microsoft:

… in ASP.NET, impersonation is performed at the thread level and not at the process level. Therefore, any process that you spawn from ASP.NET will run under the context of the ASP.NET worker process (NETWORK SERVICE) and not under the impersonated context.”

As mentioned earlier, the PDFNet printer in ToPdf method requires spawning a new process in order to print documents. The article below describes how to spawn a process with ASP.NET impersonation:
http://support.microsoft.com/kb/889251/en-us

As long as the created process is run under accounts which have proper permissions, the PDFNet printer should be able to convert documents properly.

Perhaps the best solution to introduce a conversion feature in an ASP.NET project is to have an isolated application which will be responsible for doing the conversions. Having a separate application will ensure that the security model of the ASP.NET application remains intact. This will also provide the converter application all the permission it requires to successfully convert a document.

This separate application can either be a Windows service listening for conversion tasks or a console application which will be started by the ASP.NET application. As long this application’s permission is limited to accessing specific registry keys used for printing and allowing process creation, all the conversion processes of ToPdf should work.

THe below links have more information about service accounts and ASP.NET Impersonation.
http://msdn.microsoft.com/en-us/library/ms686005%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/xh507fc5%28v=VS.100%29.aspx