Datasheet

Configured Impersonation Extra Security Configuration

None or Client Because application initialization runs as the configured

UNC identity, the UNC identity requires Modify access to

the Temporary ASP.NET Files directory.

However, it is also highly recommended that you configure

the UNC identity with

aspnet_regiis -ga <UNC iden-

tity>

Application Even though the application is on a UNC share, it is the

application impersonation identity that is used to monitor

change notifications for content files such as

global.asax

(recall the earlier discussion that described which identity is

in effect during application domain initialization). As a

result, the application impersonation identity requires read

permissions on the UNC share (both share permissions and

NTFS permissions).

If you plan to use code in

Application_Start that depends on the security credentials associated with

the operating system thread, you need to ensure that depending on how your application is configured

the correct identity has rights to your backend data stores. For example, if you are planning on connect-

ing to a database to fetch a dataset inside

Application_Start, and you use Integrated Security with

SQL Server; then the process identity, application impersonation identity, or the configured UNC iden-

tity need the appropriate rights on your SQL Server. The first two credentials make sense, but the UNC

identity probably would catch some folks by surprise, especially if an application that was working fine

when running from a local hard drive on a web server was moved to a UNC share on a production

server. The moral of the story is that when running with a UNC identity, be careful and to test your

application in an environment that closely mirrors the UNC structure you use in production.

Although the previous discussion centered on the

Application_Start event, the same rules and

rationale for determining security credentials are used when the

Application_End event executes.

Summary

In this chapter, you walked through many of the behind-the-scenes steps that occur when an application

domain is started, as well as when the first request to the application domain is processed. Before a

request is “seen” by the ASP.NET runtime though, the following hurdles must be cleared:

1. http.sys must consider the request to be well formed prior to passing it on to IIS

2. The ISAPI filter aspnet_filter.dll disallows any requests to special ASP.NET directories

(/bin, App_Data, sand so on).

3. IIS determines whether the request is for static content or dynamic content. If IIS recognizes that

the file extension for the requested resource is one that is mapped to ASP.NET, IIS forwards the

request to ASP.NET’s ISAPI extension

4. The ASP.NET ISAPI extension must complete a long series of steps that ultimately result in an

application domain being spun up in-memory and prepared for executing ASP.NET requests

Chapter 1

04_596985 ch01.qxp 12/14/05 7:46 PM Page 28