在 SharePoint Server 中規劃使用者驗證方法Plan for user authentication methods in SharePoint Server

摘要: 規劃如何使用各種使用者驗證方法,為 SharePoint Server 2013 和 SharePoint Server 2016 中的 Web 應用程式使用者建立安全體驗。Summary: Plan how to use various user authentication methods to create a secure experience for web application users in SharePoint Server 2013 and SharePoint Server 2016.

了解 SharePoint Server 所支援的使用者驗證類型和方法,以及如何決定 Web 應用程式和區域所使用的驗證類型和方法。Learn the user authentication types and methods that are supported by SharePoint Server and how to determine which ones to use for web applications and zones.


使用者驗證是根據驗證提供者對使用者身分識別進行的驗證,驗證提供者是包含使用者認證並可確認使用者正確提交認證的目錄或資料庫,例如 Active Directory 網域服務 (AD DS)。其他驗證提供者的專有名詞還包括使用者目錄和屬性存放區。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). Other terms for authentication provider are user directory and attribute store.

驗證方法是帳戶認證與宣告使用者身分識別之其他資訊的特定交換。驗證方法的結果是驗證提供者驗證使用者的證明,通常使用包含宣告的權杖格式。An authentication method is a specific exchange of account credentials and other information that assert a user's identity. The result of the authentication method is proof, typically in the form of a token that contains claims, that an authentication provider has authenticated a user.

驗證類型是根據一或多個驗證提供者驗證認證的特定方式,有時會使用業界標準通訊協定。一種驗證類型可以使用多種驗證方法。An authentication type is a specific way of validating credentials against one or more authentication providers, sometimes using an industry standard protocol. An authentication type can use multiple authentication methods.

確認使用者身分識別之後,授權程序即可決定使用者所能存取的網站、內容及其他功能。After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

規劃使用者驗證類型和方法時應該決定下列事項:Your planning for user authentication types and methods should determine the following:

  • 每個 Web 應用程式和區域的使用者驗證類型和方法The user authentication types and methods for each web application and zone

  • 支援決定使用之驗證類型和方法所需的驗證基礎結構The authentication infrastructure needed to support the determined authentication types and methods


    SharePoint Server 2016 不再支援 Windows 傳統模式驗證。Windows classic mode authentication is no longer supported in SharePoint Server 2016.

宣告式驗證Claims-based authentication

AD DS 的使用者身分識別是以使用者帳戶為基礎。為了能順利驗證,使用者需要提供帳戶名稱及知道密碼的證明。若要確定資源的存取權,應用程式可能必須查詢 AD DS 以取得帳戶屬性及其他資訊,例如網路上的群組成員資格或角色。雖然此作法適用於 Windows 環境,但是不會向外延展至協力廠商驗證提供者,以及支援網際網路、合作夥伴或雲端架構運算模型的多廠商環境。User identity in AD DS is based on a user account. For successful authentication, the user provides the account name and proof of knowledge of the password. To determine access to resources, applications might have to query AD DS for account attributes and other information, such as group membership or role on the network. While this works well for Windows environments, it does not scale out to third-party authentication providers and multi-vendor environments that support Internet, partner, or cloud-based computing models.

透過宣告式身分識別,使用者可以從一般信任的身分識別提供者取得數位簽署的安全性權杖。此權杖包含一組宣告。每個宣告代表有關使用者的特定資料項目,例如使用者的名稱、群組成員資格及網路上的角色。宣告式驗證是使用宣告式身分識別技術和基礎結構的使用者驗證。支援宣告式驗證的應用程式可從使用者取得安全性權杖 (而不是認證),並使用宣告中的資訊來決定資源存取權。不需要目錄服務 (例如 AD DS) 的個別查詢。With claims-based identities, a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of claims. Each claim represents a specific item of data about a user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that uses claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain a security token from a user, rather than credentials, and use the information within the claims to determine access to resources. No separate query to a directory service such as AD DS is needed.

Windows 宣告式驗證是根據 Windows Identity Foundation (WIF,一組用來實作宣告式身分識別的 .NET Framework 類別) 所建立。宣告式驗證需依賴一些標準 (例如 WS-同盟、WS-Trust) 及通訊協定 (例如安全性聲明標記語言 (SAML))。Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as the Security Assertion Markup Language (SAML).

如需宣告式驗證的詳細資訊,請參閱下列資源:For more information about claims-based authentication, see the following resources:

由於宣告式驗證廣泛用於使用者驗證、伺服器對伺服器驗證及應用程式驗證,因此建議針對 SharePoint Server 伺服器陣列的所有 Web 應用程式和區域使用宣告式驗證。如需詳細資訊,請參閱<在 SharePoint Server 中規劃伺服器對伺服器的驗證>。當您使用宣告式驗證時,Web 應用程式可使用所有支援的驗證方法,且您可以利用 SharePoint Server 中使用伺服器對伺服器驗證及應用程式驗證的新功能和案例。Due to the widespread use of claim-based authentication for user authentication, server-to-server authentication, and app authentication, we recommend claims-based authentication for all web applications and zones of a SharePoint Server farm. For more information, see Plan for server-to-server authentication in SharePoint Server. When you use claims-based authentication, all supported authentication methods are available for your web applications and you can take advantage of new features and scenarios in SharePoint Server that use server-to-server authentication and app authentication.

