Sharepoint的处理IIS(Process)与账户处理模型

[转http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/06/2544118.html]

Sharepoint210有四种执行模型:

  1、完全信任执行模型(Full Trust)

  2、Bin/CAS 执行模型 （1与2都属于场解决方案）

  3、沙盒执行模型(Sand Box)

  4、 混合执行方法（Hybrid Approach）

 Sharepoint最简单的处理模型就是一个完整的Asp.net应用程序处理模型，但由于Sharepoint2010中引入了沙盒处理方式，所以使得处理场景变得复杂。

   这里我们从一个Http请求开始,来看看Sharepoint的处理过程以及其执行信任模型。

 一、由HTTP.SYS到对应的应用程序池(Application Pool)

   当一个Http请求(Http Request)到达Sharepoint的前端 Web 服务器（Front-End Web Server）时，前端 Web 服务器（Front-End Web Server）上的HTTP.SYS就会侦测到有Http Request到来,于是对其进行分析判断，看看这个Request请求的是哪个网站 (Website)，这个网站 (Website)运行在哪个应用程序池(Application Pool)中，并把它提交到对应的应用程序池(Application Pool)，如下图:

   HTTP.SYS是Web服务器上用于接收Http请求的侦听器, 它是一个位于Windows中的操作系统核心组件，能够让任何应用程序通过它提供的接口，以http协议进行信息通讯。从外部来的所有的Http服务请求会在Http.sys里暂存入队列，即使服务程序重启，尚未被处理的请求也不会丢失.

二、Http Request被应用程序池内的IIS工作进程(W3WP)接管并处理

   当Http Request到达了应用程序池，便交IIS工作进程(Worker Process)继续处理。

   IIS工作进程(W3WP) 是IIS应用程序的宿主, 我们在任务管理器中可以查看到它。

        

     它的主要任务就是对到来的HttpRequest进行处理，处理内容包括对Request的Session, ViewState,Cache的维护以及Request所请求的各种资源的分配等等。

2.1.1 IIS工作进程(W3WP)的创建

    W3WP这个工作进程是由Windows Activation Service (WAS: Windows 进程激活服务)进行创建并管理的，Windows 进程激活服务管理的不仅是W3WP，它还负责管理应用程序池的配置(application pool configuration)以及与Http或与其它协议(protocol)相关的工作进程(Worker Process)的创建与生命周期的管理。

       

     所以，当有Http请求(Http Request)进入时，WAS就会创建一个W3WP工作进程。但当你关闭了web网页,由于http是无连接的访问,它不会返回相应的关闭信息,所以W3WP这个进程不会因为你关闭了web应用程序尔关闭。但系统在应用程序池的配置中,默认的是20分钟，你也可以设定你指定的时间,那么在这个时间范围内没有在访问应用程序,那么系统会自动的关闭w3wp这个进程.而不需要我们人为的干预。

2.1.2关于应用程序池

     我们可以把应用程序池看成一个容器。它是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔，所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响

2.1.3 应用程序池与W3WP的关系

     对于 IIS，可能存在若干个应用程序池，而通常每个应用程序池都会创建一个 W3WP进程。 但是， 并不是所有情况都是一个应用程序池对应一个 W3WP进程。 Web Garden ， 或者一些异常发生时候，就会一个 应用程序池对应多个 W3WP进程。

     Web Garden 指的是一个应用程序可以在多个进程(w3wp)中来执行，一次请求使用其中的一个。用这个的主要目的是提高程序的可用性。当其中一个进程发生错误，那么也不会影响其他进程。发生错误的进程可以根据规则关闭，而其他的进程则可以继续工作。

     而至于异常，则是指由于应用程序池会在没有请求的时候定时回收，但在发生错误的时候，会自动重新建立一个处理进程( W3WP进程)

2.1.4 W3WP工作进程标识(Worker Process Identity - WPI)

     在W3WP工作进程运行时需要有明确的身份，这个身份就叫作工作进程标识(Worker Process Identity - WPI) 。服务器并没有提供一个直接的手段来设置工作进程在什么身份标识下运行, 而是通过应用程序池的身份标识设定来实现的.

     在IIS6, Windows 2008 IIS7下, 默认关联权限是NetworkService.

     在Windows 2008 R2 IIS7.5下, 默认是关联权限是Application Pool Identity（应用程序池标识帐户）. 在稍后我们还要具体说明。

     在运行时IIS会将应用程序池(Application Pool)的身份(即: 应用程序池标识API)注入到Worker Process中, 就会以应用程序池的身份运行. 可以认为应用程序池与其包含的Worker Process的运行身份是一致的。

