在 SharePoint Server 中規劃使用者驗證方法

  • 發行項

 

**適用版本：**SharePoint Server 2013, SharePoint Server 2016

**上次修改主題的時間：**2017-06-21

**摘要：**規劃如何使用各種使用者驗證方法，為 SharePoint Server 2013 和 SharePoint Server 2016 中的 Web 應用程式使用者建立安全體驗。

了解 SharePoint Server 所支援的使用者驗證類型和方法，以及如何決定 Web 應用程式和區域所使用的驗證類型和方法。

本文內容：

  • 簡介

  • 宣告式驗證

  • 支援的驗證類型和方法

  • 規劃 Windows 驗證

  • 規劃表單型驗證

  • 規劃 SAML 權杖型驗證

  • 規劃 Web 應用程式的區域

簡介

使用者驗證是根據驗證提供者對使用者身分識別進行的驗證，驗證提供者是包含使用者認證並可確認使用者正確提交認證的目錄或資料庫，例如 Active Directory 網域服務 (AD DS)。其他驗證提供者的專有名詞還包括使用者目錄和屬性存放區。

驗證方法是帳戶認證與宣告使用者身分識別之其他資訊的特定交換。驗證方法的結果是驗證提供者驗證使用者的證明，通常使用包含宣告的權杖格式。

驗證類型是根據一或多個驗證提供者驗證認證的特定方式，有時會使用業界標準通訊協定。一種驗證類型可以使用多種驗證方法。

確認使用者身分識別之後，授權程序即可決定使用者所能存取的網站、內容及其他功能。

規劃使用者驗證類型和方法時應該決定下列事項：

  • 每個 Web 應用程式和區域的使用者驗證類型和方法

  • 支援決定使用之驗證類型和方法所需的驗證基礎結構

    注意

    SharePoint Server 2016 不再支援 Windows 傳統模式驗證。

宣告式驗證

AD DS 的使用者身分識別是以使用者帳戶為基礎。為了能順利驗證，使用者需要提供帳戶名稱及知道密碼的證明。若要確定資源的存取權，應用程式可能必須查詢 AD DS 以取得帳戶屬性及其他資訊，例如網路上的群組成員資格或角色。雖然此作法適用於 Windows 環境，但是不會向外延展至協力廠商驗證提供者，以及支援網際網路、合作夥伴或雲端架構運算模型的多廠商環境。

透過宣告式身分識別，使用者可以從一般信任的身分識別提供者取得數位簽署的安全性權杖。此權杖包含一組宣告。每個宣告代表有關使用者的特定資料項目，例如使用者的名稱、群組成員資格及網路上的角色。宣告式驗證是使用宣告式身分識別技術和基礎結構的使用者驗證。支援宣告式驗證的應用程式可從使用者取得安全性權杖 (而不是認證)，並使用宣告中的資訊來決定資源存取權。不需要目錄服務 (例如 AD DS) 的個別查詢。

Windows 宣告式驗證是根據 Windows Identity Foundation (WIF，一組用來實作宣告式身分識別的 .NET Framework 類別) 所建立。宣告式驗證需依賴一些標準 (例如 WS-同盟、WS-Trust) 及通訊協定 (例如安全性聲明標記語言 (SAML))。

如需宣告式驗證的詳細資訊，請參閱下列資源：

由於宣告式驗證廣泛用於使用者驗證、伺服器對伺服器驗證及應用程式驗證，因此建議針對 SharePoint Server 伺服器陣列的所有 Web 應用程式和區域使用宣告式驗證。如需詳細資訊，請參閱＜在 SharePoint Server 中規劃伺服器對伺服器的驗證＞。當您使用宣告式驗證時，Web 應用程式可使用所有支援的驗證方法，且您可以利用 SharePoint Server 中使用伺服器對伺服器驗證及應用程式驗證的新功能和案例。