針對宣告式驗證,SharePoint Server 會自動將所有使用者帳戶變更成宣告身分識別。這會為每位使用者產生安全性權杖 (又稱為宣告權杖)。宣告權杖中包含關於使用者的宣告。Windows 帳戶將轉換成 Windows 宣告。表單型成員資格使用者則轉換成表單型驗證宣告。SharePoint Server 可以使用 SAML 型權杖中的宣告。此外,SharePoint 開發人員及管理員可加入其他宣告以增強使用者權杖。例如,加入其他 SharePoint Server 使用的宣告可增強 Windows 使用者帳戶及表單型帳戶。For claims-based authentication, SharePoint Server automatically changes all user accounts to claims identities. This results in a security token (also known as a claims token) for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. SharePoint Server can use claims that are included in SAML-based tokens. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Server.

您不必是宣告架構師,也能在 SharePoint Server 中使用宣告式驗證。但是,實作 SAML 權杖型驗證時,您需與宣告式環境的管理員協調,如規劃 SAML 權杖型驗證所述。You do not have to be a claims architect to use claims-based authentication in SharePoint Server. However, implementing SAML token-based authentication requires coordination with administrators of your claims-based environment, as described in Plan for SAML token-based authentication.

SharePoint Server 2013 中的傳統模式驗證Classic mode authentication in SharePoint Server 2013

在 SharePoint 2013 中,當您在管理中心中建立 Web 應用程式時,您只能指定宣告式驗證的驗證類型和方法。在舊版 SharePoint 中,您也可以在管理中心中設定 Web 應用程式使用傳統模式驗證。傳統模式驗證使用 Windows 驗證,且 SharePoint 2013 會將使用者帳戶視為 AD DS 帳戶。In SharePoint 2013, when you create a web application in Central Administration, you can only specify authentication types and methods for claims-based authentication. In previous versions of SharePoint, you could also configure classic mode authentication for web applications in Central Administration. Classic mode authentication uses Windows authentication and SharePoint 2013 treats the user accounts as AD DS accounts.

若要設定 Web 應用程式使用傳統模式驗證,您必須使用 New-SPWebApplication PowerShell Cmdlet 建立 Web 應用程式。設定為使用傳統模式驗證的 SharePoint 2010 產品 Web 應用程式會在升級為 SharePoint 2013 之後保留其驗證設定。但是,建議您將 Web 應用程式移轉至宣告式驗證,再升級為 SharePoint 2013。To configure a web application to use classic mode authentication, you must use the New-SPWebApplication PowerShell cmdlet to create it. SharePoint 2010 Products web applications that are configured for classic mode authentication retain their authentication settings when you upgrade to SharePoint 2013. However, we recommend that you migrate your web applications to claims-based authentication before upgrading to SharePoint 2013.

SharePoint 2013 伺服器陣列可以包含使用兩種模式之 Web 應用程式的組合。某些服務不會區分使用者帳戶屬於傳統 Windows 帳戶或 Windows 宣告帳戶。A SharePoint 2013 farm can include a mix of web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts.

如需移轉再升級的詳細資訊,請參閱從傳統模式移轉至宣告式驗證For more information about migrating before upgrading, see Migrate from classic-mode to claims-based authentication.

如需升級再移轉的詳細資訊,請參閱<Migrate from classic-mode to claims-based authentication in SharePoint Server>。For more information about migrating after upgrading, see Migrate from classic-mode to claims-based authentication in SharePoint Server.

如需如何在 SharePoint 2013 中建立使用傳統模式驗證之 Web 應用程式的資訊,請參閱<建立 SharePoint Server 中使用傳統模式驗證的 web 應用程式>。請注意,您無法將使用宣告式驗證的 Web 應用程式移轉至使用傳統模式驗證。For information about how to create web applications that use classic mode authentication in SharePoint 2013, see Create web applications that use classic mode authentication in SharePoint Server. Note that you cannot migrate a web application that uses claims-based authentication to use classic mode authentication.


只有使用宣告式驗證的 SharePoint 2013 Web 應用程式才能使用 Office Online。在使用傳統模式驗證的 SharePoint 2013 Web 應用程式上,Office Online 的轉譯和編輯無法運作。若您將使用傳統模式驗證的 SharePoint 2010 Web 應用程式移轉至 SharePoint 2013,就必須將這些應用程式移轉至宣告式驗證以允許其搭配 Office Online 使用。Office Online can be used only by SharePoint 2013 web applications that use claims-based authentication. Office Online rendering and editing will not work on SharePoint 2013 web applications that use classic mode authentication. If you migrate SharePoint 2010 web applications that use classic mode authentication to SharePoint 2013, you must migrate them to claims-based authentication to allow them to work with Office Online.

支援的驗證類型和方法Supported authentication types and methods

SharePoint Server 支援下列驗證類型的各種驗證方法及驗證提供者:SharePoint Server supports a variety of authentication methods and authentication providers for the following authentication types:

  • Windows 驗證Windows authentication

  • 表單型驗證Forms-based authentication

  • SAML 權杖型驗證SAML token-based authentication

Windows 驗證Windows authentication

