views:

512

answers:

1

I am experiencing assembly binding failures due to insufficient permissions to the Temporary ASP.NET Files folder.

The application uses (web.config) Forms authentication with Impersonate = True and IIS Windows Integrated Authentication.

According to ASP.NET Identity Matrix, this means that the WindowsIdentity resolves to Domain\UserName and according to ASP.NET Required Access Control Lists (ACLs), the WindowsIdentity requires read/write permissions to the Temporary ASP.NET Files folder.

Using the Fusion log viewer, I can confirm that the assembly binding failure is due to Domain\UserName (belonging to the "Users" group in security) only having read permissions to this folder, but not write permissions.

The questions are:

Are there any security implications of assigning write permissions to the Temporary ASP.Net Files folder?

Is such a server configuration change commonly used? If not, why would WindowsIdentity resolve to Domain\UserName for this combination of web.config settings - or should this combination not be used in this context?

Note: The problem only occurs if a non-admin user is the first to hit the page. If the assembly has already been compiled and stored in Temporary ASP.NET Files due to an admin user hitting the page, there are no problems for subsequent users. I do NOT wish to place the assemblies in the GAC.

+1  A: 

ASP.NET requires write permission to the Temporary ASP.NET files folder, it shouldn't be a security risk providing you only grant permission to that folder and not any higher as it sits within the c:\windows folder.

This MSDN article about securing ASP.NET applications recommends granting full control to the temporary compilation directory to the ASP.NET process identity. I've quoted the relevant section:

By default, temporary files are created and compiled in the following directory:

%winnt%\Microsoft.NET\Framework{version}\Temporary ASP.NET Files

You can specify the location on a per application basis using the tempDirectory attribute, although this provides no security benefit.

Note The ASP.NET process identity specified on the element requires Full Control access rights on the temporary compilation directory.

Steve Temple
(You need to add "msdn" to the front of the link.)Yes, but in this case, the web.config settings mean that the DOMAIN\User (configured impersonation) requires write access and the question was specifically about what security implications this could have. The ASP.NET Process is not figuring as part of this assembly binding.
Joergen Bech