針對宣告式驗證，SharePoint Server 會自動將所有使用者帳戶變更成宣告身分識別。這會為每位使用者產生安全性權杖 (又稱為宣告權杖)。宣告權杖中包含關於使用者的宣告。Windows 帳戶將轉換成 Windows 宣告。表單型成員資格使用者則轉換成表單型驗證宣告。SharePoint Server 可以使用 SAML 型權杖中的宣告。此外，SharePoint 開發人員及管理員可加入其他宣告以增強使用者權杖。例如，加入其他 SharePoint Server 使用的宣告可增強 Windows 使用者帳戶及表單型帳戶。

您不必是宣告架構師，也能在 SharePoint Server 中使用宣告式驗證。但是，實作 SAML 權杖型驗證時，您需與宣告式環境的管理員協調，如規劃 SAML 權杖型驗證所述。

SharePoint Server 2013 中的傳統模式驗證

在 SharePoint 2013 中，當您在管理中心中建立 Web 應用程式時，您只能指定宣告式驗證的驗證類型和方法。在舊版 SharePoint 中，您也可以在管理中心中設定 Web 應用程式使用傳統模式驗證。傳統模式驗證使用 Windows 驗證，且 SharePoint 2013 會將使用者帳戶視為 AD DS 帳戶。

若要設定 Web 應用程式使用傳統模式驗證，您必須使用 New-SPWebApplication PowerShell Cmdlet 建立 Web 應用程式。設定為使用傳統模式驗證的 SharePoint 2010 產品 Web 應用程式會在升級為 SharePoint 2013 之後保留其驗證設定。但是，建議您將 Web 應用程式移轉至宣告式驗證，再升級為 SharePoint 2013。

SharePoint 2013 伺服器陣列可以包含使用兩種模式之 Web 應用程式的組合。某些服務不會區分使用者帳戶屬於傳統 Windows 帳戶或 Windows 宣告帳戶。

如需移轉再升級的詳細資訊，請參閱＜從傳統模式移轉至宣告式驗證＞。

如需升級再移轉的詳細資訊，請參閱＜在 SharePoint 2013 中從傳統模式移轉至宣告式驗證＞。

如需如何在 SharePoint 2013 中建立使用傳統模式驗證之 Web 應用程式的資訊，請參閱＜在 SharePoint 2013 中建立使用傳統模式驗證的 Web 應用程式＞。請注意，您無法將使用宣告式驗證的 Web 應用程式移轉至使用傳統模式驗證。

重要

只有使用宣告式驗證的 SharePoint 2013 Web 應用程式才能使用 Office Online。在使用傳統模式驗證的 SharePoint 2013 Web 應用程式上，Office Online 的轉譯和編輯無法運作。若您將使用傳統模式驗證的 SharePoint 2010 Web 應用程式移轉至 SharePoint 2013，就必須將這些應用程式移轉至宣告式驗證以允許其搭配 Office Online 使用。

支援的驗證類型和方法

SharePoint Server 支援下列驗證類型的各種驗證方法及驗證提供者：

  • Windows 驗證

  • 表單型驗證

  • SAML 權杖型驗證

Windows 驗證

Windows 驗證類型利用現有的 Windows 驗證提供者 (AD DS) 及 Windows 網域環境用來驗證連線用戶端之認證的驗證通訊協定。宣告式驗證所使用的 Windows 驗證方法如下：

  • NTLM

  • Kerberos

  • 摘要

  • 基本

如需詳細資訊，請參閱本文中的＜規劃 Windows 驗證＞。

觀看 SharePoint 2013 和 SharePoint Server 2016 中的 Windows 宣告驗證影片

SharePoint Server 也支援匿名驗證，不過這不是 Windows 驗證類型。使用者不需驗證其認證，就能存取 SharePoint 內容。預設會停用匿名驗證。當您使用 SharePoint Server 發佈不需要安全性且提供給所有使用者的內容時 (例如公用網際網路網站)，一般會使用匿名驗證。

請注意，除了啟用匿名驗證之外，您也必須設定網站和網站資源上的匿名存取 (權限)。

注意

由 SharePoint 所建立可服務 Web 應用程式的 Internet Information Services (IIS) 網站，一律會啟用匿名驗證和表單驗證方法，即使已停用匿名驗證和表單驗證的 SharePoint 設定時也是一樣。這是故意的，而直接在 IIS 設定中停用匿名驗證或表單驗證會導致 SharePoint 網站發生錯誤。