2.1.5 应用程序池标识(Application Pool Identity -API)

    前面提到了应用程序池标识,应用程序池标识是运行应用程序池的工作进程所使用的服务帐户名称。

    在IIS6, Windows 2008 IIS7下, 应用程序池标识默认关联权限是NetworkService.

    在Windows 2008 R2 IIS7.5下, 应用程序池默认是关联权限是Application Pool Identity.

    需要特别注意的是，这里的Application Pool Identity是指的应用程序池标识帐户，它属于应用程序池标识(Application Pool Identity -API)的关联帐户的一种，虽然它们的英文拼写一样，但却是不同的两个概念，即一个是指的标识，一个是指的帐户，我们可以从Application Pool的Advanced Setting中看到下图, 从此图中我们可以看到二者的区别。

     从上图我们可以看出，应用程序池标识(API)可以设置为许多类型的帐户(Local Service, Local System, NetworkService, 应用程序池标识帐户<Application Pool Identity> 以及 用户自定义帐户)。

   2.1.6 W3WP的服务帐户(Service Account)

    服务帐户(Service Account)是Windows服务器为运行于其上的程序提供的帐户，它的作用就是通过提供安全上下文(Security Context)来为访问者提供在本系统中有效的安全属性或规则集合。我们既可以在Active Directory下创建基于域的Service Account，也可以在本机创建基于本地的Service Account。

2.1.7应用程序池帐户(Application Pool Account)

    IIS中的W3WP进程也和其它所有程序或进程一样，必须在特定的Service Account下运行，这个Service Account就是应用程序池帐户(Application Pool Account)。当你在IIS中创建一个应用程序池时，Windows 进程激活服务(WAS)就会自动为你创建一个应用程序池帐户(Application Pool Account)，这个帐户通常是Sharepoint服务器场帐户，因此该进程(W3WP)具有 SharePoint 资源的读写权限。在多服务器服务器场上，服务器场帐户通常是域用户(Domain User)。该帐户是访问内容数据库(Content Database)的同一帐户

    所以，从上面的描述我们可以看出应用程序池帐户(Application Pool Account)其实就是我们前面讲到的W3WP工作进程标识(Worker Process Identity - WPI)与应用程序池标识(Application Pool Identity -API)所关联的帐户。它只是网上不同的文章从不同的角度抽象出的这个概念而已。换句话说，应用程序池帐户(Application Pool Account)就是应用程序池标识(Application Pool Identity -API)或W3WP工作进程标识(Worker Process Identity - WPI)所关联的帐户，它们都属于服务帐户(Service Account)。

我们前面提到，在IIS7.5中(仅win7,win2008 SP2,win2008 R2支持)，应用程序池的运行帐户(Application Pool Account)，除了指定为LocalService,LocalSystem,NetWorkService这三种内置帐户外，还新增了一种ApplicationPoolIdentify(应用程序池标识帐户)，下面分别说明这些内置帐户:

• ApplicationPoolIdentity帐户(应用程序池标识帐户) : IIS7.5在默认情况下，选择"应用程序池标识"帐户。此帐户对于您的应用程序来说是最安全的，因为这个账户的权限很低， 只属于 IIS_IUSRS 用户组 ，ApplicationPoolIdentity 这个帐户是一个"虚拟"帐户，说它是虚拟的，是因为在用户管理里看不到该用户或用户组，在命令行下输入net user也无法显示，但该帐号又是确实存在的。事实上Application Pool Identity只是一个统称, 并不存在实际的这个命名. 他依赖你的Application Pool的名称, 例如有一个Application Pool名字叫做: DefaultAppPool, 那么这个虚拟标识的全名是: IIS AppPool\ DefaultAppPool运行在此Application Pool下的Worker Process从任务管理器中可以看到w3wp是在DefaultAppPool这个用户下运行的.

  

   

  你可以在文件系统中对这个帐户分配权限. 这么做的好处是能够将权限分离开来做粒度更细的配置, 不像是NetworkService有很多应用基于此, 设置一个权限影响一大片。如果你的程序需要访问本地文件系统 （比如日志输出） ， 就需要为 ApplicationPoolIdentity 账户设置 NTFS 权限， 这个账户在安全对话框是找不到的， 只能手工输入 IIS APPPOOL\{app pool name} 进行设置。

