SharePoint Server で Kerberos 認証を計画する
適用対象: 
2013 2016 2019 サブスクリプション エディション 
Microsoft 365 の SharePoint
Kerberos プロトコルは、信頼できるソースが提供するチケットを使用する認証方法をサポートします。Kerberos チケットは、特定のクライアント コンピューターに関連付けられたユーザーのネットワーク資格情報が認証済みであることを表します。Kerberos プロトコルは、ユーザーがネットワーク リソースにアクセスする目的でネットワーク サービスを操作する方法を定義します。Kerberos キー配布センター (KDC) は、ユーザーの代理で、クライアント コンピューターにチケット保証チケット (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 を誤って構成すると、サイトへの認証がうまく行われません。
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 ドメインに置いておく必要があります。 > Excel Services > PerformancePoint Services > InfoPath Forms Services > Visio Services > これらのサービス アプリケーションは、SharePoint Foundation 2013 では使用できません。Excel Services は、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 委任の代替方法として使用することもできます。クレームベース認証では、クライアントの認証クレームが 2 つの異なるサービスの間で引き渡されます。ただし、これらのサービスは以下の条件をすべて満たしている必要があります。
これらのサービスの間に信頼関係が存在すること。
サービスがクレーム対応であること。
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」を参照してください。
重要
SharePoint Server の以下のサービス アプリケーションでは、クレーム ベースの資格情報を Windows 資格情報に変換する必要があります。この変換プロセスでは Claims to Windows Token Service (C2WTS) が使用されます。Excel Services> PerformancePoint Services> InfoPath Forms Services> Visio Services> > このサービス アプリケーションは SharePoint Foundation 2013 では使用できません。Excel Services は、SharePoint Server 2016 では使用できません。
C2WTS を必要とするこれらのサービス アプリケーションでは、Kerberos の制限付き委任を使用しなければなりません。これは、C2WTS でプロトコル遷移が必要で、プロトコル遷移は Kerberos の制限付き委任でのみサポートされているからです。前出のサービス アプリケーションの場合、C2WTS は送信認証の目的でファーム内のクレームを Windows 資格情報に変換します。これらのサービス アプリケーションが C2WTS を利用できるのは、受信認証方法が Windows クレームベースか Windows クラシック モードの場合に限られることに注意してください。サービス アプリケーションが Web アプリケーション経由でアクセスされる場合と、SAML (Security Assertion Markup Language) クレームまたはフォームベース認証クレームを使用する場合は、C2WTS を使用しません。このことから、クレームを Windows 資格情報に変換することはできません。
Kerberos 認証と新しい SharePoint アプリケーション モデル
ユーザー認証に Windows クレームモードを使用しており、Web アプリケーションが、認証プロトコルとして NTLM にフォールバックせずに、Kerberos 認証だけを使用するように設定されている場合は、アプリ認証が機能しません。詳細については、「SharePoint Server でアプリ認証を計画する」を参照してください。