Windows 驗證類型利用現有的 Windows 驗證提供者 (AD DS) 及 Windows 網域環境用來驗證連線用戶端之認證的驗證通訊協定。宣告式驗證所使用的 Windows 驗證方法如下:The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS) and the authentication protocols that a Windows domain environment uses to validate the credentials of connecting clients. Windows authentication method, which is used by both claims-based authentication include the following:


  • KerberosKerberos

  • 摘要Digest

  • 基本Basic

如需詳細資訊,請參閱本文中的<規劃 Windows 驗證>。For more information, see Plan for Windows authentication in this article.

觀看 SharePoint 2013 和 SharePoint Server 2016 中的 Windows 宣告驗證影片Watch the Windows claims authentication in SharePoint 2013 and SharePoint Server 2016 video

SharePoint Server 也支援匿名驗證,不過這不是 Windows 驗證類型。使用者不需驗證其認證,就能存取 SharePoint 內容。預設會停用匿名驗證。當您使用 SharePoint Server 發佈不需要安全性且提供給所有使用者的內容時 (例如公用網際網路網站),一般會使用匿名驗證。Although not a Windows authentication type, SharePoint Server also supports anonymous authentication. Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled by default. You typically use anonymous authentication when you use SharePoint Server to publish content that does not require security and is available for all users, such as a public Internet website.

請注意,除了啟用匿名驗證之外,您也必須設定網站和網站資源上的匿名存取 (權限)。Note that in addition to enabling anonymous authentication, you must also configure anonymous access (permissions) on sites and site resources.


由 SharePoint 所建立可服務 Web 應用程式的 Internet Information Services (IIS) 網站,一律會啟用匿名驗證和表單驗證方法,即使已停用匿名驗證和表單驗證的 SharePoint 設定時也是一樣。這是故意的,而直接在 IIS 設定中停用匿名驗證或表單驗證會導致 SharePoint 網站發生錯誤。Internet Information Services (IIS) websites that are created by SharePoint for serving web applications always have the Anonymous Authentication and Forms Authentication methods enabled, even when the SharePoint setting for Anonymous and Forms Authentication are disabled. This is intentional and disabling Anonymous or Forms Authentication directly in the IIS settings will result in errors in the SharePoint site.

表單型驗證Forms-based authentication

表單型驗證 (FBA) 是宣告式身分識別管理系統,以 ASP.NET 成員資格與角色提供者驗證為基礎。您可以對儲存在下列驗證提供者的認證使用宣告式驗證:Forms-based authentication is a claims-based identity management system that is based on ASP.NET membership and role provider authentication. Forms-based authentication can be used against credentials that are stored in an authentication provider, such as the following:


  • 資料庫 (例如 SQL Server 資料庫)A database such as a SQL Server database

  • 輕量型目錄存取通訊協定 (LDAP) 資料存放區 (例如 Novell eDirectory、Novell Directory Services (NDS) 或 Sun ONE)An Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE

表單型驗證會根據使用者以登入表單形式 (通常為網頁) 輸入的認證來驗證使用者。未經驗證的要求會重新導向至登入頁面,使用者必須在該頁面提供有效認證再送出表單。系統會發出驗證要求的 Cookie,包含用於重新建立後續要求之身分識別的金鑰。Forms-based authentication validates users based on credentials that users type in a logon form (typically a web page). Unauthenticated requests are redirected to a logon page, where a user must provide valid credentials and submit the form. The system issues a cookie for authenticated requests that contains a key for reestablishing the identity for subsequent requests.

觀看 SharePoint 2013 和 SharePoint Server 2016 中的表單型宣告驗證影片Watch the forms-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video


若是表單型驗證,則會以純文字形式傳送使用者帳戶認證。因此,除非您同時使用安全通訊端階層 (SSL) 加密網站流量,否則不應使用表單型驗證。With forms-based authentication, the user account credentials are sent as plaintext. Therefore, you should not use forms-based authentication unless you are also using Secure Sockets Layer (SSL) to encrypt the website traffic.

如需詳細資訊,請參閱規劃表單型驗證For more information, see Plan for forms-based authentication.

SAML 權杖型驗證SAML token-based authentication

SharePoint Server 的 SAML 權杖型驗證使用 SAML 1.1 通訊協定和 WS-同盟被動式要求者設定檔 (WS-F PRP),需與宣告式環境 (無論是貴組織本身內部環境或是合作夥伴環境) 的管理員進行協調。如果使用 Active Directory Federation Services (AD FS) 2.0,則會具有 SAML 權杖型驗證環境。SAML token-based authentication in SharePoint Server uses the SAML 1.1 protocol and the WS-Federation Passive Requestor Profile (WS-F PRP). It requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. If you use Active Directory Federation Services (AD FS) 2.0, you have a SAML token-based authentication environment.

SAML 權杖型驗證環境中包含一個身分識別提供者 Security Token Service (IP-STS)。IP-STS 會代表帳戶包含在相關聯驗證提供者中的使用者發行 SAML 權杖。在權杖中,可包括關於使用者 (例如,使用者名稱及使用者所屬群組) 的任意數目宣告。AD FS 2.0 伺服器即為 IP-STS 的一例。A SAML token-based authentication environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication provider. Tokens can include any number of claims about a user, such as a user name and the groups to which the user belongs. An AD FS 2.0 server is an example of an 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 Server takes advantage of claims that are included in tokens that an IP-STS issues to authorized users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can represent multiple RP-STS entries in the IP-STS.