表單型驗證

表單型驗證 (FBA) 是宣告式身分識別管理系統，以 ASP.NET 成員資格與角色提供者驗證為基礎。您可以對儲存在下列驗證提供者的認證使用宣告式驗證：

  • AD DS

  • 資料庫 (例如 SQL Server 資料庫)

  • 輕量型目錄存取通訊協定 (LDAP) 資料存放區 (例如 Novell eDirectory、Novell Directory Services (NDS) 或 Sun ONE)

表單型驗證會根據使用者以登入表單形式 (通常為網頁) 輸入的認證來驗證使用者。未經驗證的要求會重新導向至登入頁面，使用者必須在該頁面提供有效認證再送出表單。系統會發出驗證要求的 Cookie，包含用於重新建立後續要求之身分識別的金鑰。

觀看 SharePoint 2013 和 SharePoint Server 2016 中的表單型宣告驗證影片

注意

若是表單型驗證，則會以純文字形式傳送使用者帳戶認證。因此，除非您同時使用安全通訊端階層 (SSL) 加密網站流量，否則不應使用表單型驗證。

如需詳細資訊，請參閱＜規劃表單型驗證＞。

SAML 權杖型驗證

SharePoint Server 的 SAML 權杖型驗證使用 SAML 1.1 通訊協定和 WS-同盟被動式要求者設定檔 (WS-F PRP)，需與宣告式環境 (無論是貴組織本身內部環境或是合作夥伴環境) 的管理員進行協調。如果使用 Active Directory Federation Services (AD FS) 2.0，則會具有 SAML 權杖型驗證環境。

SAML 權杖型驗證環境中包含一個身分識別提供者 Security Token Service (IP-STS)。IP-STS 會代表帳戶包含在相關聯驗證提供者中的使用者發行 SAML 權杖。在權杖中，可包括關於使用者 (例如，使用者名稱及使用者所屬群組) 的任意數目宣告。AD FS 2.0 伺服器即為 IP-STS 的一例。

SharePoint Server 利用 IP-STS 發給授權使用者之權杖內的宣告。在宣告環境中，凡是接受 SAML 權杖的應用程式稱之為信賴憑證者 STS (RP-STS)。信賴憑證者應用程式在接收 SAML 權杖後，會使用其中所含的宣告來決定是否要授與用戶端存取所要求資源的權限。在 SharePoint Server 中，每個設為使用 SAML 提供者的 Web 應用程式，就會當成個別 RP-STS 項目新增至 IP-STS 伺服器中。SharePoint 伺服器陣列可代表 IP-STS 中的多個 RP-STS 項目。

觀看 SharePoint 2013 和 SharePoint Server 2016 中的 SAML 型宣告驗證影片

SAML 權杖型驗證的一組驗證提供者取決於宣告環境中的 IP-STS。如果使用 AD FS 2.0，驗證提供者 (又稱為 AD FS 2.0 的屬性存放區) 包括：

  • Windows Server 2003 Active Directory 和 Windows Server 2008 的 AD DS

  • 所有版本的 SQL Server 2005 和 SQL Server 2008

  • 自訂屬性存放區

如需詳細資訊，請參閱＜規劃 SAML 權杖型驗證＞。

選擇 LDAP 環境的驗證類型

表單型驗證或 SAML 權杖型驗證可以使用 LDAP 環境。您應該使用配合目前 LDAP 環境的驗證類型。如果目前沒有 LDAP 環境，建議您使用表單型驗證，因為這種驗證複雜性較低。不過，如果驗證環境已支援 WS-同盟 1.1 及 SAML 1.1，則建議使用 SAML。SharePoint Server 具有內建 LDAP 提供者。

規劃 Windows 驗證

規劃及實作用於宣告式驗證之 Windows 驗證方法的程序類似。為 Web 應用程式選擇宣告式驗證並不會使實作 Windows 驗證方法變得更複雜。本節摘要說明如何規劃 Windows 驗證方法。

