Original address: http://www.iis.net/1026/SinglePageArticle.ashx
Translated by: Tony Qu (from BluePrint Translation Team)
Author: Vikas Malhotra
Last updated: Tuesday, September 12, 2006 at 11:48 AM
Introduction In previous versions of IIS there was a local account that was created during installation called IUSR_MachineName. Once anonymous authentication is enabled, this IUSR_MachineName account is the identity used by IIS by default, and it is used in both FTP and HTTP services. There is also a group called IIS_WPG, which is the container for all application pool accounts. During the IIS installation, you must ensure that all available system resources have been set with appropriate permissions for IIS_WPG. When the administrator creates a new application pool account, you only need to add the new account (identity) to this group.
This model works very well, but like any other design, they have their drawbacks, the main drawback being that the IUSR_MachineName account and the IIS_WPG group are local to the system on which they are created. Each account or group in Windows has a unique number called SID (Security Identification Number), so that it can be distinguished from other accounts or groups. We only use the SID to create the ACL. As part of the design of previous versions of IIS, we included IUSR_MachineName in the metabase.xml file. If you try to copy metabase.xml from one machine to another, it will not work immediately because the other machine Accounts on a machine use different names. Also, you can't just use xcopy /o to copy the ACL, because the SIDs are different on different machines. One workaround is to use a domain account, but you'll need to add an Active Directory to your schema. The IIS_WPG group also has the same permissions problem. If you set an ACL for the IIS_WPG group on the file system of one machine, using xcopy /o to copy the ACL to another machine will not succeed. IIS understands this problem and has improved it by using built-in accounts and groups in IIS 7.0.
Built-in accounts and groups are guaranteed by the operating system, which guarantees a unique SID. IIS even goes one better and guarantees that new account names and group names are never localized. For example, no matter which language version of Windows you install, the IIS account name will always be IUSR, and the group name will always be IIS_IUSRS.
In summary, in IIS 7.0:
The IUSR built-in account replaces the IUSR_MachineName account
The IIS_IUSRS built-in group replaces the IIS_WPG group.
Because IUSR is a built-in account, it no longer requires a password. Logically you can think of it as the NETWORKSERVICE or LOCALSERVICE account. The IUSR account and IIS_IUSRS group will be further introduced in the following chapters.
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 be created and used only when installing the FTP server. If FTP is not installed, the account will never be created.
This built-in account does not require a password and will be used as the default user identity when anonymous authentication is enabled. If you take a look at the applicationHost.config file, you will find the following definition:
<anonymousAuthentication enabled="true" userName="IUSR" defaultLogonDomain="" />
This tells IIS to use the new built-in account for all anonymous authentication requests. The big advantage of doing this is that we can now:
* Set file system permissions for IUSR using Windows Explorer or many other command line tools
* No need to worry about the password of this account expiring
* Use xcopy /o to seamlessly copy files and their ownership and ACL information to different machines.
It is important to mention that the IUSR account is very similar to the LOCALSERVICE account in that it works anonymously on the network. NETWORKSERVICE and LOCALSYSTEM can work as machine, but IUSR does not because it is a privileged promotion. If you wish to have an anonymous account with network access, you will need to create a new user account and set the username and password manually, just like you previously set up anonymous authentication. To achieve this in IIS Manager, you can:
* Click the Start button, type "INetMgr.exe" and press Enter (if a prompt box pops up, press Continue to escalate permissions)
* Click the "+" button next to the machine name in Connection
* Double-click the site you want to manage in IIS Manager
* Double-click the Authentication item under the Feature Name heading
* Select Anonymous Authentication, click Edit under the Task title on the right, and the Specify Credentials dialog will pop up.
* Click on the Specific User option and then press the "Set" button
* Enter the desired user name and password, and press OK
to understand the new IIS_IUSRS group. As mentioned earlier, the IIS_IUSRS group is used to replace the IIS_WPG group. It already has access rights to all files and system resources, so if a The account is added to the group and it will work seamlessly as an application pool identity.
Because it works with built-in accounts, this built-in group can solve several xcopy deployment problems. If you set permissions for IIS_WPG on files (this is possible in IIS6) and try to copy those files to another Windows system, the site settings may be corrupted since the group SID is different on the different machines.
In IIS7, since the group SID is the same in all Longhorn systems. Using 'xcopy /o' preserves ACL and ownership information when you move files from one machine to another, making xcopy deployments much simpler!
The second request from customers is "Once we configure the application pool identity, we need IIS to make all the necessary changes for us." We accepted this comment and made this process even simpler in IIS7.0. When IIS starts a worker process, it needs to create a token for use by the process. Now, when we create this token, IIS will automatically add the IIS_IUSRS membership to the worker process token at runtime. This will allow the account to run as the application pool without being explicitly part of the IIS_IUSRS group. We believe this change will help you set up your system more easily and make your overall experience better.
If you want to disable this feature and manually add accounts to the IIS_IUSRS group, you can only use this feature by setting the manualGroupMembership value to true. Here is an example of how to set defaultAppPool to disable this feature:
<applicationPools>
<add name="DefaultAppPool">
<processModel manualGroupMembership="true" />
</add>
</applicationPools>