觀看 SharePoint 2013 和 SharePoint Server 2016 中的 SAML 型宣告驗證影片Watch the SAML-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video

SAML 權杖型驗證的一組驗證提供者取決於宣告環境中的 IP-STS。如果使用 AD FS 2.0,驗證提供者 (又稱為 AD FS 2.0 的屬性存放區) 包括:The set of authentication providers for SAML token-based authentication depends on the IP-STS in your claims environment. If you use AD FS 2.0, authentication providers (known as attribute stores for AD FS 2.0) can include the following:

  • Windows Server 2003 Active Directory 和 Windows Server 2008 的 AD DSWindows Server 2003 Active Directory and AD DS in Windows Server 2008

  • 所有版本的 SQL Server 2005 和 SQL Server 2008All editions of SQL Server 2005 and SQL Server 2008

  • 自訂屬性存放區Custom attribute stores

如需詳細資訊,請參閱<規劃 SAML 權杖型驗證>。For more information, see Plan for SAML token-based authentication.

選擇 LDAP 環境的驗證類型Choosing authentication types for LDAP environments

表單型驗證或 SAML 權杖型驗證可以使用 LDAP 環境。您應該使用配合目前 LDAP 環境的驗證類型。如果目前沒有 LDAP 環境,建議您使用表單型驗證,因為這種驗證複雜性較低。不過,如果驗證環境已支援 WS-同盟 1.1 及 SAML 1.1,則建議使用 SAML。SharePoint Server 具有內建 LDAP 提供者。Forms-based authentication or SAML token-based authentication can use LDAP environments. You should use the authentication type that matches your current LDAP environment. If you do not already have an LDAP environment, we recommend that you use forms-based authentication because it is less complex. However, if your authentication environment already supports WS-Federation 1.1 and SAML 1.1, then we recommend SAML. SharePoint Server has a built-in LDAP provider.

規劃 Windows 驗證Plan for Windows authentication

規劃及實作用於宣告式驗證之 Windows 驗證方法的程序類似。為 Web 應用程式選擇宣告式驗證並不會使實作 Windows 驗證方法變得更複雜。本節摘要說明如何規劃 Windows 驗證方法。The process of planning and implementing Windows authentication methods is similar for claims-based authentication. Claims-based authentication for a web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the planning for the Windows authentication methods.

NTLM 和 Kerberos 通訊協定NTLM and the Kerberos protocol

NTLM 和 Kerberos 通訊協定都是整合式 Windows 驗證方法,這兩種方法可讓使用者無縫地進行驗證,而不需經由提示要求認證。例如:Both NTLM and the Kerberos protocol are Integrated Windows authentication methods, which let users seamlessly authenticate without prompts for credentials. For example:

  • 使用者若從 Internet Explorer 存取 SharePoint 網站,將使用執行 Internet Explorer 程序所用的認證,進行驗證。根據預設,這些認證即是使用者用於登入電腦的認證。Users who access SharePoint sites from Internet Explorer use the credentials under which the Internet Explorer process is running to authenticate. By default, these credentials are the credentials that the user used to log on to the computer.

  • 使用整合式 Windows 驗證方法存取 SharePoint 資源的服務或應用程式,會嘗試使用執行中之執行緒的認證 (根據預設,此即是該程序的身分識別) 進行驗證。Services or applications that use Integrated Windows authentication methods to access SharePoint resources attempt to use the credentials of the running thread, which by default is the identity of the process, to authenticate.

NTLM 是最容易實作的 Windows 驗證方法,通常不需要驗證基礎結構的任何其他設定。只要在建立或設定 Web 應用程式時,選取此選項即可。NTLM is the simplest form of Windows authentication to implement and typically requires no additional configuration of authentication infrastructure. Simply select this option when you create or configure the web application.

Kerberos 通訊協定支援票證驗證。使用 Kerberos 通訊協定需對環境進行額外設定。若要啟用 Kerberos 驗證,用戶端與伺服器電腦必須擁有連至網域金鑰發佈中心 (KDC) 的信任連線。若要設定 Kerberos 通訊協定,您需在安裝 SharePoint Server 之前,先在 AD DS 中設定服務主要名稱 (SPN)。The Kerberos protocol supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Server.