NTLM 和 Kerberos 通訊協定

NTLM 和 Kerberos 通訊協定都是整合式 Windows 驗證方法，這兩種方法可讓使用者無縫地進行驗證，而不需經由提示要求認證。例如：

  • 使用者若從 Internet Explorer 存取 SharePoint 網站，將使用執行 Internet Explorer 程序所用的認證，進行驗證。根據預設，這些認證即是使用者用於登入電腦的認證。

  • 使用整合式 Windows 驗證方法存取 SharePoint 資源的服務或應用程式，會嘗試使用執行中之執行緒的認證 (根據預設，此即是該程序的身分識別) 進行驗證。

NTLM 是最容易實作的 Windows 驗證方法，通常不需要驗證基礎結構的任何其他設定。只要在建立或設定 Web 應用程式時，選取此選項即可。

Kerberos 通訊協定支援票證驗證。使用 Kerberos 通訊協定需對環境進行額外設定。若要啟用 Kerberos 驗證，用戶端與伺服器電腦必須擁有連至網域金鑰發佈中心 (KDC) 的信任連線。若要設定 Kerberos 通訊協定，您需在安裝 SharePoint Server 之前，先在 AD DS 中設定服務主要名稱 (SPN)。

您應該考慮使用 Kerberos 驗證的原因如下：

  • Kerberos 通訊協定是最強大的整合式 Windows 驗證通訊協定，而且支援進階安全性功能 (包括進階加密標準 (AES) 加密，以及用戶端和伺服器的相互驗證)。

  • Kerberos 通訊協定允許委派用戶端認證。

  • 在可用的安全驗證方法中，Kerberos 需要與 AD DS 網域控制站的最少網路流量。在特定情況下，Kerberos 可以減少頁面延遲，或是在特定情況下增加前端網頁伺服器可以提供的頁面數。Kerberos 也可以減少網域控制站的負載。

  • Kerberos 通訊協定是許多平台和廠商支援的開放式通訊協定。

Kerberos 驗證可能不適用的原因如下：

  • Kerberos 驗證比其他驗證方法需要更多基礎結構和環境的設定，才能正常運作。在許多情況下，需要有網域管理員權限，才能設定 Kerberos 通訊協定。Kerberos 驗證可能很難設定和管理。Kerberos 的設定錯誤可能會讓您的網站驗證失敗。

  • Kerberos 驗證需要 KDC 及 AD DS 網域控制站的用戶端電腦連線。在 Windows 部署中，KDC 是 AD DS 網域控制站。雖然這是組織內部網路常見的網路設定，但是網際網路對應部署一般不是以此方式進行設定。

下列步驟摘要說明如何設定 Kerberos 驗證：

  1. 為 SQL Server 服務帳戶在 AD DS 中建立 SPN，以設定 SQL Server 通訊所用的 Kerberos 驗證。

  2. 為將使用 Kerberos 驗證的 Web 應用程式建立 SPN。

  3. 安裝 SharePoint Server 伺服器陣列。

  4. 在該伺服器陣列中設定特定服務使用特定服務帳戶。

  5. 建立將使用 Kerberos 驗證的 Web 應用程式。

摘要及基本

若是摘要驗證方法，則會以 MD5 訊息摘要形式將使用者帳戶認證傳送至主控 Web 應用程式或區域之網頁伺服器上的 Internet Information Services (IIS) 服務。若是基本驗證方法，則會以純文字形式傳送使用者帳戶認證。因此，除非您同時使用 SSL 加密網站流量，否則不應使用基本驗證方法。

如果您的環境使用僅支援網站之摘要或基本驗證的網頁瀏覽器或服務，則可能必須使用這些較舊的驗證方法。

不像 NTLM、Kerberos 及匿名驗證方法，您會從對應至 Internet Information Services (IIS) 嵌入式管理單元中之 Web 應用程式或區域的網站內容設定摘要和基本驗證方法。

如果使用宣告式驗證，請參閱：

規劃表單型驗證

