Ssl – Will disabling SSL 2.0 automagically make it use SSL 3.0 in IIS7

It goes a little bit beyond just turning off SSL 2.0. You also have to disable weak encryption algorithms by following this MS KB. Your PCI scan should have pointed out what specifically it found.

You can use a website like, https://www.ssllabs.com/ssldb/index.html for testing your SSL certs.

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)