Last post Jun 24, 2019 02:31 PM by inguam
May 30, 2019 01:42 PM|inguam|LINK
When using Windows impersonation, the account is a domain account but the app pool runs under ApplicationPoolIdentity. The error shows the domain account: The current identity (domain\username) does not have write access to 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary
ASP.NET Files'. When I add this domain account to the IIS_IUSRS group on the machine, it works just fine. I would like a cleaner way to solve this issue , that also doesn't do anything to the sever. For example, I don't want to use the tool command: aspnet_regiis.exe
-ga domain\user) or by setting permissions on the .NET temp folder itself. Any thoughts? I have the source code, since a coworker wrote it, so I can update the code as well if need be.
May 31, 2019 03:17 AM|Wei Zhang|LINK
According to your description, you could also solve this issure by setting the permission of folder.You could follow the steps as below:
May 31, 2019 01:09 PM|inguam|LINK
Thanks, but I forgot to mention in the post that I would like to avoid setting permissions on the folder itself. I updated the post to say that. Thanks anyway
Jun 03, 2019 02:06 AM|Wei Zhang|LINK
As far as I known,Setting permissions of folder seems the only way to set the permission if you don't want to add account to local machine.
Jun 04, 2019 05:42 PM|PatriceSc|LINK
Going the other way round I don't see many options as only SYSTEM, Admins and IIS_IUSRS have a write permission there.
It would left us with :
- AFAIK "Temporary ASP.NET Files" is used for dynamic compilation (such as aspx or cshtml files). If better understanding what is left, it it might be perhaps possible to precompile absolutely anything in which case it might be not needed anymore
- maybe if the IIS site is configured to load before its first use ("autostarting" the web site) so that the user identity is not used maybe ?
Short of those corner cases I don't see any other option (for now I would use IIs_IUSRS and would try to understand why it is needed)
BTW make sure using impersonation is really required (I suspect impersonation sometimes end up in being configured for a wrong reason such as using the wrong function to get the authenticated user identity).
Jun 10, 2019 02:08 PM|inguam|LINK
Thanks! These give me a lead to follow - thanks again!
Jun 24, 2019 02:31 PM|inguam|LINK
I looked at this deeper and found that I had ASP.NET Impersonation and Windows Authentication enabled in IIS. Apparently, having both enabled it uses the impersonating account to compile the app (which is why it needed accessed to that .NET temp folder),
and not the app pool account (which was set to ApplicationPoolIdentity). I disabled ASP.NET Impersonation and changed the running account for the app pool to the account that I was using for impersonation, and it worked correctly.