若在使用表單型驗證時，根據外部或不是以 Windows 為基礎的身分識別管理系統驗證使用者，則必須在 Web.config 檔案中登錄成員資格提供者及角色管理員。SharePoint Server 使用標準 ASP.NET 角色管理員介面，收集目前使用者的群組資訊。SharePoint Server 的授權程序會將每一個 ASP.NET 角色視為一個網域群組。在 Web.config 檔案登錄角色管理員的方法，與登錄用於驗證之成員資格提供者的方法完全相同。

若要從管理中心網站管理成員資格使用者或角色，您必須在 Web.config 檔案中為管理中心網站登錄成員資格提供者及角色管理員。您還必須在 Web.config 檔案中，為主控內容的 Web 應用程式登錄成員資格提供者及角色管理員。

如需設定表單型驗證的詳細步驟，請參閱＜在 SharePoint 2013 中設定宣告式 Web 應用程式的表單型驗證＞。

規劃 SAML 權杖型驗證

SAML 權杖型提供者的實作架構包括下列元件：

  • SharePoint Security Token Service   此服務會建立伺服器陣列所用的 SAML 權杖。此服務會在伺服器陣列的所有伺服器上自動建立並啟動。此服務用於伺服器陣列之間的通訊，因為所有伺服器陣列之間的通訊都是使用宣告式驗證。此服務還用於使用宣告式驗證之 Web 應用程式所實作的驗證方法，包括 Windows 驗證、表單型驗證及 SAML 權杖型驗證。

  • 權杖簽署憑證 (ImportTrustCertificate)   此憑證會從 IP-STS 匯出，然後再複製到伺服器陣列的一部伺服器上，並加入伺服器陣列的 [受信任的根授權單位] 清單。一旦您使用此憑證建立 SPTrustedIdentityTokenIssuer，就無法使用此憑證建立其他 SPTrustedIdentityTokenIssuer。若要使用此憑證建立不同 SPTrustedIdentityTokenIssuer，則必須先刪除現有的 SPTrustedIdentityTokenIssuer。在刪除現有的 SPTrustedIdentityTokenIssuer 之前，必須先從所有可能使用它的 Web 應用程式中解除彼此關聯。

  • 身分識別宣告   身分識別宣告是來自 SAML 權杖的宣告，它是使用者的唯一識別碼。只有 IP-STS 的擁有人才知道權杖中哪個值是每個使用者的唯一識別碼。在對應所有所需宣告期間，會建立身分識別宣告，作為一般宣告對應。作為身分識別宣告之用的宣告，是在建立 SPTrustedIdentityTokenIssuer 時宣告。

  • 其他宣告   這些宣告包括 SAML 票證中用以描述使用者的其他宣告，其中可包括使用者角色、使用者群組或其他種類的宣告，例如年齡。所有宣告對應都會建立成物件形式，並在 SharePoint Server 伺服器陣列的伺服器之間複寫。

  • 領域   在 SharePoint 宣告架構中，URI 或 URL 若與設為使用 SAML 權杖型提供者之 SharePoint Web 應用程式相關聯，即為領域。當在伺服器陣列上建立 SAML 型驗證提供者，您需指定 IP-STS 要辨識的領域，或 Web 應用程式 URL (一次指定一個)。第一個領域是在您建立 SPTrustedIdentityTokenIssuer 時指定。建立 SPTrustedIdentityTokenIssuer 之後即可新增更多領域。指定領域的語法類似下列語法：$realm = "urn:sharepoint:mysites"。對 SPTrustedIdentityTokenIssuer 新增領域之後，您必須對 IP-STS 伺服器上的領域識別碼建立 RP-STS 信任。此程序包含指定 Web 應用程式的 URL。

  • SPTrustedIdentityTokenIssuer   這個物件是建立在包含進行 IP-STS 通訊並從此通訊中接收權限所需之值的 SharePoint 伺服器陣列上。在建立 SPTrustedIdentityTokenIssuer 時，您需指定要使用的權杖簽署憑證、第一個領域、代表身分識別宣告的宣告，以及其他任何宣告。來自 STS 的權杖簽署憑證只能與一個 SPTrustedIdentityTokenIssuer 產生關聯。但是，建立 SPTrustedIdentityTokenIssuer 之後，您還是可以為其他 Web 應用程式新增更多領域。將領域新增至 SPTrustedIdentityTokenIssuer 之後，您還必須將它當成信賴憑證者新增至 IP-STS。SPTrustedIdentityTokenIssuer 物件會在 SharePoint Server 伺服器陣列的伺服器之間複寫。

  • 信賴憑證者 Security Token Service (RP-STS)   在 SharePoint Server 中，每個設為使用 SAML 提供者的 Web 應用程式都會當成 RP-STS 項目新增至 IP-STS 伺服器。SharePoint Server 伺服器陣列可包含多個 RP-STS 項目。

  • 身分識別提供者 Security Token Service (IP-STS)   宣告環境中的這個 Security Token Service 會代表相關使用者目錄中的使用者發行 SAML 權杖。

