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.

概要Introduction

ユーザー認証は、認証プロバイダーに対して、ユーザーの ID を検証することです。認証プロバイダーは、ユーザーの資格情報を含むディレクトリまたはデータベースで、ユーザーが適切な資格情報を提出したか確認できます。認証プロバイダーの一例は、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.

認証方式とは、ユーザーの ID を証明するアカウント資格情報およびその他の情報のやり取りのことを指します。認証方式の結果は、一般的には、認証プロバイダーがユーザーを認証したというクレームを含むトークンの形式の証明になります。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.

認証の種類とは、時には業界標準プロトコルを使用して、1 つまたは複数の認証プロバイダーに対して資格情報を確認する特定の方法です。認証の種類では、複数の認証方式を使用できます。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.

ユーザー ID の検証後、ユーザーがアクセスできるサイト、コンテンツ、および機能が承認プロセスによって決定されます。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

    注意

    Windows クラシック モード認証は、SharePoint Server 2016 ではサポートされなくなりました。Windows classic mode authentication is no longer supported in SharePoint Server 2016.

クレーム ベース認証Claims-based authentication

AD DS 内のユーザー ID は、ユーザー アカウントに基づきます。適切な認証では、ユーザーはアカウント名とパスワードを提出します。リソースへのアクセスを決定する目的で、アプリケーションは、ネットワーク上でのグループ メンバーシップまたは役割のような、アカウント属性とその他の情報について 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.

クレームベース ID では、ユーザーは、一般的に、信頼できる ID プロバイダーからデジタル署名セキュリティ トークンを取得します。トークンには一連のクレームが含まれます。各クレームは、ユーザーの名前、グループ メンバーシップ、およびネットワーク上の役割のような、ユーザーについてのデータの特定のアイテムを表します。クレームベース認証は、クレームベースの ID テクノロジとインフラストラクチャを使用するユーザー認証です。クレームベース認証をサポートするアプリケーションは、資格情報の代わりに、ユーザーからセキュリティ トークンを取得し、クレーム内のその情報を使用してリソースへのアクセスを決定します。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 でのクレームベース認証は、クレームベースの ID を実装する目的で使用される一連の .NET Framework クラスである Windows Identity Foundation (WIF) に基づいています。クレームベース認証では、WS-Federation、WS-Trust などの標準や、SAML (Security Assertion Markup Language) などのプロトコルが利用されます。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 ではすべてのユーザー アカウントを自動的にクレーム ID に変更します。これによって、各ユーザーのセキュリティ トークン (別名クレーム トークン) を生成します。クレーム トークンには、ユーザーに関するクレームが含まれています。Windows アカウントは Windows クレームに変換され、フォームベースのメンバーシップ ユーザーはフォームベースの認証クレームに変換されます。SharePoint Server では、SAML ベースのトークンに含まれるクレームを使用できます。また、SharePoint の開発者および管理者は、ユーザー トークンを追加のクレームで強化できます。たとえば、Windows ユーザーのアカウントとフォームベース アカウントを、SharePoint Server が使用する追加のクレームで強化できます。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 コマンドレットを使用して作成する必要があります。クラシック モード認証用に構成された SharePoint 2010 製品 Web アプリケーションは、SharePoint 2013にアップグレードしたとき、その認証設定を保持します。しかし、SharePoint 2013にアップグレードする前に、Web アプリケーションをクレームベース認証に移行することを推奨します。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.

アップグレードする前に移行することの詳細については、「SharePoint 2013 でクラシックモードからクレームベース認証に移行する」を参照してください。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 アプリケーションを作成する方法については、「クラシック モード認証を使用する Web アプリケーションを作成する (SharePoint Server)」を参照してください。クレームベース認証を使用する 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.

重要

Office Online は、クレームベース認証を使用する SharePoint 2013 Web アプリケーションでのみ使用できます。クラシック モード認証を使用する SharePoint 2013 Web アプリケーションでは、Office Online の表示と編集は正常に機能しません。クラシック モード認証を使用する SharePoint 2010 Web アプリケーションを SharePoint 2013 に移行する場合は、それらの Web アプリケーションが 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:

  • NTLMNTLM

  • 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

