在 SharePoint Server 中規劃使用者驗證方法
適用於：
2013 Subscription Edition 
SharePoint in Microsoft 365
注意事項
此處所述的使用者驗證方法適用於 SharePoint Server 2013、SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 訂閱版本。
了解 SharePoint Server 所支援的使用者驗證類型和方法，以及如何決定 Web 應用程式和區域所使用的驗證類型和方法。
瞭解 Microsoft 365 中的 SharePoint 驗證。
注意事項
在 SharePoint Server 訂閱版本中，我們現在支援 OIDC 1.0 驗證。 如需如何使用這個新驗證類型的詳細資訊，請參閱 OpenID Connect 1.0 驗證。
簡介
User authentication is the validation of a user's identity against an authentication provider, which is a directory or database that contains the user's credentials and can confirm the user submitted them correctly. An example of an authentication provider is Active Directory Domain Services (AD DS). 驗證提供者的其他詞彙包括使用者目錄和屬性存放區。
驗證方法是帳戶認證和其他資訊的特定交換，可判斷使用者的身分識別。 驗證方法的結果是驗證提供者驗證使用者的證明，通常使用包含宣告的 Token 格式。
驗證類型是根據一或多個驗證提供者驗證認證的特定方式，有時會使用業界標準通訊協定。 一種驗證類型可以使用多種驗證方法。
確認使用者身分識別之後，授權程序即可決定使用者所能存取的網站、內容及其他功能。
您對於使用者驗證類型和方法的規劃應該會決定：
每個 Web 應用程式和區域的使用者驗證類型和方法
支援決定使用之驗證類型和方法所需的驗證基礎結構
注意事項
SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 訂閱版本不再支援 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 宣告帳戶的用戶帳戶。
如需移轉再升級的詳細資訊，請參閱從傳統模式移轉至宣告式驗證。
如需升級再移轉的詳細資訊，請參閱＜Migrate from classic-mode to claims-based authentication in SharePoint Server＞。
如需如何在 SharePoint 2013 中建立使用傳統模式驗證之 Web 應用程式的資訊，請參閱＜建立 SharePoint Server 中使用傳統模式驗證的 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-Federation 被動要求者設定檔 (WS-F PRP) 。 無論是您自己的內部環境或合作夥伴環境，都需要與宣告型環境的系統管理員協調。 如果您使用 Active Directory 同盟服務 (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 驗證：
為 SQL Server 服務帳戶在 AD DS 中建立 SPN，以設定 SQL Server 通訊所用的 Kerberos 驗證。
為將使用 Kerberos 驗證的 Web 應用程式建立 SPN。
安裝 SharePoint Server 伺服器陣列。
在該伺服器陣列中設定特定服務使用特定服務帳戶。
建立將使用 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 應用程式的 Web.config 檔案中註冊成員資格提供者和角色管理員。
如需設定表單型驗證的詳細指示，請參閱為 SharePoint Server 中的宣告型 Web 應用程式設定表單型驗證。
規劃 SAML 權杖型驗證
SAML 權杖型提供者的實作架構包括下列元件：
SharePoint 安全性令牌服務 此服務會建立伺服器陣列所使用的 SAML 令牌。 服務會在伺服器陣列中的所有伺服器上自動建立和啟動。 服務用於伺服器數位列間通訊，因為所有伺服陣列間通訊都會使用宣告式驗證。 此服務也用於針對使用宣告式驗證的 Web 應用程式實作的驗證方法。 這些方法包括 Windows 驗證、表單型驗證和 SAML 令牌型驗證。
ImportTrustCertificate (令牌簽署憑證) 此憑證是您從IP-STS導出的憑證，然後複製到伺服器陣列中的一部伺服器，並將其新增至伺服器陣列的受信任根授權單位清單。 使用此憑證建立 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 項目。
IP-STS) (識別提供者安全性令牌服務 此服務是宣告環境中的安全令牌，代表包含在相關聯用戶目錄中的用戶發出 SAML 令牌。
下圖顯示 SharePoint Server SAML 權杖宣告架構。
SAML 權杖宣告架構
SPTrustedIdentityTokenIssuer 對像是使用數個參數所建立，其中包括：
單一身分識別宣告。
單一 SignInURL 參數。
SignInURL 參數會指定要將使用者要求重新導向至 的 URL，以便向 IP-STS 進行驗證。
單一 Wreply 參數。
某些IP-STS 伺服器需要 Wreply 參數，其設定為 true 或 false。 預設值為 False。 只有在IP-STS需要 Wreply 參數時，才使用它。
多個領域。
多個宣告對應。
若要使用 SharePoint Server 實作 SAML 令牌型驗證，請實作下列需要事先規劃的步驟：
從 IP-STS 匯出權杖簽署憑證。 將此憑證複製到 SharePoint Server 伺服器陣列中的伺服器。
定義要當成使用者唯一識別碼的宣告。 此宣告稱為身分識別宣告。 使用者主要名稱 (UPN) 或使用者電子郵件名稱經常會當成使用者識別碼。 請與 IP-STS 管理員協調，以決定正確的識別碼，因為只有 IP-STS 的擁有人才知道權杖中哪個值是每個使用者的唯一識別碼。 識別使用者的唯一識別碼是宣告對應程序的一個過程。 請使用 Microsoft PowerShell 建立宣告對應。
定義額外的宣告對應。 從 SharePoint Server 伺服器陣列將使用的傳入令牌定義額外的宣告。 使用者角色是 SharePoint Server 伺服器陣列中可用來將權限指派給資源的宣告範例。 將會捨棄來自沒有對應之傳入令牌的所有宣告。
使用 PowerShell 建立新的驗證提供者，以匯入權杖簽署憑證。 此程序會建立 SPTrustedIdentityTokenIssuer。 在此程式中，您會指定已對應的身分識別宣告和額外宣告。 建立並指定與您為 SAML 令牌型驗證設定的第一個 SharePoint Web 應用程式相關聯的領域。 建立 SPTrustedIdentityTokenIssuer之後，您可以為額外的SharePoint Web 應用程式建立並新增更多領域。 此程式可讓您設定多個 Web 應用程式使用相同的 SPTrustedIdentityTokenIssuer。
對於新增至 SPTrustedIdentityTokenIssuer 的每一個領域，您必須在 IP-STS 上建立 RP-STS 項目。 您可以在 SharePoint Web 應用程式存在之前建立此專案。 無論如何，您必須在建立 Web 應用程式之前規劃 URL。
針對現有或新的 SharePoint Web 應用程式，將其設定為使用新建立的驗證提供者。 當您建立 Web 應用程式時，驗證提供者會在管理中心中顯示為信任的身分識別提供者。
您可以設定多個 SAML 權杖型驗證提供者。 但是，您只能在伺服器陣列中使用權杖簽署憑證一次。 所有已設定的提供者都會顯示為管理中心的選項。 來自不同受信任 STS 環境的宣告不會發生衝突。
如果您向合作夥伴公司實作 SAML 令牌型驗證，且您自己的環境包含 IP-STS，建議您和內部宣告環境的系統管理員建立從內部 IP-STS 到合作夥伴 STS 的單向信任關係。 此方法不需要您將驗證提供者新增至 SharePoint Server 伺服器陣列。 它也可讓您的宣告系統管理員管理整個宣告環境。
重要事項
當您使用 SharePoint Server 的宣告式驗證時，不再需要將網路負載平衡設為單一相關性。
注意事項
[!附註] 若 Web 應用程式是設定為使用 SAML 權杖型驗證， SPTrustedClaimProvider 類別就不會提供「人員選擇」控制項搜尋功能。 任何「人員選擇」控制項中輸入的文字不論其是否為有效的使用者、群組或宣告，在解析後都會自動顯示。 若您的 SharePoint Server 解決方案使用 SAML 權杖型驗證，請規劃建立實作自訂搜尋及名稱解析的自訂宣告提供者。
如需設定 SAML 型驗證的詳細指示，請參閱使用 SharePoint Server 中的 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。 員工會使用不同的區域，視他們在辦公室工作或遠端工作而定。