locked
For a Windows impersonation account error "does not have write access" RRS feed

  • Question

  • User-1695411901 posted

    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.

    Thursday, May 30, 2019 1:42 PM

Answers

  • User-1695411901 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 24, 2019 2:31 PM

All replies

  • User-1174608757 posted

    Hi inguam,

    According to your description, you could also solve this issure by setting the permission of folder.You could follow the steps as below:

    1. Open Windows Explorer
    2. Select the directory the Smartcrypt Manager is installed under (eg: c:\web\mds)
    3. Right click the directory and select Properties
    4. Select the Security tab
    5. Click the Edit button and then Add button
    6. Click the Locations button and make sure that you select your computer.
    7. Enter IIS AppPool\<myappoolname> (eg: IIS AppPool\smartcrypt) in the Enter the object names to select: text box.
    8. Click the Check Names button and click OK.
    9. Check Modify under the Allow column, and click OK, and OK.

    Best Reards

    Wei

    Friday, May 31, 2019 3:17 AM
  • User-1695411901 posted

    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

    Friday, May 31, 2019 1:09 PM
  • User-1174608757 posted

    Hi inguam,

    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.

    Best Regards

    Wei

    Monday, June 3, 2019 2:06 AM
  • User753101303 posted

    Hi,

    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).

    Tuesday, June 4, 2019 5:42 PM
  • User-1695411901 posted

    Thanks!  These give me a lead to follow - thanks again!

    Monday, June 10, 2019 2:08 PM
  • User-1695411901 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 24, 2019 2:31 PM