Windows 認証の種類ではありませんが、SharePoint Server は、匿名認証もサポートします。ユーザーは、自分の資格情報を確認されることなく SharePoint コンテンツにアクセスできます。匿名認証は既定で無効です。一般的には、公開されたインターネット Web サイトのような、セキュリティを必要とせず、すべてのユーザーが使用可能なコンテンツを発行する際に 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 アプリケーションを提供するために SharePoint によって作成された インターネット インフォメーション サービス (IIS) Web サイトでは、匿名認証とフォーム認証のメソッドが常に有効になります。   これは意図的なものであり、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

フォームベース認証は、ASP.NET のメンバーシップ プロバイダーとロール プロバイダーの認証に基づく、クレームベース ID 管理システムです。フォーム ベース認証は、以下のような、認証プロバイダーに保存される資格情報に対して使用できます。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:

  • AD DSAD DS

  • SQL Server データベースのようなデータベースA database such as a SQL Server database

  • Novell eDirectory、NDS (Novell Directory Services)、または Sun ONE のような LDAP (ライトウェイト ディレクトリ アクセス プロトコル) データ ストアAn Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE

フォーム ベース認証では、ユーザーがログオン フォーム (一般的には Web ページ) で入力する資格情報に基づいてユーザーを検証します。認証されていない要求はログオン ページにリダイレクトされ、ユーザーは有効な資格情報を提供して、フォームを提出する必要があります。後続の要求の ID を再確立するキーを含む 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

注意

