在早期的IIS版本中如IIS6.0，随着IIS的安装，系统会创建一个IUSR_MachineName用户。IIS启用匿名访问，就是通过此用户进行身份认证的，包括FTP匿名访问，HTTP匿名访问。

 

在创建IUSR_MachineName用户的同时，IIS_WPG用户组也会被创建出来。此用户组是一个包含所有预定义应用程序池标识用户的容器。在安装IIS的时候，系统里所有IIS需要用到的资源都被授予IIS_WPG用户组适当的权限。因此，当管理员为应用程序池标识为一个新创建的用户时，只需将该用户加入IIS_WPG用户组，即可保证应用程序池正常工作。

 

在这样的架构下，IIS可以很好地工作，但也有其不足之处：IUSR_MachineName用户和IIS_WPG用户组都是本地系统里的用户（组），同系统中的其他用户（组）一样，都有各自的唯一安全标识符SID。IIS的配置文件metabase.xml有调用IUSR_MachineName用户。由于此用户在其他计算机上有着不同的SID及名称，所以当我们把metabase.xml复制到其他计算机上时，IIS将无法正常工作。

 

另外，也正是由于SID的缘故，我们无法将IUSR_MachineName用户相关的ACL成功复制到其他计算机上。IIS_WPG用户组也一样。

 

IIS 7成功解决了这两个问题。

 

IIS 7的内置用户（组）突破了SID的限制，因为IIS7在调用这些内置用户（组）时，使用的是用户名而非SID。而且在不同语言版本的系统中，IIS 7的内置用户（组）都是IUSR（IIS_IUSRS）。其中，IUSR用于取代IUSR_MachineName，IIS_IUSRS用于取代IIS_WPG。

 

由于IUSR属于内置用户，所以使用时，不需要输入密码。你可以把它理解为NETWORK SERVICE或LOCAL SERVICE一类的用户。下面具体讲一下IUSR和IIS_IUSRS。

 

 

在IIS 7中，IUSR用户取代了IUSR_MachineName用户。IUSR在认证时不需要密码。IIS 7的匿名身份认证，就是通过此用户进行的。打开IIS 7配置文件applicationHost.config ，可以看到这样一段设置：

 

 

这表明IIS 7是通过IUSR来实现所有的匿名访问。这样一来，你就可以：

 

通过Explorer或cmd来设置IUSR的权限；
不用担心IUSR密码过期的问题；
将IUSR相关的ACL无缝迁移至其他计算机上。

 

当然，我们也可以将IIS 7的匿名身份标识为成其他用户：

 

1、打开IIS Manager，双击你想要设置的站点。
2、在功能视图中，双击身份验证。
3、选择匿名身份验证，点击编辑。
4、点击特定用户，设置。
5、输入该用户的用户名密码，确定。

 

 

IIS_IUSRS用户组取代了IIS_WPG用户组。此内置用户组拥有应用程序池访问系统资源所需的足够权限。因此，任何加入此用户组的用户，都可以成为一个合格的应用程序池标识用户。

 

和IUSR用户一样，IIS_IUSRS用户组也可以实现不同计算机之间的ACL复制。

 

当IIS启动工作进程时，需要用户来标识进程，而IIS_IUSRS用户组成员ApplicationPoolIdentity就是默认的标识。

 

ApplicationPoolIdentity并不是指一个用户，而是所有程序池默认标识用户的统称。这些用户与程序池是一一对应的。例如，程序池DefaultAppPool的ApplicationPoolIdentity是用IISAPPPOOL\DefaultAppPool。

 

因此，有了IIS_IUSRS用户组，管理应用程序池标识就变得简单多了，至少你不需要再为不同程序池下的站点设置不同的程序池标识用户权限。

关键字：IUSR、IIS_IUSRS 、IIS