UNC Shares

There are two main ways that your ASP.NET application might use UNC shares:

• Accessing files on UNC shares

  For example, your application must access a remote file such as \\remoteserver\share\somefile.dat.

• Hosting applications on UNC shares

  Your application's IIS virtual directory is mapped to a remote share, for example, \\remoteserver\ appname . In this scenario, HTTP requests are processed by your Web server, but the application's pages, resources, and private assemblies are located on the remote share.

Accessing Files on UNC Shares

If your application accesses files on a UNC share, the ASP.NET process account or any impersonation identities must have the appropriate access rights defined by the ACL on the share and on the underlying directory or file.

If you use the local ASPNET process account, this does not have a network identity, so you must create a mirrored account on the remote server with a matching user name and password, or you must use a least privileged domain account that has access to both servers. On Windows Server 2003, the NetworkService account that is used to run ASP.NET Web applications can be authenticated over the network, so all you need to do is grant access rights to the machine account.

Hosting Applications on UNC Shares

You can use IIS to configure a virtual directory to point to a UNC share located on another computer, for example \\remoteserver\appname. When you do so, IIS prompts you to supply account credentials, which it uses to establish a connection to the remote computer.

Note  

The account credentials are stored in encrypted format in the IIS metabase but are available through an API. You should ensure that you use a least privileged account. For more information, see Microsoft Knowledge Base article 280383, "IIS Security Recommendations When You Use a UNC Share and Username and Password Credentials."

If your application resides on a UNC share, ASP.NET impersonates the IIS-provided UNC token (created from the account credentials that you supplied to IIS) to access that share, unless you have enabled impersonation and have used a fixed impersonation identity, as shown with the following configuration:

 <identity impersonate="true"   userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"   password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/> 

If a fixed impersonation account is provided through the userName and password attributes, ASP.NET uses that account instead of the IIS UNC token to access the share. Any resource access performed by your application also uses the fixed impersonation account.

Note  

In the above example, Aspnet_setreg.exe has been used to store the encrypted account credentials in the registry.

If you enable impersonation of the original caller (IIS authenticated identity) by using the following configuration, ASP.NET still uses the UNC-provided token to access your application's files on the share, although any resource access performed by your application uses the impersonation token.

 <identity impersonate="true" /> 

Note  

The account used for the UNC share must also be able to read Machine.config.

Code Access Security Considerations

Applications on a UNC share are granted the intranet permission set by code access security policy. The intranet permission set does not contain AspNetHostingPermission , which ASP.NET Web applications require to run, so your application will not run without explicit policy modifications.

You have two options:

• Grant full trust to the UNC share on which your application is hosted.

  This is the simplest option to manage and if you run .NET Framework version 1.0, this is the only option because ASP.NET version 1.0 Web applications require full trust.

• Configure code access security policy to grant your code the AspNetHostingPermission and any other permission it might require based on the types of resources it accesses and the operations it performs .

  Because of the way in which ASP.NET dynamically creates code and compiles page classes, you must use a code group for the UNC and the Temporary ASP.NET Files directory when you configure policy. The default temporary directory is \WINNT\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files, but the location is configurable on a per application basis by using the tempDirectory attribute of the <compilation> element.

  For more information about ASP.NET code access security policy and sandboxing privileged code, see Chapter 9, "Using Code Access Security with ASP.NET."

  Note  

  When configuring policy, you should grant trust to the share (by using a file location) rather than to the zone. This provides finer granularity because you do not affect all the applications in a particular zone.