您應該考慮使用 Kerberos 驗證的原因如下:The reasons why you should consider Kerberos authentication are as follows:

  • Kerberos 通訊協定是最強大的整合式 Windows 驗證通訊協定,而且支援進階安全性功能 (包括進階加密標準 (AES) 加密,以及用戶端和伺服器的相互驗證)。The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication of clients and servers.

  • Kerberos 通訊協定允許委派用戶端認證。The Kerberos protocol allows for delegation of client credentials.

  • 在可用的安全驗證方法中,Kerberos 需要與 AD DS 網域控制站的最少網路流量。在特定情況下,Kerberos 可以減少頁面延遲,或是在特定情況下增加前端網頁伺服器可以提供的頁面數。Kerberos 也可以減少網域控制站的負載。Of the available secure authentication methods, Kerberos requires the least amount of network traffic to AD DS domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers.

  • Kerberos 通訊協定是許多平台和廠商支援的開放式通訊協定。The Kerberos protocol is an open protocol that many platforms and vendors support.

    Kerberos 驗證可能不適用的原因如下:The reasons why Kerberos authentication might not be appropriate are as follows:

  • Kerberos 驗證比其他驗證方法需要更多基礎結構和環境的設定,才能正常運作。在許多情況下,需要有網域管理員權限,才能設定 Kerberos 通訊協定。Kerberos 驗證可能很難設定和管理。Kerberos 的設定錯誤可能會讓您的網站驗證失敗。Kerberos authentication requires more configuration of infrastructure and environment than other authentication methods to function correctly. In many cases, domain administrator permission is required to configure the Kerberos protocol. Kerberos authentication can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.

  • Kerberos 驗證需要 KDC 及 AD DS 網域控制站的用戶端電腦連線。在 Windows 部署中,KDC 是 AD DS 網域控制站。雖然這是組織內部網路常見的網路設定,但是網際網路對應部署一般不是以此方式進行設定。Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common network configuration on an organization intranet, Internet-facing deployments are typically not configured in this manner.

下列步驟摘要說明如何設定 Kerberos 驗證:The following steps summarize configuring Kerberos authentication:

  1. 為 SQL Server 服務帳戶在 AD DS 中建立 SPN,以設定 SQL Server 通訊所用的 Kerberos 驗證。Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

  2. 為將使用 Kerberos 驗證的 Web 應用程式建立 SPN。Create SPNs for web applications that will use Kerberos authentication.

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

  4. 在該伺服器陣列中設定特定服務使用特定服務帳戶。Configure specific services within the farm to use specific accounts.

  5. 建立將使用 Kerberos 驗證的 Web 應用程式。Create the web applications that will use Kerberos authentication.

摘要及基本Digest and Basic

若是摘要驗證方法,則會以 MD5 訊息摘要形式將使用者帳戶認證傳送至主控 Web 應用程式或區域之網頁伺服器上的 Internet Information Services (IIS) 服務。若是基本驗證方法,則會以純文字形式傳送使用者帳戶認證。因此,除非您同時使用 SSL 加密網站流量,否則不應使用基本驗證方法。With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the Internet Information Services (IIS) service on the web server that hosts the web application or zone. With the Basic authentication method, the user account credentials are sent as plaintext. Therefore, you should not use the Basic authentication method unless you are also using SSL to encrypt the website traffic.

如果您的環境使用僅支援網站之摘要或基本驗證的網頁瀏覽器或服務,則可能必須使用這些較舊的驗證方法。You might have to use these older authentication methods if your environment uses web browsers or services that only support Digest or Basic authentication to websites.

不像 NTLM、Kerberos 及匿名驗證方法,您會從對應至 Internet Information Services (IIS) 嵌入式管理單元中之 Web 應用程式或區域的網站內容設定摘要和基本驗證方法。Unlike the NTLM, Kerberos, and Anonymous authentication methods, you configure Digest and Basic authentication methods from the properties of the web site that corresponds to the web application or zone in the Internet Information Services (IIS) snap-in.

如果使用宣告式驗證,請參閱:If you are using claims-based authentication, see the following:

規劃表單型驗證Plan for forms-based authentication

若在使用表單型驗證時,根據外部或不是以 Windows 為基礎的身分識別管理系統驗證使用者,則必須在 Web.config 檔案中登錄成員資格提供者及角色管理員。SharePoint Server 使用標準 ASP.NET 角色管理員介面,收集目前使用者的群組資訊。SharePoint Server 的授權程序會將每一個 ASP.NET 角色視為一個網域群組。在 Web.config 檔案登錄角色管理員的方法,與登錄用於驗證之成員資格提供者的方法完全相同。To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider and role manager in the Web.config file. SharePoint Server uses the standard ASP.NET role manager interface to collect group information about the current user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Server. You register role managers in the Web.config file exactly as you register membership providers for authentication.

若要從管理中心網站管理成員資格使用者或角色,您必須在 Web.config 檔案中為管理中心網站登錄成員資格提供者及角色管理員。您還必須在 Web.config 檔案中,為主控內容的 Web 應用程式登錄成員資格提供者及角色管理員。If you want to manage membership users or roles from the Central Administration website, you must register the membership provider and the role manager in the Web.config file for the Central Administration website. You must also register the membership provider and the role manager in the Web.config file for the web application that hosts the content.

如需設定表單型驗證的詳細指示,請參閱為 SharePoint Server 中的宣告型 Web 應用程式設定表單型驗證For detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based web application in SharePoint Server

規劃 SAML 權杖型驗證Plan for SAML token-based authentication