フォーム ベース認証では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。したがって、Web サイト トラフィックを暗号化する SSL (Secure Sockets Layer) を使用していない場合は、フォーム ベース認証を使用しないでください。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-Federation パッシブ リクエスター プロファイル (WS-F PRP) を使用します。SAML トークンベース認証では、独自の内部環境とパートナーの環境のどちらの場合でも、クレームベース環境の管理者との連携が必要です。Active Directory フェデレーション サービス (ADFS) 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 トークンベース認証環境には、ID プロバイダー セキュリティ トークン サービス (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 2008 のすべてのエディションAll 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-Federation 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 リソースにアクセスするサービスまたはアプリケーションは、既定でプロセスの ID である実行中のスレッドの資格情報を使用して、認証を試みます。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 では、特定のシナリオでページの遅延を減らすことができ、状況によってはフロントエンド Web サーバーの処理ペース数を増やすことができます。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 展開では、AD DS ドメイン コントローラーが KDC となります。これは組織のイントラネットでは一般的なネットワーク構成ですが、インターネットと対面する展開は、通常、この構成ではありません。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 サービス アカウント用の SPN を AD DS で作成することにより、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

ダイジェスト認証方式では、ユーザー アカウント資格情報は、Web アプリケーションまたはゾーンをホストする Web サーバー上のインターネット インフォメーション サービス (IIS) サービスに、MD5 メッセージ ダイジェストとして送信されます。基本認証方式では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。したがって、Web サイト トラフィックを暗号化する SSL (Secure Sockets Layer) を使用していない場合は、基本認証方式を使用しないでください。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.

現在の環境が、Web サイトに対してダイジェストまたはベーシックな認証のみをサポートする Web ブラウザーまたはサービスを使用している場合、これらの旧式の認証方式を使用する必要があることがあります。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、および匿名認証方式と異なり、ダイジェストおよび基本認証方式は、インターネット インフォメーション サービス (IIS) スナップインで Web アプリケーションまたはゾーンに対応する、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 ベースでない ID 管理システムや外部の ID 管理システムに対するユーザー認証にフォームベース認証を使用するには、メンバーシップ プロバイダーとロール マネージャーを Web.config ファイルに登録する必要があります。SharePoint Server では、標準の ASP.NET ロール マネージャー インターフェイスを使用して、現在のユーザーに関するグループ情報を収集します。SharePoint Server の承認プロセスは、各 ASP.NET ロールを 1 つのドメイン グループのように処理します。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 サイトからメンバーシップ ユーザーやロールを管理する場合は、サーバーの全体管理 Web サイトの Web.config ファイルにメンバーシップ プロバイダーとロール マネージャーを登録する必要があります。また、コンテンツをホストする Web アプリケーションの Web.config ファイルにもメンバーシップ プロバイダーとロール マネージャーを登録する必要があります。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 からエクスポートする証明書です。証明書は、ファーム内の 1 つのサーバーにコピーされ、ファームの信頼できるルート証明機関リストに追加されます。この証明書を使用して 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.

  • ID クレーム SAML トークンからのクレームで、ユーザーの一意の ID です。ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者だけです。ID クレームは、必要なすべてのクレームをマッピングの中で、標準のクレーム マッピングとして作成されます。ID クレームとしての役割を果たすクレームは、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 クレーム アーキテクチャで、SAML トークンベース プロバイダーを使用するように構成されている SharePoint Web アプリケーションに関連付けられた URI または URL が、領域を表します。ファーム上で SAML トークンベース認証プロバイダーを作成するときに、IP-STS が認識する領域、つまり Web アプリケーションの URL を 1 つずつ指定します。最初の領域は、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 の作成時に、使用するトークン署名証明書、最初の領域、ID クレームに相当するクレーム、および追加のクレームを指定します。STS からのトークン署名証明書は、1 つの 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.

  • 証明書利用者 STS (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.

  • ID プロバイダー STS (IP-STS) 関連するユーザー ディレクトリ内のユーザーに代わって SAML トークンを発行する、クレーム環境内の Secure Token Service です。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:

  • 単一 ID クレーム。A single identity claim.

  • 単一 SignInURL パラメーター。A single SignInURL parameter.

    SignInURL パラメーターは、IP-STS に認証するためにユーザー要求をリダイレクトする先の URL を指定します。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 が既定値です。 Wreply パラメーターは、IP-STS によって要求されている場合にの使用します。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. ユーザーの一意識別子として使用するクレームを定義します。これは ID クレームと呼ばれます。ユーザー プリンシパル名 (UPN) またはユーザーの電子メール名がユーザー ID としてしばしば使用されます。ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者のみなので、IP-STS の管理者と連携して適切な ID を決定します。ユーザーの一意識別子の識別は、クレーム マッピング プロセスに含まれます。クレーム マッピングを作成するには、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 が作成されます。このプロセスの中で、マップした ID クレームと追加のクレームを指定します。SAML トークンベース認証用に構成している最初の SharePoint Web アプリケーションに関連する領域を、作成および指定する必要もあります。 SPTrustedIdentityTokenIssuer を作成した後で、さらに別の SharePoint Web アプリケーション用の領域を作成および追加することもできます。このようにして、同じ SPTrustedIdentityTokenIssuer を使用する複数の Web アプリケーションを構成します。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 アプリケーションを作成したとき、認証プロバイダーはサーバーの全体管理で信頼できる ID プロバイダーとして表示されます。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 トークンベース認証プロバイダーを構成できます。ただし、トークン署名証明書を使用できるのは、ファーム内で 1 回のみです。すべての構成済みのプロバイダーが、サーバーの全体管理にオプションとして表示されます。異なる信頼できる 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.

注意

SAML トークン ベース認証を使用するように Web アプリケーションが構成されている場合、ユーザー選択ウィンドウ コントロールに対する検索機能が 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.

AD FS を使用して 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 アプリケーションには、最大で 5 つのゾーンを含めることができます。Web アプリケーションの作成時に、サーバーの全体管理は "既定" という名前のゾーンを作成します。追加のゾーンを作成するには、Web アプリケーションを拡張し、残りのゾーン名の 1 つ (イントラネット、エクストラネット、インターネット、またはカスタム) を選択します。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:

  • 1 つのゾーンには、フォームベース認証の 1 つのインスタンスのみ実装できます。You can implement only one instance of forms-based authentication on a zone.

  • サーバーの全体管理では、統合 Windows 方式と基本方式の両方を同時に使用できます。これ以外の場合、1 つのゾーンに複数の 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 を使用してパートナーの Web サイトにアクセスしています。パートナー企業を囲む点線のボックスは、ユーザー ディレクトリと、既定のゾーン内で構成されている認証の種類との間の関係を示しています。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 を必要とします。少なくとも 1 つのゾーンを、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.

  • ユーザーにアクセスを提供するのに必要な最小限度のゾーンを使用します。各ゾーンは、Web アプリケーションにアクセスする新規 IIS サイトとドメインに関連付けられます。必要な場合のみ、新しいアクセス ポイントを追加します。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.

  • 少なくとも 1 つのゾーンに、クロール コンポーネント用の 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.

認証の種類ごとに 1 つのゾーンOne zone per authentication type

各種類の認証に対して 1 つのゾーン

図の中で、既定のゾーンはリモートの従業員用に使用されています。各ゾーンには、それぞれ異なる 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.