下圖顯示 SharePoint Server SAML 權杖宣告架構。

SAML 權杖宣告架構

SharePoint 宣告驗證元件

SPTrustedIdentityTokenIssuer 由多個參數所建立，其中包含以下參數：

  • 單一身分識別宣告。

  • 單一 SignInURL 參數。

    SignInURL 參數可指定將使用者要求重新導向的 URL，以對 IP-STS 進行驗證。

  • 單一 Wreply 參數。

    部分 IP-STS 伺服器會要求使用 Wreply 參數，而該參數可能設為 True 或 False；False 為預設值。只有當 IP-STS 要求 Wreply 參數時，再使用該參數。

  • 多個領域。

  • 多個宣告對應。

若要對 SharePoint Server 實作 SAML 權杖型驗證，請使用需事先規劃的下列步驟：

  1. 從 IP-STS 匯出權杖簽署憑證。將此憑證複製到 SharePoint Server 伺服器陣列中的伺服器。

  2. 定義要當成使用者唯一識別碼的宣告。此稱之為身分識別宣告。使用者主要名稱 (UPN) 或使用者電子郵件名稱經常會當成使用者識別碼。請與 IP-STS 管理員協調，以決定正確的識別碼，因為只有 IP-STS 的擁有人才知道權杖中哪個值是每個使用者的唯一識別碼。識別使用者的唯一識別碼是宣告對應程序的一個過程。請使用 Microsoft PowerShell 建立宣告對應。

  3. 定義其他宣告對應。定義 SharePoint Server 伺服器陣列將使用之其他來自傳入權杖的宣告。使用者角色是 SharePoint Server 伺服器陣列中可用來將權限指派給資源的宣告範例。所有來自傳入權杖的宣告若沒有對應，將遭捨棄。

  4. 使用 PowerShell 建立新的驗證提供者，以匯入權杖簽署憑證。此程序會建立 SPTrustedIdentityTokenIssuer。在此過程中，您需指定身分識別宣告及您對應的其他宣告。您還必須建立並指定領域，以與您為 SAML 權杖型驗證設定的第一個 SharePoint Web 應用程式相關聯。建立 SPTrustedIdentityTokenIssuer 之後，您可以建立並新增更多領域，以供其他 SharePoint Web 應用程式使用。這就是設定多個 Web 應用程式使用同一個 SPTrustedIdentityTokenIssuer 的作法。

  5. 對於新增至 SPTrustedIdentityTokenIssuer 的每一個領域，您必須在 IP-STS 上建立 RP-STS 項目。您可以在 SharePoint Web 應用程式存在之前完成此作業。無論如何，您必須在建立 Web 應用程式之前規劃 URL。

  6. 針對現有或新的 SharePoint Web 應用程式，將其設定為使用新建立的驗證提供者。當您建立 Web 應用程式時，驗證提供者會在管理中心中顯示為信任的身分識別提供者。

您可以設定多個 SAML 權杖型驗證提供者。但是，您只能在伺服器陣列中使用權杖簽署憑證一次。所有已設定的提供者都會顯示為管理中心的選項。來自不同受信任 STS 環境的宣告將不會產生衝突。