SAML 權杖型提供者的實作架構包括下列元件:The architecture for implementing SAML token-based providers includes the following components:

  • SharePoint Security Token Service 此服務會建立伺服器陣列所用的 SAML 權杖。此服務會在伺服器陣列的所有伺服器上自動建立並啟動。此服務用於伺服器陣列之間的通訊,因為所有伺服器陣列之間的通訊都是使用宣告式驗證。此服務還用於使用宣告式驗證之 Web 應用程式所實作的驗證方法,包括 Windows 驗證、表單型驗證及 SAML 權杖型驗證。SharePoint Security Token Service This service creates the SAML tokens that the farm uses. The service is automatically created and started on all servers in a server farm. The service is used for inter-farm communication because all inter-farm communication uses claims-based authentication. This service is also used for authentication methods that are implemented for web applications that use claims-based authentication. This includes Windows authentication, forms-based authentication, and SAML token-based authentication.

  • 權杖簽署憑證 (ImportTrustCertificate) 此憑證會從 IP-STS 匯出,然後再複製到伺服器陣列的一部伺服器上,並加入伺服器陣列的 [受信任的根授權單位] 清單。一旦您使用此憑證建立 SPTrustedIdentityTokenIssuer,就無法使用此憑證建立其他 SPTrustedIdentityTokenIssuer。若要使用此憑證建立不同 SPTrustedIdentityTokenIssuer,則必須先刪除現有的 SPTrustedIdentityTokenIssuer。在刪除現有的 SPTrustedIdentityTokenIssuer 之前,必須先從所有可能使用它的 Web 應用程式中解除彼此關聯。Token-signing certificate (ImportTrustCertificate) This is the certificate that you export from an IP-STS and then copy to one server in the farm and add it to the farm's Trusted Root Authority list. Once you use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it to create another one. To use the certificate to create a different SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from all web applications that may be using it.

  • 身分識別宣告 身分識別宣告是來自 SAML 權杖的宣告,它是使用者的唯一識別碼。只有 IP-STS 的擁有人才知道權杖中哪個值是每個使用者的唯一識別碼。在對應所有所需宣告期間,會建立身分識別宣告,作為一般宣告對應。作為身分識別宣告之用的宣告,是在建立 SPTrustedIdentityTokenIssuer 時宣告。Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token will always be unique for each user. The identity claim is created as a regular claims mapping during the mapping of all desired claims. The claim that serves as the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

  • 其他宣告 這些宣告包括 SAML 票證中用以描述使用者的其他宣告,其中可包括使用者角色、使用者群組或其他種類的宣告,例如年齡。所有宣告對應都會建立成物件形式,並在 SharePoint Server 伺服器陣列的伺服器之間複寫。Other claims These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Server farm.

  • 領域 在 SharePoint 宣告架構中,URI 或 URL 若與設為使用 SAML 權杖型提供者之 SharePoint Web 應用程式相關聯,即為領域。當在伺服器陣列上建立 SAML 型驗證提供者,您需指定 IP-STS 要辨識的領域,或 Web 應用程式 URL (一次指定一個)。第一個領域是在您建立 SPTrustedIdentityTokenIssuer 時指定。建立 SPTrustedIdentityTokenIssuer 之後即可新增更多領域。指定領域的語法類似下列語法: $realm = "urn:sharepoint:mysites"。對 SPTrustedIdentityTokenIssuer 新增領域之後,您必須對 IP-STS 伺服器上的領域識別碼建立 RP-STS 信任。此程序包含指定 Web 應用程式的 URL。Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. You can add more realms after you create the SPTrustedIdentityTokenIssuer. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm identifier on the IP-STS server. This process involves specifying the URL for the web application.

  • SPTrustedIdentityTokenIssuer 這個物件是建立在包含進行 IP-STS 通訊並從此通訊中接收權限所需之值的 SharePoint 伺服器陣列上。在建立 SPTrustedIdentityTokenIssuer 時,您需指定要使用的權杖簽署憑證、第一個領域、代表身分識別宣告的宣告,以及其他任何宣告。來自 STS 的權杖簽署憑證只能與一個 SPTrustedIdentityTokenIssuer 產生關聯。但是,建立 SPTrustedIdentityTokenIssuer 之後,您還是可以為其他 Web 應用程式新增更多領域。將領域新增至 SPTrustedIdentityTokenIssuer 之後,您還必須將它當成信賴憑證者新增至 IP-STS。SPTrustedIdentityTokenIssuer 物件會在 SharePoint Server 伺服器陣列的伺服器之間複寫。SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create the SPTrustedIdentityTokenIssuer, you can add more realms for additional web applications. After you add a realm to the SPTrustedIdentityTokenIssuer, you must also add it to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Server farm.

  • 信賴憑證者 Security Token Service (RP-STS) 在 SharePoint Server 中,每個設為使用 SAML 提供者的 Web 應用程式都會當成 RP-STS 項目新增至 IP-STS 伺服器。SharePoint Server 伺服器陣列可包含多個 RP-STS 項目。Relying party security token service (RP-STS) In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as an RP-STS entry. A SharePoint Server farm can include multiple RP-STS entries.

  • 身分識別提供者 Security Token Service (IP-STS) 宣告環境中的這個 Security Token Service 會代表相關使用者目錄中的使用者發行 SAML 權杖。Identity provider security token service (IP-STS) This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are included in the associated user directory.

下圖顯示 SharePoint Server SAML 權杖宣告架構。The following diagram shows the SharePoint Server SAML token claims architecture.

SAML 權杖宣告架構SAML token claims architecture

SharePoint 宣告驗證元件

