SharePoint Server で Kerberos 認証を計画する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Kerberos プロトコルでは、信頼されたソースが提供するチケットを使用する認証方法がサポートされています。 Kerberos チケットは、クライアント コンピューターに関連付けられているユーザーのネットワーク資格情報が認証されたことを示します。 Kerberos プロトコルは、ユーザーがネットワーク サービスと対話してネットワーク リソースにアクセスする方法を定義します。 Kerberos キー配布センター (KDC) は、ユーザーの代わりにチケット許可チケット (TGT) をクライアント コンピューターに発行します。 Windows では、クライアント コンピューターは Active Directory Domain Services (AD DS) ドメインのメンバーであり、TGT はドメイン コントローラーがユーザー資格情報を認証したことを証明します。
ネットワーク サービスにネットワーク接続を確立する前に、クライアント コンピューターは、KDC にその TGT を示して、サービス チケットを要求します。 クライアント コンピューターが認証されたことを確認する、以前に発行された TGT に基づいて、KDC はクライアント コンピューターにサービス チケットを発行します。 次に、クライアント コンピューターは、ネットワーク サービスにサービス チケットを提出します。 また、サービス チケットは、サービスを識別する、適切なサービス プリンシパル名 (SPN) を含む必要があります。 Kerberos 認証を有効にするには、クライアント コンピューターとサーバー コンピューターが KDC との間に信頼できる接続を確立していることが必要です。 また、クライアントおよびサーバーコンピューターは、AD DS にアクセスできる必要があります。
Kerberos 認証と SharePoint Server
Kerberos 認証を検討すべき理由は、以下のとおりです。
Kerberos プロトコルは最も強力な統合 Windows 認証プロトコルであり、クライアントおよびサーバーの高度暗号化標準 (AES) 暗号、相互認証などの高度なセキュリティ機能をサポートしています。
Kerberos プロトコルを使用すると、クライアントの資格情報の委任を行うことができます。
安全な認証方法の中でも Kerberos は AD DS ドメイン コントローラーへのトラフィックが最も少なくて済む方法です。 Kerberos では、特定のシナリオでページの遅延を減らすことができ、状況によってはフロントエンド Web サーバーの処理ペース数を増やすことができます。 Kerberos はドメイン コントローラーへの負荷を減らすこともできます。
Kerberos プロトコルは、多くのプラットフォームやベンダーがサポートしているオープン プロトコルです。
Kerberos 認証が適切ではないかもしれない状況は、以下のとおりです。
他の認証方法とは対照的に、Kerberos 認証では、正しく機能するために追加のインフラストラクチャと環境構成が必要です。 多くの場合、Kerberos 認証を構成するには、ドメイン管理者のアクセス許可が必要です。設定と管理が困難な場合があります。 Kerberos を誤って構成すると、サイトへの認証がうまく行われません。
Kerberos 認証では、KDC および AD DS ドメイン コントローラーにクライアント コンピューターが接続できる必要があります。 Windows および SharePoint 展開では、AD DS ドメイン コントローラーが KDC となります。 これは組織のイントラネットでは一般的なネットワーク構成ですが、インターネットと対面する展開は、通常、この構成ではありません。
Kerberos 委任
Kerberos 認証は、クライアント ID の委任をサポートしています。 これは、サービスが認証対象クライアントの ID を偽装できることを意味します。 偽装により、サービスはクライアント用に認証対象の ID を他のネットワーク サービスに渡すことが可能になります。 クレームベース認証もクライアント資格情報の委任に使用できますが、バックエンドのアプリケーションがクレーム対応である必要があります。
SharePoint Server と共に使用することで Kerberos 委任では、フロントエンド サービスがクライアントを認証し、さらにクライアントの ID を使用してバックエンド システムを認証できます。 その後、バックエンド システムはそれ独自の認証を行います。 クライアントが Kerberos 認証を使用してフロントエンド サービスとの認証を行うとき、Kerberos 委任を使用すれば、クライアントの ID をバックエンド システムに渡すことができます。 Kerberos プロトコルは次の 2 種類の委任をサポートしています。
基本 Kerberos 委任 (制約なし)
Kerberos の制限付き委任
基本 Kerberos 委任と Kerberos の制限付き委任
基本 Kerberos 委任は、同じフォレスト内のドメイン境界を越えることができますが、フォレスト境界を越えることはできません。 Windows Server 2012 を実行するドメイン コントローラーを使用している場合以外、Kerberos の制約付き委任は、ドメインまたはフォレスト境界を越えることはできません。
SharePoint Server 展開の一部であるサービス アプリケーションによっては、SharePoint Server で Kerberos 認証を実装する目的で Kerberos の制限付き委任が必要になることがあります。
重要
次のいずれかのサービス アプリケーションで Kerberos 認証を展開するには、SharePoint Server とすべての外部データ ソースが同じ Windows ドメインに存在する必要があります。 > InfoPath Forms Services Visio Services > PerformancePoint Services Excel Services >>> これらのサービス アプリケーションは、SharePoint Foundation 2013 では使用できません。 Excel Services is not available in SharePoint Server 2016.
Kerberos 認証を以下のいずれかのサービス アプリケーションまたは製品で展開するには、SharePoint Server が基本 Kerberos 委任または Kerberos の制限付き委任を使用できる必要があります。
Business Data Connectivity Service (このサービス アプリケーションは SharePoint Foundation 2013では使用できません)
Access Services (このサービス アプリケーションは SharePoint Foundation 2013では使用できません)
SQL Server Reporting Services (SSRS) (独立した製品)
Project Server 2016 (独立した製品)
Kerberos 認証に対応したサービスでは、ID を、複数回、委任できます。 ID がサービスからサービスへと伝えられていくと、委任方法が基本 Kerberos から Kerberos の制限付きに変更されることがあります。 ただし、逆方向の変更はできません。 委任方法を Kerberos の制限付きから基本 Kerberos に変更することはできません。 このことから、基本 Kerberos 委任を必要とするようなバックエンド サービスが存在しないか事前に確認しておくことが重要です。 これはドメイン境界の計画と設計に影響することがあります。
Kerberos 対応サービスでは、プロトコル遷移を使用して非 Kerberos ID を、他の Kerberos 対応サービスに委任できる Kerberos ID に変換できます。 たとえば、この機能を利用すると、非 Kerberos ID をフロントエンド サービスからバックエンド サービスの Kerberos ID に委任できます。
重要
プロトコル遷移には Kerberos の制限付き委任が必要です。 このことから、プロトコル遷移による ID はドメイン境界を通過できません。
要求ベースの認証は、Kerberos 委任の代わりに使用できます。 要求ベースの認証を使用すると、サービスが次のすべての条件を満たしている場合に、クライアントの認証要求を異なるサービス間で渡すことができます。
これらのサービスの間に信頼関係が存在すること。
サービスがクレーム対応であること。
Kerberos 認証の詳細については、以下のリソースを参照してください。
Kerberos 認証とクレームベース認証
SharePoint 2013 と SharePoint Server 2016 はクレームベース認証をサポートしています。 クレームベース認証は、クレームベースの ID を実装する目的で使用される一連の .NET Framework クラスである Windows Identity Foundation (WIF) に基づいています。 クレームベース認証では、WS-Federation、WS-Trust などの標準が利用されます。 クレームベース認証の詳細については、以下を参照してください。
サーバーの全体管理を使用して UNRESOLVED_TOKEN_VAL(SharePoint Server) Web アプリケーションを作成するとき、1 つまたは複数のクレームベース認証の種類を選択する必要があります。 New-SPWebApplication Microsoft PowerShell コマンドレットを使用して UNRESOLVED_TOKEN_VAL(SharePoint Server) Web アプリケーションを作成するとき、クレーム認証とクレーム認証の種類、またはクラシック モード認証を指定できます。 クレーム認証がすべての UNRESOLVED_TOKEN_VAL(SharePoint Server) Web アプリケーションで推奨されます。 クレーム認証を使用することにより、すべてのサポートされる認証の種類が Web アプリケーションで使用可能になり、サーバー間認証とアプリ認証を活用できます。 詳細については、「 What's new in authentication for SharePoint Server 2013」を参照してください。
重要
The following service applications in SharePoint Server require the translation of claims-based credentials to Windows credentials. この翻訳プロセスでは、Windows トークン サービスへの要求 (C2WTS): >Excel Services>PerformancePoint Services>InfoPath Forms Services>Visio Services>> これらのサービス アプリケーションは SharePoint Foundation 2013 では使用できません。 Excel Services is not available in SharePoint Server 2016.
C2WTS を必要とするサービス アプリケーションでは、Kerberos 制約付き委任でのみサポートされるプロトコル遷移が必要であるため、Kerberos 制約付き委任を使用する必要があります。 前の一覧のサービス アプリケーションの場合、C2WTS はファーム内の要求を送信認証用の Windows 資格情報に変換します。 これらのサービス アプリケーションは、受信認証方法が Windows 要求または Windows クラシック モードの場合にのみ C2WTS を使用できることを理解しておくことが重要です。 Web アプリケーションを介してアクセスされ、セキュリティ アサーション マークアップ言語 (SAML) 要求またはフォーム ベースの認証要求を使用するサービス アプリケーションでは、C2WTS は使用されません。 そのため、要求を Windows 資格情報に変換することはできません。
Kerberos 認証と新しい SharePoint アプリケーション モデル
ユーザー認証に Windows クレームモードを使用しており、Web アプリケーションが、認証プロトコルとして NTLM にフォールバックせずに、Kerberos 認証だけを使用するように設定されている場合は、アプリ認証が機能しません。 詳細については、「SharePoint Server でアプリ認証を計画する」を参照してください。