• LocalService "本地服务"帐户是用户组的成员之一，它拥有与"网络服务"帐户(NetworkService)相同的用户权限，但仅限于在本地计算机上使用。当应用程序池中的工作进程不需要访问它所运行在的 Web 服务器以外的内容时，可以使用此帐户。
• LocalSystem "本地系统"帐户拥有所有用户权限，它是 Web 服务器上的管理员组的成员之一。Local System 帐户是一个有权访问整个系统（包括域控制器上的目录服务）的功能强大的帐户。如果某个服务登录到域控制器上的 Local System 帐户，则该服务有权访问整个域。默认情况下，某些服务将配置为登录到 Local System 帐户。不要更改默认的服务设置。应尽可能避免使用"本地系统"帐户，因为它会给 Web 服务器带来更严重的安全风险。
• NetworkService "网络服务" 帐户是用户组的成员之一，并拥有运行应用程序所需的用户权限。通过使用计算机帐户的凭据，它可以在整个基于 Active Directory 的网络上进行交互。 在IIS 6.0 与IIS 7 中，工作进程默认运行于此类型，它是Window内建的Identity。它不需要密码并且仅拥有用户权限。

     应用程序池帐户(Application Pool Account)设置好后，会被自动加入到Sharepoint Farm内的每个服务器(Server)上的WSS_WPG、WSS_ADMIN_WPG或IIS_USERS这三个组的成员(Member)中，或者换过来说，这三个组都拥有应用程序池帐户（Application Pool Account）。

    下面分别看看Sharepoint Farm内的这三个组:

      WSS_WPG组具有对本地资源的读取访问权限，除了Application Pool Account它还拥有LOCAL SERVICE, NETWORK SERVICE （如果Application Pool Account使用的不是它们）等帐户。

      WSS_ADMIN_WPG 组也具有对本地资源的读取访问权限,除了拥有Application Pool Account，它还拥有 Builtin\Administrators, NETWORK SERVICE, Sharepoint Farm admin以及Timer services等帐户

      IIS_IUSRS Group 组:这是IIS7的内置组，用于代替IIS6中的IIS_WPG 组。默认它会拥有适当的权限来运行Worker Process. 所有的工作进程标识(Worker Process Identity - WPI)下的运行帐户均被隐式的自动加入到这个组中, 以获得最小的运行权限. 例如当你将MyAppPool这个Application Pool的运行身份设置为Application Pool Identity, 那么IIS AppPool\MyAppPool这个用户会被自动加入到IIS_IUSRS组中拥有他的全部权限. 因此对此组权限赋值需很小心很容易不知不觉中影响一大片.同时在IIS7中，它还使用内置的IUSER帐户来代替以前IIS6中的IUSR_MachineName帐户。IUSR是一个匿名帐户，虽然它是一个匿名帐户并且没有密码, 但他属于authenticated users ,而authenticated users属于Users组, 因此IUSR默认具备了Users组的权限

  

    在SQL Server数据库方面，应用程序池帐户(Application Pool Account)还需要以下权限配置设置

     1.为 Web 应用程序的应用程序池帐户分配内容数据库(content database)的 db_owner 角色。

     2.为此帐户分配与服务器场配置数据库关联的 WSS_CONTENT_APPLICATION_POOLS 角色。

     3.为此帐户分配与 SharePoint_Admin 内容数据库关联的 WSS_CONTENT_APPLICATION_POOLS 角色。

     此外，应用程序池帐户（Application Pool Account）还有别于服务器场管理员帐户(Farm Administration Account)，后者除了前者所属的WSS_WPG、WSS_ADMIN_WPG、IIS_USERS这三个组外，还包含在WSS_RESTRICTED_WPG_V4以及Performance Monitor User这两个组中。

     但应用程序池帐户也有例外，如： SharePoint 管理中心网站(Central Administration Web Site)的应用程序池标识所用帐户与Windows SharePoint Services 定时服务的进程帐户"不是"应用程序池帐户（Application Pool Account），而是服务器场帐户，此帐户也称为数据库访问帐。

     简单总结：SharePoint 是一个 ASP.NET 应用程序，它与 ASP.NET 应用程序类似，当前端 Web 服务器收到某个 HTTP 请求时，特殊的驱动程序（即 HTTP.SYS）将检测该请求，并将其路由到处理目标 IIS 网站和目标 SharePoint Web 应用程序的请求的应用程序池。每个应用程序池均有一个 IIS 工作进程 (w3wp.exe)用于执行每个请求的请求管道，此工作进程需要设置应用程序池帐户(Application Pool Account, 这通常是服务器场帐户，因此该进程具有 SharePoint 资源的读写权限。在多服务器服务器场上，服务器场帐户通常是域用户。该帐户是访问内容数据库的同一帐户)，而应用程序池帐户可以设置为LocalService,LocalSystem,NetWorkService以及 ApplicationPoolIdentify这些内置帐户，也可以设置用户自定义帐户，然后Sharepoint会把这个帐户设置到Farm内每个服务器上的WSS_WPG、WSS_ADMIN_WPG或IIS_USERS这三个组中，同时应用程序池帐户还会具备SQL Server数据库方面的权限以访问Sharepoint的数据库内容(eg:Content Database)。

     进入IIS 工作进程(IIS Worker Process)的阶段是Sharepoint的四种执行模型都必须经过的处理阶段。场解决方案与任何 ASP.NET 应用程序一样是在 IIS 工作进程(w3wp)中运行。而沙盒解决方案却在具有特殊限制的执行环境中运行(这对于阻止未授权或性能不佳的代码减慢应用程序池的速度或导致应用程序池发生崩溃很重要。因此，SharePoint 将对可在沙盒解决方案中执行的代码施加限制)。当请求尝试访问沙盒解决方案时，IIS 工作进程(w3wp)将会把工作交给在它内部运行的 SharePoint 执行管理器(Execution Manager)，由执行管理器(Execution Manager)负责查找沙盒工作进程(SPUCWorkerProcess.exe)（如果未运行任何沙盒工作进程，则启动一个沙盒工作进程）。沙盒工作进程就是负责运行沙盒解决方案代码的进程。