SPTrustedIdentityTokenIssuer 由多個參數所建立,其中包含以下參數:The SPTrustedIdentityTokenIssuer object is created with several parameters, which include the following:

  • 單一身分識別宣告。A single identity claim.

  • 單一 SignInURL 參數。A single SignInURL parameter.

    SignInURL 參數可指定將使用者要求重新導向的 URL,以對 IP-STS 進行驗證。The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS.

  • 單一 Wreply 參數。A single Wreply parameter.

    部分 IP-STS 伺服器會要求使用 Wreply 參數,而該參數可能設為 True 或 False;False 為預設值。只有當 IP-STS 要求 Wreply 參數時,再使用該參數。Some IP-STS servers require the Wreply parameter, which is set to either true or false. False is the default. Use the Wreply parameter only if it is required by the IP-STS.

  • 多個領域。Multiple realms.

  • 多個宣告對應。Multiple claims mappings.

若要對 SharePoint Server 實作 SAML 權杖型驗證,請使用需事先規劃的下列步驟:To implement SAML token-based authentication with SharePoint Server, use the following steps which require planning in advance:

  1. 從 IP-STS 匯出權杖簽署憑證。將此憑證複製到 SharePoint Server 伺服器陣列中的伺服器。Export the token-signing certificate from the IP-STS. Copy the certificate to a server in the SharePoint Server farm.

  2. 定義要當成使用者唯一識別碼的宣告。此稱之為身分識別宣告。使用者主要名稱 (UPN) 或使用者電子郵件名稱經常會當成使用者識別碼。請與 IP-STS 管理員協調,以決定正確的識別碼,因為只有 IP-STS 的擁有人才知道權杖中哪個值是每個使用者的唯一識別碼。識別使用者的唯一識別碼是宣告對應程序的一個過程。請使用 Microsoft PowerShell 建立宣告對應。Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. The user principal name (UPN) or user e-mail name is frequently used as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. You use Microsoft PowerShell to create claims mappings.

  3. 定義其他宣告對應。定義 SharePoint Server 伺服器陣列將使用之其他來自傳入權杖的宣告。使用者角色是 SharePoint Server 伺服器陣列中可用來將權限指派給資源的宣告範例。所有來自傳入權杖的宣告若沒有對應,將遭捨棄。Define additional claims mappings. Define the additional claims from the incoming token that the SharePoint Server farm will use. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint Server farm. All claims from an incoming token that do not have a mapping will be discarded.

  4. 使用 PowerShell 建立新的驗證提供者,以匯入權杖簽署憑證。此程序會建立 SPTrustedIdentityTokenIssuer。在此過程中,您需指定身分識別宣告及您對應的其他宣告。您還必須建立並指定領域,以與您為 SAML 權杖型驗證設定的第一個 SharePoint Web 應用程式相關聯。建立 SPTrustedIdentityTokenIssuer 之後,您可以建立並新增更多領域,以供其他 SharePoint Web 應用程式使用。這就是設定多個 Web 應用程式使用同一個 SPTrustedIdentityTokenIssuer 的作法。Use PowerShell to create a new authentication provider to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint web applications that you are configuring for SAML token-based authentication. After you create the SPTrustedIdentityTokenIssuer, you can create and add more realms for additional SharePoint web applications. This is how you configure multiple web applications to use the same SPTrustedIdentityTokenIssuer.

  5. 對於新增至 SPTrustedIdentityTokenIssuer 的每一個領域,您必須在 IP-STS 上建立 RP-STS 項目。您可以在 SharePoint Web 應用程式存在之前完成此作業。無論如何,您必須在建立 Web 應用程式之前規劃 URL。For each realm that you add to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. You can do this before the SharePoint web application exists. Regardless, you must plan the URL before you create the web applications.

  6. 針對現有或新的 SharePoint Web 應用程式,將其設定為使用新建立的驗證提供者。當您建立 Web 應用程式時,驗證提供者會在管理中心中顯示為信任的身分識別提供者。For an existing or new SharePoint web application, configure it to use the newly created authentication provider. The authentication provider is displayed as a trusted identity provider in Central Administration when you create a web application.

您可以設定多個 SAML 權杖型驗證提供者。但是,您只能在伺服器陣列中使用權杖簽署憑證一次。所有已設定的提供者都會顯示為管理中心的選項。來自不同受信任 STS 環境的宣告將不會產生衝突。You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All configured providers are displayed as options in Central Administration. Claims from different trusted STS environments will not conflict.

如果您對合作夥伴公司實作 SAML 權杖型驗證,且貴組織本身環境也包括 IP-STS,建議您與內部宣告環境的管理員一起建立內部 IP-STS 與合作夥伴 STS 之間的單向信任關係。這種作法不需要對您的 SharePoint Server 伺服器陣列新增驗證提供者,同時也可讓您的宣告管理員管理整個宣告環境。If you implement SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you and the administrator of your internal claims environment establish a one-way trust relationship from your internal IP-STS to the partner STS. This approach does not require you to add an authentication provider to your SharePoint Server farm. It also enables your claims administrators to manage the whole claims environment.


當您使用 SharePoint Server 的宣告式驗證時,不再需要將網路負載平衡設為單一相關性。You no longer have to set network load balancing to single affinity when you are using claims-based authentication in SharePoint Server.


