IIS 7.5, ASP.NET, impersonation, and access to C:\Windows\Temp

Question

Summary: One of our web applications requires write access to C:\Windows\Temp. However, no matter how much I weaken the NTFS permission, procmon shows ACCESS DENIED.

Background (which might or might not be relevant for the problem): We are using OLEDB to access an MS Access database (which is located outside of C:\Windows\Temp). Unfortunately, this OLEDB driver requires write access to the user profile's TEMP directory (which happens to be C:\Windows\Temp when running under IIS 7.5), otherwise the dreaded "Unspecified Error" OleDbException is thrown. See KB 926939 for details. I followed the steps in the KB article, but it doesn't help.

Details:

This is the output of icacls C:\Windows\Temp. For debugging purposes I gave full permissions to Everyone.

C:\Windows\Temp NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                CREATOR OWNER:(OI)(CI)(IO)(F)
                BUILTIN\IIS_IUSRS:(OI)(CI)(S,RD)
                BUILTIN\Users:(CI)(S,WD,AD,X)
                BUILTIN\Administrators:(OI)(CI)(F)
                Everyone:(OI)(CI)(F)

However, this is the screenshot of procmon:

procmon screenshot

Desired Access: Generic Read/Write, Delete
Disposition:    Create
Options:        Synchronous IO Non-Alert, Non-Directory File, Random Access, Delete On Close, Open No Recall
Attributes:     NT
ShareMode:      None
AllocationSize: 0
Impersonating:  MYDOMAIN\myuser

PS: When logged in as MYDOMAIN\myuser, I can create files in C:\Windows\Temp using Windows Explorer without any problems.

EDIT: Relevant parts of web.config:

 <authentication mode="Windows" />
 <identity impersonate="true" />
 <authorization>
   <deny users="?" />
   <allow users="*" />
 </authorization>

Authentication seems to work, i.e., System.Security.Principal.WindowsIdentity.GetCurrent().Name (which is shown on my custom error page) returns MYDOMAIN\myuser.

PS: I also considered posting this to serverfault instead, but my guess would be that this is a problem with how ASP.NET handles impersonation rather than a Windows configuration issue. — Heinzi, Jun 07 '10 at 13:11
What are the values for `` and `` in `Web.config` and is IIS configured to allow anonymous access (not sure if this is still applicable in IIS7)? — scherand, Jun 07 '10 at 13:16
@scherand: I've updated my question. IIS7.5 seems to use the .net settings w.r.t. anonymous access. — Heinzi, Jun 07 '10 at 13:31
Hmm - that is beyond me, sorry to have bothered you :( If you feel like experimenting and have not done so already you might check what identity through `HttpContext.Current.User.Identity.Name` or `System.Threading.Thread.CurrentPrincipal.Identity.Name` and if you feel like reading I found the following article [Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7.0](http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx) but I am not at all sure if this is going to help... — scherand, Jun 07 '10 at 14:41
Did you add permission for ServerName\ASPNET as described in KB827190 (http://support.microsoft.com/kb/827190)? — Sheng Jiang 蒋晟, Sep 07 '11 at 15:18
@Sheng: Well, I gave full permissions for `Everyone`, which should include `ServerName\ASPNET`, right? — Heinzi, Sep 08 '11 at 06:36
@SirCrispalot: Well, we "solved" it by replacing the Access database with an XML file. Unfortunately, we never found the underlying cause for the original problem. — Heinzi, Sep 23 '13 at 15:22

score 4 · Answer 1 · answered Jun 15 '10 at 03:27

4

Have you tried following the steps on this: loadUserProfile and IIS 7 temporary directory failures

answered Jun 15 '10 at 03:27

Carlos Aguilar Mares

13,411
2
39
36

Well, that's exactly what I did (grant permissions). I even went so far as to grant *full* permissions. – Heinzi Jun 15 '10 at 07:49
If that's where the temp dir is, you did *not* set it to loadUserProfile – Andrew Barber Oct 08 '11 at 04:01
1

@AndrewBarber: The article says: "*The answer is pretty straight forward: turn off loadUserProfile, **or** ACL the temp directory to allow writes.*" Note the "*or*". Thus, according to the article, just setting the ACLs on the temp directory *should* fix the problem, but it doesn't. But yes, the workaround using loadUserProfile is useful, so +1 to the answer (no "accepted answer" yet, since it does not answer the original question -- "why does the write access to C:\Windows\Temp not work even though full permissions are given"). :-) – Heinzi Oct 08 '11 at 10:24
Agree with @Heinzi ... although it does not answer the original question here, it does solve the problem, so +1. – FastTrack Mar 03 '19 at 16:10

IIS 7.5, ASP.NET, impersonation, and access to C:\Windows\Temp

1 Answers1