11

I'm using IIS7 (Windows Server 2008 x64) and I have a website setup using anonymous authentication. The anon user identity is configured as IUSR. The application writes files to a folder and I'm giving the IIS_IUSRS group RW permissions to the folder. This doesn't work. I must explicitly give IUSR RW perms to allow the application to write to the folder.

It's my understanding that the application pool identity is automatically added to the IIS_IUSRS group. I assumed that IUSR (or any anonymous user identity) was also an implied member of the IIS_IUSRS group as well. It doesn't appear that this is the case.

While troubleshooting, I use Process Monitor to view access to the folder and determined that Network Service (the application pool identity) is impersonating IUSR (this is what I expected) but giving RW perms to the IIS_IUSRS group didn't allow IUSR to access the file (Access Denied).

Can anyone explain whether IUSR is or isn't a member of the IIS_IUSRS group?

I've reviewed the following documentation and found no solid answer:

Understanding Built-In User and Group Accounts in IIS 7

Application Pool Identities

Izzy
  • 8,214
  • 2
  • 30
  • 35

1 Answers1

14

That is because these are two different things. IIS_IUSRS is the group for IIS Worker Process Accounts. This means the identity that the application pool itself runs under. IUSR is the anonymous user identity. That means the identity that IIS believes to be the user who is accessing the site.

Now even though you didn't say it, let me guess - this app is classic asp? (Otherwise, if it is .Net then you must be using impersonation). Either way, what happens is that resources are accessed as the impersonated identity, meaning, the anonymous user in your case, meaning IUSR. That is why you have to grant it the rights. In .Net, if you turn off impersonation, you will find that IIS_IUSRS will come into play as you are expecting. In Classic ASP (and for static files), you don't have a choice, impersonation is always "enabled"; so its always the user identity which is used, not the pool identity. So since IIS_IUSRS is for pool identities, it is not in play.

Edit after OP added more information:

It is easy to confuse IUSR and IIS_IUSRS because of their names. To way to see that they are different is to remember that IIS_IUSRS is a replacement for IIS_WPG in IIS6, which was the Worker Process Group. To these groups you add accounts that you want to run your pools under, not anon identities, anon privileges are supposed to be more limited. eg. sometimes you might want to use a domain account to run the pool for kerberos delegation to other network resources. Then you would add that service account to this group.

When impersonation is enabled the pool/process pretends to be the user because it was told to. In case of anon auth (your case), that user is IUSR. In case of windows auth, it would be the user's windows\domain identity. This is also why you get a performance hit with impersonation, because the process has to switch to a different identity for resource access.

If you are using .NET and anonymous authentication, then I don't see why you would enable impersonation though. In case you are not using or don't need impersonation, you should be aware of some more trickery in the case of IIS7: you can make your IUSR go away completely and end all confusion. I think you would like that, and it's my preferred method too. All you have to do is to tell it to reuse the pool identity as the anonymous identity.

So after this you will only have to deal with the IIS_IUSRS group. But dont get confused, this still doesn't mean that these two are the same! It may be possible for the process identity to substitute for IUSR, but not the other way around !

Some more IIS7 trickery to be aware of: if you look at IIS_IUSRS, it may be empty. Thats because your virtual pool identities are automatically added to it when the pool starts, so you dont have to worry about these things.

This table should help clarify better how the thread execution identity is determined:

Impersonation  Anonymous Access   Resources Accessed As

Enabled          Enabled           IUSR_computer in IIS5/6 or,
                                       IUSR in IIS7 or,
                                       If you changed the anon user account 
                                       in IIS,  whatever you set there
Enabled          Disabled          MYDOM\MyName
Disabled         Enabled           NT Authority\Network Service (pool identity)
Disabled         Disabled          NT Authority\Network Service (pool identity)
Amit Naidu
  • 774
  • 5
  • 11
  • We are definatley using .Net (3.5 targeted) but it may be using impersonation. I'll have to check with my developers to be certain. My confusion stems from the fact that I assumed (incorrectly it seems) that the anonymous user identity was automatically a member of the IIS_IUSRS group. Since he isn't then allow me to clarify and please correct me if I'm worng. –  Oct 04 '10 at 17:50
  • 1) Using classic ASP, file access permissions use the anonymous user identity. In IIS 7 or later, this user is not a member of the IIS_IUSRS group by default. 2) Using ASP.Net, file access permissions use the anonymous user identity if impersonation is enabled. In IIS 7 or later, this user is not a member of the IIS_IUSRS group by default. 3) Using ASP.Net, file access permissions use the worker process identity if impersonation is disabled. In IIS 7 or later, this user is always a member of the IIS_IUSRS group by default. –  Oct 04 '10 at 17:58
  • Yes absolutely correct on all points! To be perfectly clear, in #1 and #2 you should add "if IIS anon auth is enabled", which I didn't have to include earlier because you already said you are using anon. See the table I added to better explain this. – Amit Naidu Oct 07 '10 at 09:00
  • Thank you very much for clarifying this. It agrees with what I have found through trial and error but I haven't seen this documented very clearly anywhere.It's critical to admins who employ LUA on their servers when setting up IIS applications that need write permission. –  Oct 11 '10 at 13:17