如果您對合作夥伴公司實作 SAML 權杖型驗證，且貴組織本身環境也包括 IP-STS，建議您與內部宣告環境的管理員一起建立內部 IP-STS 與合作夥伴 STS 之間的單向信任關係。這種作法不需要對您的 SharePoint Server 伺服器陣列新增驗證提供者，同時也可讓您的宣告管理員管理整個宣告環境。

重要

當您使用 SharePoint Server 的宣告式驗證時，不再需要將網路負載平衡設為單一相關性。

注意

若 Web 應用程式是設定為使用 SAML 權杖型驗證，SPTrustedClaimProvider 類別就不會提供「人員選擇」控制項搜尋功能。任何「人員選擇」控制項中輸入的文字不論其是否為有效的使用者、群組或宣告，在解析後都會自動顯示。若您的 SharePoint Server 解決方案使用 SAML 權杖型驗證，請規劃建立實作自訂搜尋及名稱解析的自訂宣告提供者。

如需使用 AD FS 設定 SAML 權杖型驗證的詳細步驟，請參閱＜在 SharePoint 2013 中使用 AD FS 設定 SAML 式宣告驗證＞。

規劃 Web 應用程式的區域

區域代表存取 Web 應用程式中同一個網站的不同邏輯路徑。每個 Web 應用程式最多可包含五個區域。當您建立 Web 應用程式時，管理中心會建立預設區域。若要建立其他區域，請擴充 Web 應用程式，並從其餘區域名稱中選取其中之一：內部網路、外部網路、網際網路或自訂。

請根據下列項目來規劃區域：

  • 宣告式驗證 (建議使用) - 您可以在單一區域上實作多個驗證提供者。您也可以使用多個區域。

在單一區域中實作多種驗證類型

如果使用的是宣告式驗證，並同時實作多種驗證方法，建議您在預設區域上實作多種驗證方法。結果是所有使用者使用相同 URL。

當在同一區域實作多種驗證方法時，將有下列限制：

  • 您只能在一個區域上實作一個表單型驗證的執行個體。

  • 管理中心需允許您同時使用整合式 Windows 方法及基本驗證，否則無法在同一區域上實作多種 Windows 驗證類型。

如果伺服器陣列設定了多個 SAML 權杖型驗證提供者，在您建立 Web 應用程式或新的區域時，這些提供者都會變成選項。您可以在相同區域上設定多個 SAML 提供者。

下圖顯示合作夥伴共同作業網站預設區域上所實作的多種驗證類型。

在預設區域執行多種驗證類型

某一區域上的多種驗證類型

在此圖中，來自不同目錄存放區的使用者使用相同 URL 存取合作夥伴網站。以虛線方框框住合作夥伴公司，表示使用者目錄與預設目錄所設定的驗證類型之間的關係。

規劃編目內容

編目元件需要 NTLM 存取內容。必須至少有一個區域設為使用 NTLM 驗證。如果預設區域並未設定 NTLM 驗證，編目元件可以使用其他設為使用 NTLM 驗證的區域。

實作多個區域

若要為 Web 應用程式實作多個區域，請使用下列準則：

  • 使用預設區域實作最安全的驗證設定。若某要求無法與特定區域相關聯，將會套用預設區域的驗證設定及其他安全性原則。預設區域是建立 Web 應用程式時所建立的區域。通常會針對使用者存取，設計最安全的驗證設定。因此，使用者可能會存取預設區域。

  • 使用能夠提供使用者存取所需的最少區域數目。每個區域都要與新 IIS 網站及網域產生關聯，以便存取 Web 應用程式。只有在需要新的存取點時才新增。

  • 請確定至少有一個區域設為使用 NTLM 驗證，以供編目元件使用。若非必要，請勿建立索引元件的專用區域。

下圖顯示實作多個區域，以滿足合作夥伴共同作業網站的多種驗證類型需求。

每種驗證類型一個區域

每種驗證類型一個區域

在此圖中，預設區域係供遠端員工使用。每個區域都有不同的相關聯 URL。員工視其位於辦公室工作或遠端工作，而使用不同區域。