若 Web 應用程式是設定為使用 SAML 權杖型驗證, SPTrustedClaimProvider 類別就不會提供「人員選擇」控制項搜尋功能。任何「人員選擇」控制項中輸入的文字不論其是否為有效的使用者、群組或宣告,在解析後都會自動顯示。若您的 SharePoint Server 解決方案使用 SAML 權杖型驗證,請規劃建立實作自訂搜尋及名稱解析的自訂宣告提供者。When a web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it resolves, regardless of whether it is a valid user, group, or claim. If your SharePoint Server solution uses SAML token-based authentication, plan to create a custom claims provider that implements custom search and name resolution.

如需設定 SAML 型驗證的詳細指示,請參閱使用 SharePoint Server 中的 AD FS 設定 SAML 型宣告驗證For detailed steps to configure SAML token-based authentication using AD FS, see Configure SAML-based claims authentication with AD FS in SharePoint Server.

規劃 Web 應用程式的區域Planning zones for web applications

區域代表存取 Web 應用程式中同一個網站的不同邏輯路徑。每個 Web 應用程式最多可包含五個區域。當您建立 Web 應用程式時,管理中心會建立預設區域。若要建立其他區域,請擴充 Web 應用程式,並從其餘區域名稱中選取其中之一:內部網路、外部網路、網際網路或自訂。Zones represent different logical paths to gain access to the same sites in a web application. Each web application can include as many as five zones. When you create a web application, Central Administration creates the zone named default. To create additional zones, extend the web application and select one of the remaining zone names: intranet, extranet, Internet, or custom.

請根據下列項目來規劃區域:Your plan for zones will depend on the following:

  • 宣告式驗證 (建議使用) - 您可以在單一區域上實作多個驗證提供者。您也可以使用多個區域。Claims-based authentication (recommended) — You can implement multiple authentication providers on a single zone. You can also use multiple zones.

    在單一區域中實作多種驗證類型Implementing more than one type of authentication on a single zone

如果使用的是宣告式驗證,並同時實作多種驗證方法,建議您在預設區域上實作多種驗證方法。結果是所有使用者使用相同 URL。If you use claims-based authentication and implement more than one authentication method, we recommend that you implement multiple authentication methods on the default zone. The result is the same URL for all users.

當在同一區域實作多種驗證方法時,將有下列限制:When you implement multiple authentication methods on the same zone, the following restrictions apply:

  • 您只能在一個區域上實作一個表單型驗證的執行個體。You can implement only one instance of forms-based authentication on a zone.

  • 管理中心需允許您同時使用整合式 Windows 方法及基本驗證,否則無法在同一區域上實作多種 Windows 驗證類型。Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, you cannot implement more than one type of Windows authentication on a zone.

如果伺服器陣列設定了多個 SAML 權杖型驗證提供者,在您建立 Web 應用程式或新的區域時,這些提供者都會變成選項。您可以在相同區域上設定多個 SAML 提供者。If multiple SAML token-based authentication providers are configured for a farm, all appear as options when you create a web application or a new zone. You can configure multiple SAML providers on the same zone.

下圖顯示合作夥伴共同作業網站預設區域上所實作的多種驗證類型。The following diagram shows multiple types of authentication implemented on the default zone for a partner collaboration site.

在預設區域執行多種驗證類型Multiple types of authentication implemented on the default zone


在此圖中,來自不同目錄存放區的使用者使用相同 URL 存取合作夥伴網站。以虛線方框框住合作夥伴公司,表示使用者目錄與預設目錄所設定的驗證類型之間的關係。In the diagram, users from different directory stores use the same URL to access the partner web site. The dashed box that surrounds partner companies shows the relationship between the user directory and the authentication type that is configured in the default zone.

規劃編目內容Planning to crawl content

編目元件需要 NTLM 存取內容。必須至少有一個區域設為使用 NTLM 驗證。如果預設區域並未設定 NTLM 驗證,編目元件可以使用其他設為使用 NTLM 驗證的區域。The crawl component requires NTLM to access content. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

實作多個區域Implement more than one zone

若要為 Web 應用程式實作多個區域,請使用下列準則:If you plan to implement more than one zone for web applications, use the following guidelines:

  • 使用預設區域實作最安全的驗證設定。若某要求無法與特定區域相關聯,將會套用預設區域的驗證設定及其他安全性原則。預設區域是建立 Web 應用程式時所建立的區域。通常會針對使用者存取,設計最安全的驗證設定。因此,使用者可能會存取預設區域。Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you create a web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end-users are likely to access the default zone.

  • 使用能夠提供使用者存取所需的最少區域數目。每個區域都要與新 IIS 網站及網域產生關聯,以便存取 Web 應用程式。只有在需要新的存取點時才新增。Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the web application. Only add new access points when they are required.

  • 請確定至少有一個區域設為使用 NTLM 驗證,以供編目元件使用。若非必要,請勿建立索引元件的專用區域。Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless it is necessary.

下圖顯示實作多個區域,以滿足合作夥伴共同作業網站的多種驗證類型需求。The following diagram shows multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

每種驗證類型一個區域One zone per authentication type


在此圖中,預設區域係供遠端員工使用。每個區域都有不同的相關聯 URL。員工視其位於辦公室工作或遠端工作,而使用不同區域。In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether they are working in the office or are working remotely.