IIS7对于以往是革命性的改变, 不再是以前缝缝补补的破衣裳, 全部重写的代码带来了更为优秀的性能与扩展能力. 他不再是一个Web Server了而变成了一个Application Server能够承载一切以通讯为基础的应用. 新的变革也带来了新的知识, 想更好的驾驭IIS7权限则是最基础的一部分也是最先需要了解的一部分. 本文让你初步了解IIS7的权限应用的基本相关知识, 了解来龙去脉不会再因应用程序突然多出一个莫名其妙权限而感到困惑. 虽然下面的内容均以Web服务为例, 但道理同样适用于以IIS7宿主的其他应用如FTP等等.

工作进程(Worker Process)

Worker Process是IIS应用程序的宿主, 在任务管理器中可以看到每一个Worker Process就是一个w3wp.exe.

WindowsLiveWriter-429641856/supfiles195C5D69/image7.png" target="_blank">

是Worker Process运行时的身份:

这里并没有提供一个直接的手段来设置Worker Process在什么身份标识下运行, 而是通过Application Pool的身份标识设定来实现的.

应用程序池(Application Pool)

Application Pool包含至少一个或多个Worker Process(Web Garden模式). 在运行时会将Application Pool的身份注入到Worker Process中, 就会以Application Pool的身份运行. 可以认为Application Pool与其包含的Worker Process的运行身份是一致的.

是Application Pool运行时的身份:

虚拟帐户 Application Pool Identity

上面提到的身份标识选项中你可以选择他, 但他只是一个统称, 并不存在实际的这个命名. 他依赖你的Application Pool的名称, 例如我的Application Pool名字叫做: SimonwAppPool, 那么这个虚拟标识的全名是: IIS AppPool\SimonwAppPool 运行在此Application Pool下的Worker Process从任务管理器中可以看到w3wp.exe是在SimonwAppPool这个用户下运行的. 可以在文件系统中对这个帐户分配权限. 这么做的好处是能够将能够将权限分离开来做粒度更细的配置, 不像是NetworkService有很多应用基于此, 设置一个权限影响一大片.

不过有时候通过UI找不到这个对象大约是个Bug, 通过命令行icacls处理即可.

什么是impersonate

这可能是一个让人容易迷糊的词汇impersonate - 扮演, 装扮. 他是指在某个特定的时刻以一个新的身份来代替已有身份来运行应用程序. 一个请求来临时在IIS处理管道中, 在authentication之前authenticated user的上下文是未知的, 这时你的应用程序以WPI的权限在运行. 在authentication之后authenticated user的上下文被建立, 但依然没有去扮演, 直至请求被映射到他的handler也就是handler mapping后应用程序开始使用扮演则将默认的WPI权限替换为authenticated user的权限来执行应用程序.

举个例子, php配置fastcgi时推荐设置fcgi.impersonate=true, 体现在请求一个php文件时
false: 始终使用WPI的权限, 默认权限是NetworkService
true: 使用authenticated user, 默认为IUSR, 也就是说可以让在站点级别上设置的权限生效.

用户组与用户

在IIS7下需要注意2个特殊的用户和用户组, 在IIS6中有着类似的对应关系
IIS6:IIS_WPG - IIS7:IIS_IUSRS
IIS6:IUSR_MachineName - IIS7:IUSR

最大的改变就是他们都成为了系统内置帐户(built-in account)有着统一的SID, 这样的好处在于做不同机器/系统间的拷贝时可以连带权限一同拷贝过去了, 在以往因为SID不同换了机器权限是无法有效拷贝的只能挨个手动设置, 现在方便多了.

IIS_IUSRS组