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的前端網頁伺服器（Front-End Web Server）時，前端網頁伺服器（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 服務器上的Administrator 群組的成員之一。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 應用程式類似，當前端網頁伺服器收到某個 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)（如果未運行任何沙箱背景工作處理序，則啟動一個沙箱背景工作處理序）。沙箱背景工作處理序就是負責運行沙箱化解決方案代碼的進程。