5

Namely how is setting read/write permission for this account different from giving read/write access in the IIS (Windows 2003, so it should be IIS6 if I am not mistaken).

Here is the issue: It looks like we had a security sweep and as a part of that IUSR account lost write access everywhere. A whole bunch of legacy ASP sites didn't like that at all...

My very surfacish understanding is that it is enough to deny write access in the IIS console to protect a website from someone just dropping random files into it, and IUSR access only has effect on the application scripts running server side, and thus can be safely given write access back.

edit:

The applications in question obviously require write access to their own web folders, otherwise this wouldn't be an issue at all. Question is how to configure IIS/application to both satisfy security and make them work. My first instinct was to change account which is used to run the app pool. However that is already set to NETWORK_SERVICE, and that guy already has full access to folders in question.

liho1eye
  • 123
  • 2
  • 9

2 Answers2

3

Most people have a hard time understanding the difference between IIS' anonymous user (IUSR_...) and the account used executing binaries (the application pool account).

The IUSR account is used when the user isn't authenticated on the server which is - for "normal" websites - is the default use case. For intranet sites you could disable anonymous access to the IIS server and let users (automatically) submit their network/domain credentials.

The anonymous account's permissions on files and folders determines which resources (files) the normal web user can access on that server. Normally all (static) files are read-only and you don't allow listing of the folder content.

The application pool identity (e.g. the Network Service account) is something different. It's the account that executes your scripts or assemblies, the process identity. For example, if your application wants to write to a certain folder (e.g. C:\temp) that account must have the filesystem permission to modify files in that folder.

Here are some links for additional information:

Community
  • 1
splattne
  • 28,348
  • 19
  • 97
  • 147
0

The IUSR account is a builtin user account that is used by default as the anonymous user in IIS6. It is not a powerful account by default and generally I advise my users to not use it if possible. The primary reason for this is the principle of isolation. You don't want spillover affects from other admins making your app unhappy.

unhappyCrackers1
  • 977
  • 1
  • 6
  • 18
  • A detailed response to your last paragraph requires more details such as what version of ASP.NET is involved. In general, I would take issue with your assumptions. IMO the least-privileged account principle is a good approach to the situation. You want redundancy in a high security environment and you don't want processes running with any more privilege than is required to properly function. This excellent blog post should deepen your understanding of the topic: http://blogs.iis.net/davcox/archive/2009/08/12/who-is-the-anonymous-user.aspx – unhappyCrackers1 Jan 28 '11 at 21:37
  • As per my original post I am dealing with ASP sites, not ASP.NET. Updated my question to be more clear. – liho1eye Jan 28 '11 at 21:56
  • Right, Classic ASP is definitely a different beast than ASP.NET 2.0. Your permissions issues will tend to revolve around the app pool in ASP.NET and in Classic ASP it is usually the Anonymous user. You really want to tighten up both the user permissions as well as the directory restrictions configured in the IIS Manager. The link above outlines some of how IIS works in this regards. – unhappyCrackers1 Jan 28 '11 at 22:45
  • I looked over you link (an links inside it) and all that is telling me is to disable write access for IUSR account, without really any good reason. As per issue in my original post that is not acceptable. On the other hand I found this http://blogs.msdn.com/b/david.wang/archive/2005/08/20/why-can-i-upload-a-file-without-iis-write-permission.aspx which confirmed exactly what I thought. It is pretty safe to give IUSR permission to write to web folder (assuming application itself is not injectable in any way). – liho1eye Jan 29 '11 at 00:01