Here is detail explaination about the IIS 7.0 and IIS 6.0 user and group account from IIS team.

Introduction

In previous versions of IIS, we had a local account created at install time called IUSR_MachineName. The IUSR_MachineName account was the default identity used by IIS whenever anonymous authentication was enabled. This was used by both the FTP and HTTP services. 

There was also had a group called IIS_WPG, used as a container for all the application pool identities. We made sure all the appropriate resources on the system had the correct permissions set for the IIS_WPG group during IIS setup so that an administrator only needed to add their identity to that group when they created a new application pool account.

This model worked well, but had its drawbacks: the IUSR_MachineName account and IIS_WPG group were both local to the system it was created on. Every account and group within Windows is given a unique number called a SID (security identifier) that distinguishes it from other accounts. When an ACL is created only the SID is used. As part of our design in previous versions of IIS, we had included the IUSR_MachineName in the metabase.xml file so that if you tried to copy the metabase.xml from one machine to another, it would not work–the account on the other machine would have a different name.

In addition, you could not just ‘xcopy /o’ ACLs from one machine to another since the SIDs were different machine to machine. A work around was to use domain accounts–but that required adding an active directory to the infrastructure. The IIS_WPG group had similar issues with permissions. If you set ACLs on one machine’s file system for IIS_WPG and tried to ‘xcopy /o’ those over to another machine, it would fail. The IIS team heard this feedback and improved this experience by using a built-in account and group in IIS 7.0.

 A built-in account and group are guaranteed by the operating system to always have a unique SID. IIS 7.0 has taken this further and ensured the actual names used by the new account and group will never be localized. For example, regardless of the language of Windows you install, the IIS account name will always be IUSR and the group name will be IIS_IUSRS.

 In summary, IIS 7.0 offers:

• The IUSR built-in account replaces the IUSR_MachineName account
• The IIS_IUSRS built-in group replaces the IIS_WPG group

Since the IUSR account is a built in account, it no longer needs a password. Logically, think of it as being the same as NETWORKSERVICE or LOCALSERVICE accounts. Both the new IUSR account and IIS_IUSRS group are discussed in greater depth in the sections below.

Understanding the new IUSR account

As mentioned above, the IUSR account will replace the IUSR_MachineName account in IIS 7.0. The IUSR_MachineName account will still be created and used only when the FTP server is installed. If FTP is not installed, then this account will never be created.

This built-in account does not need a password and will be the default identity used for when anonymous authentication is enabled. If you look in the applicationHost.config file you will see the following definition:

<anonymousAuthentication enabled=“true” userName=“IUSR” defaultLogonDomain=“” />

This tells IIS that we want to use the new built-in account for all anonymous authentication requests. The biggest advantage of this is we can now:

• Set file system permissions for the IUSR account using Windows Explorer or any of the many command line tools
• No longer need to worry about passwords expiring for this account
• Use xcopy /o to copy files along with their ownership and ACL information to different machines seamlessly

A key point to stress: the IUSR account is similar to LOCALSERVICE in the manner in which it acts anonymously on the network. The NETWORKSERVICE and LOCALSYSTEM accounts can act as the machine identity–but the IUSR account will not, since it would be an elevation of privilege. If you need the anonymous account to have rights on the network, you will need to create a new user account and set the user name and password manually as you had in the past for anonymous authentication. To do this using the IIS 7.0 Manager:

1. Click Start, and type INetMgr.exe and click Enter (if prompted, select Continue to elevate your permissions).
2. Click the + button beside the name of your machine in the Connections section.
3. In IIS 7.0 Manager, double click the site you want to administer.
4. Double click the Authentication item under the Feature Name heading.
5. Select Anonymous Authentication and then click on Edit in under the Tasks heading on the right side which brings up the Specify Credentials dialog.
6. Click the Specific User option and then click Set.
7. Input the username and password desired and select OK.

Understanding the new IIS_IUSRS group

As discussed earlier, the IIS_IUSRS group is intended to replace the IIS_WPG group. This built-in group has been granted access on all the necessary file and system resources so that an account, when added to this group, can act as an application pool identity seamlessly.

As with the built-in account, this built-in group solves several xcopy deployment obstacles. If you set permissions on your files for the IIS_WPG group (that was available on IIS 6.0 systems) and tried to copy those files to another Windows machine, the group’s SID would be different across the machines and your site’s configurations would be broken.

Since the group SID in IIS 7.0 is the same on all systems running Windows Server 2008, using ‘xcopy /o’ will preserve the ACL’s and ownership information as you move files from machine to machine. This now makes XCOPY deployments very easy.

A second request customers made was “Once we configure an application pool identity, we want IIS to do all the necessary changes for us.” The IIS team responded to this feedback and made this process much easier in IIS 7.0. When IIS starts a worker process, it needs to create a token that process will use. Now, when we create this token, IIS 7.0 automatically adds the IIS_IUSRS membership to the worker processes token at runtime. By doing this, accounts that have been defined to run as ‘application pool identities’ no longer need to explicitly be part of the IIS_IUSRS group. This change helps you setup your systems with less obstacles and makes your overall experience more favorable.

If you want to disable this feature and manually add accounts to the IIS_IUSRS group, disable this new feature by setting the manualGroupMembership value to ‘true’. Below is an example of how this can be done to the defaultAppPool:

<applicationPools>
    <add name=“DefaultAppPool”>
        <processModel manualGroupMembership=“true” />
    </add>
</applicationPools >