適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
ユーザーが Web アプリケーションに接続しようとして認証に失敗した場合は、その認証イベントがログに記録されます。 Microsoft によって提供されているツールを使用して体系的な手法で失敗について調べると、クレーム ベース認証に関連する一般的な問題について理解を深め、解決することができます。
SharePoint リソースに正常にアクセスするには、認証と承認の両方が必要です。 要求を使用している場合、認証によってセキュリティ トークンが有効であることが確認されます。 承認によって、セキュリティ トークン内の一連のクレームとリソースに対する構成済みの権限に基づいて、リソースへのアクセスが許可されることが確認されます。
認証と承認のどちらがアクセスの問題の原因になっているかを判断するには、ブラウザー ウィンドウのエラー メッセージをよく確認してください。
ユーザーがサイトにアクセスできないことを示すエラー メッセージが表示された場合、認証は成功し、承認は失敗しました。 承認のトラブルシューティングを行うには、次の解決策を試します。
セキュリティ アサーション マークアップ言語 (SAML) 要求ベースの認証を使用している場合に承認が失敗した最も一般的な理由は、アクセス許可がユーザーの SAML ID 要求ではなく、ユーザーの Windows ベースのアカウント (ドメイン\ユーザー) に割り当てられたためです。
ユーザーまたはそのユーザーの属しているグループが適切な権限を使用するように構成されていることを確認します。 詳細については、「SharePoint Server でのユーザー アクセス許可とアクセス許可レベル」を参照してください。
この記事に示すツールや手法を使用してユーザーのセキュリティ トークン内の一連のクレームを確認し、構成済みの権限と比較できるようにします。
メッセージが認証に失敗したことを示している場合は、認証の問題が発生しています。 クレーム ベース認証を使用する SharePoint Web アプリケーション内にリソースが含まれている場合は、この記事の情報を使用してトラブルシューティングを開始します。
トラブルシューティング ツール
以下に、SharePoint Server のクレーム認証に関する情報を収集するために Microsoft によって提供されている主なトラブルシューティング ツールを示します。
統合ログ システム (ULS) ログを使用すると、認証トランザクションの詳細を取得できます。
サーバーの全体管理を使用すると、SharePoint Web アプリケーションおよび領域のユーザー認証設定の詳細を確認し、ULS ログ レベルを構成することができます。
セキュリティ アサーション マークアップ言語 (SAML) ベースの要求認証のフェデレーション プロバイダーとして Active Directory フェデレーション サービス (AD FS) 2.0 (AD FS) を使用している場合は、AD FS ログを使用して、AD FS が Web クライアント コンピューターに発行するセキュリティ トークン内の要求を特定できます。
Network Monitor 3.4 を使用すると、ユーザー認証ネットワーク トラフィックの詳細を取得して調べることができます。
ユーザー認証の ULS ログ レベルの設定
クレーム認証の試行に関してログに記録する情報量が最大になるように SharePoint Server を構成するには、以下の手順を実行します。
ユーザー認証のログの量が最大になるように SharePoint Server を構成するには
サーバーの全体管理から、サイド リンク バーで [ 監視 ] を選択し、[ 診断ログの構成] を選択します。
カテゴリの一覧で [SharePoint Foundation] を展開し、[認証承認] および [クレーム認証] を選択します。
[イベント ログの記録対象となる重要度の最も低いイベント] で、[詳細] を選択します。
[トレース ログの記録対象となる重要度の最も低いイベント] で、[詳細] を選択します。
[OK] を選択します。
要求認証のトラブルシューティングを実行していない場合にパフォーマンスを最適化するには、次の手順に従って、ユーザー認証ログを既定値に設定します。
ユーザー認証のログの量が既定になるように SharePoint Server を構成するには
サーバーの全体管理から、サイド リンク バーで [ 監視 ] を選択し、[ 診断ログの構成] を選択します。
カテゴリの一覧で [SharePoint Foundation] を展開し、[認証承認] および [クレーム認証] を選択します。
[イベント ログの記録対象となる重要度の最も低いイベント] で、[情報] を選択します。
[トレース ログの記録対象となる重要度の最も低いイベント] で、[中] を選択します。
[OK] を選択します。
AD FS ログの構成
最大レベルの ULS ログを有効にした後でも、SharePoint Server では受け取ったセキュリティ トークン内の一連のクレームは記録されません。 SAML ベースのクレーム認証用に AD FS を使用する場合は、AD FS ログを有効にしてイベント ビューアーを使用し、SharePoint Server が発効したセキュリティ トークンのクレームを調べることができます。
AD FS ログの有効化
AD FS サーバーで、イベント ビューアーから [表示] を選択し、[分析ログとデバッグ ログの表示] を選択します。
イベント ビューアー コンソール ツリーで [ アプリケーションとサービス ログ]、[AD FS 2.0 トレース] の順に展開します。
[ デバッグ] を右クリックし、[ ログの有効化] を選択します。
%ProgramFiles% \Active Directory Federation Services 2.0 フォルダーを開きます。
メモ帳を使用して Microsoft.IdentityServer.ServiceHost.Exe.Config ファイルを開きます。
[編集] を選択し、[検索] を選択し、「<source name="Microsoft.IdentityModel" switchValue="Off">」と入力し、[OK] を選択します。
「switchValue="Off"」を「switchValue="Verbose"」に変更します。
[ ファイル] を選択 し、[保存] を選択し、メモ帳を終了します。
[サービス] スナップインで** AD FS 2.0 サービス **を右クリックし、[再起動] を選択 します。
これで、AD FS サーバーでイベント ビューアーを使用して、[アプリケーションとサービス ログ]、[AD FS 2.0 Tracing] (AD FS 2.0 トレース)、[デバッグ] ノードからクレームに関する詳細を調べることができます。 イベント ID 1001 のイベントを探してください。
また、HttpModule か Web パーツ、または OperationContext によってクレームを列挙することもできます。 詳細については、「SharePoint 2010 でクレーム拡張時にすべてのユーザー クレームを取得する方法」をご覧ください。 SharePoint 2010 に関するこの情報は、SharePoint 2013 にも適用されます。
クレーム ユーザー認証のトラブルシューティング方法
以下の手順は、クレーム認証に失敗した場合の原因の特定に役立ちます。
手順 1: 失敗した認証の詳細を確認する
失敗した認証に関する決定的な詳細情報を取得するには、SharePoint ULS ログで確認する必要があります。 このログ ファイルは、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS フォルダーに保存されています。
失敗した認証を ULS ログ ファイルで手動で確認するか、ULS Log Viewer を使用できます。
失敗した認証を手動で確認するには
認証に失敗したユーザー アカウント名をそのユーザーから入手します。
SharePoint Server または SharePoint Foundation を実行しているサーバーで、%CommonProgramFiles% \Microsoft Shared\Web Server Extensions\16\LOGS または %CommonProgramFiles% \Microsoft Shared\Web Server Extensions\15\LOGS フォルダーを見つけます。
LOGS フォルダーで、[変更日] を選択して、フォルダーを日付で並べ替え、一番上に最新の日付を付けて並べ替えます。
認証タスクをもう一度試してください。
LOGS フォルダー ウィンドウの一覧の一番上にあるログ ファイルをダブルクリックし、メモ帳でファイルを開きます。
メモ帳で [編集] を選択し、[検索] を選択し、「認証承認」または「クレーム認証」と入力して、[次の検索] を選択します。
[ キャンセル] を選択し、[ メッセージ ] 列の内容を読み取ります。
ULS Viewer を使用するには、「ULS Viewer」からダウンロードし、SharePoint Server または SharePoint Foundation を実行しているサーバーのフォルダーに保存します。 インストール後、次の手順に従って、失敗した認証試行を見つけます。
ULS Viewer を使用して失敗した認証を確認するには
SharePoint Server または SharePoint Foundation を実行しているサーバーで、格納されているフォルダーから Ulsviewer をダブルクリックします。
ULS ビューアーで [ファイル] を選択し、[開く] をポイントし、[ULS] を選択します。
[ULS ランタイム フィードのセットアップ] ダイアログで、[既定のログ ファイル ディレクトリから ULS フィードを使用する] で 、%CommonProgramFiles% \Common Files\Microsoft Shared\Web Server Extensions\16\LOGS フォルダーまたは \Common Files\Microsoft Shared\Web Server Extensions\15\LOGS フォルダーが指定されていることを確認します。 そうでない場合は、[ディレクトリの場所をリアルタイム フィードに使用する] を選択し、[ログ ファイルの場所] で %CommonProgramFiles% \Microsoft Shared\Web Server Extensions\16\LOGS フォルダーまたは \Microsoft Shared\Web Server Extensions\15\LOGS フォルダーを指定します。
%CommonProgramFiles% は、SharePoint Server または SharePoint Foundation を実行しているサーバーの CommonProgramFiles 環境変数の値に置き換えます。 たとえば、その場所が C ドライブの場合は、%CommonProgramFiles% を C:\Program Files\Common Files に設定します。
[OK] を選択します。
[ 編集] を選択し、[ フィルターの変更] を選択します。
[ フィルター処理 ] ダイアログの [ フィールド] で、[カテゴリ] を選択 します。
[ 値] に「 Authentication Authorization」 または「 Claims Authentication」と入力し、[ OK] を選択します。
認証の試行を繰り返します。
ULS Viewer ウィンドウで表示された行をダブルクリックし、[Message] (メッセージ) 部分を表示します。
OAuth 以外の要求に対するメッセージのクレーム エンコード部分で、クレーム エンコード文字列 (例: i:0#.w|contoso\chris) から認証方法とエンコードされたユーザー ID を特定できます。
手順 2: 構成要件を確認する
1 つ以上のクレーム認証方法をサポートするために Web アプリケーションまたは領域がどのように構成されているかを確認するには、SharePoint サーバーの全体管理 Web サイトを使用します。
Web アプリケーションまたは領域の認証構成を確認するには
サーバーの全体管理から、サイド リンク バーで [アプリケーション管理 ] を選択し、[ Web アプリケーションの管理] を選択します。
ユーザーがアクセスしようとしている Web アプリケーションの名前を選択し、リボンの [セキュリティ ] グループで [ 認証プロバイダー] を選択します。
認証プロバイダーの一覧で、適切なゾーン (既定など) を選択 します。
[ 認証の編集 ] ダイアログの [ 要求認証の種類 ] セクションで、要求認証の設定を確認します。
Windows クレーム認証の場合は、[Windows 認証の有効化] および [統合 Windows 認証] が選択されていることと、必要に応じて [NTLM] または [ネゴシエート (Kerberos)] が選択されていることを確認します。 必要に応じて [ 基本認証 ] を選択します。
フォーム ベース認証の場合は、[フォーム ベース認証 (FBA) の有効化] が選択されていることを確認します。 [ASP.NET メンバーシップ プロバイダー名] および [ASP.NET ロール マネージャー名] の値を確認します。 これらの値は、SharePoint サーバーの全体管理 Web サイト、Web アプリケーション、および SharePoint Web Services\SecurityTokenServiceApplication の web.config ファイルで構成したメンバーシップ プロバイダーとロールの値と一致する必要があります。 詳細については、「Configure forms-based authentication for a claims-based web application in SharePoint Server」を参照してください。
SAML ベースのクレーム認証の場合は、[ 信頼できる ID プロバイダー] および正しい信頼できるプロバイダー名が選択されていることを確認します。 詳細については、「Configure SAML-based claims authentication with AD FS in SharePoint Server」を参照してください。
[ サインイン ページの URL] セクションで、サインイン ページのオプションを確認します。 既定のサインイン ページについて、[既定のサインイン ページ] が選択されている必要があります。 ユーザー設定のサインイン ページについて、ユーザー設定のサインイン ページの指定された URL を確認します。 確認するには、URL をコピーし、Web ブラウザーを使用してその URL へのアクセスを試みます。
[ 保存] を 選択して、認証設定への変更を保存します。
認証の試行を繰り返します。 フォーム ベース認証または SAML ベース認証の場合は、予想されるサインイン ページが正しいサインイン オプションを使用して表示されるかを確認します。
それでも認証が失敗する場合は、ULS ログをチェックして、認証構成の変更前と後の認証試行に違いがあるかどうかを判断します。
手順 3: チェックするその他の項目
ログ ファイルと Web アプリケーション構成を確認した後、以下の項目を確認します。
Web クライアント コンピューターの Web ブラウザーでクレームがサポートされていること。 詳細については、「SharePoint Server 2016 でのブラウザー サポートの計画」を参照してください。
Windows クレーム認証の場合は、以下の項目を確認します。
ユーザーが認証を試行するコンピューターが、SharePoint Web アプリケーションをホストするサーバーと同じドメインのメンバー、またはホスト サーバーで信頼されているドメインのメンバーであること。
ユーザーが認証を試行するコンピューターが Active Directory ドメイン サービス (AD DS) ドメインにログオンしていること。 Web クライアント コンピューターのコマンド プロンプトまたは SharePoint 管理シェルで「 nltest /dsgetdc: /force 」と入力し、ドメイン コントローラーにアクセスできることを確認します。 ドメイン コントローラーが一覧表示されない場合は、Web クライアント コンピューターと AD DS ドメイン コントローラーが接続されておらず検出されないことをトラブルシューティングします。
SharePoint Server または SharePoint Foundation を実行しているサーバーが AD DS ドメインにログオンしていること。 SharePoint Server または SharePoint Foundation を実行しているサーバーのコマンド プロンプトまたは SharePoint 管理シェルで「 nltest /dsgetdc: /force 」と入力し、ドメイン コントローラーにアクセスできることを確認します。 ドメイン コントローラーが一覧表示されない場合は、SharePoint Server または SharePoint Foundation を実行しているサーバーと AD DS ドメイン コントローラーが接続されておらず検出されないことをトラブルシューティングします。
フォーム ベース認証の場合は、以下の項目を確認します。
構成されている ASP.NET メンバーシップ プロバイダーおよびロール プロバイダーのユーザー資格情報が正しいこと。
ASP.NET メンバーシップ プロバイダーおよびロール プロバイダーをホストするシステムがネットワーク上で利用可能なこと。
ユーザー設定のサインイン ページでユーザーの資格情報が正しく収集および伝達されること。 これをテストするには、一時的に既定のサインイン ページを使用するように Web アプリケーションを構成し、そのページが機能することを確認します。
SAML ベースのクレーム認証の場合は、以下の項目を確認します。
構成されている ID プロバイダーのユーザー資格情報が正しいこと。
フェデレーション プロバイダー (AD FS など) および ID プロバイダー (AD DS やサード パーティの ID プロバイダーなど) として機能するシステムがネットワーク上で利用可能なこと。
ユーザー設定のサインイン ページでユーザーの資格情報が正しく収集および伝達されること。 これをテストするには、一時的に既定のサインイン ページを使用するように Web アプリケーションを構成し、そのページが機能することを確認します。
手順 4: Web デバッグ ツールを使用して Web トラフィックを監視および分析する
HttpWatch や Fiddler などのツールを使用して、以下の種類の HTTP トラフィックを分析します。
Web クライアント コンピューターと SharePoint Server または SharePoint Foundation を実行しているサーバーの間のトラフィック
たとえば、フェデレーション サーバー (AD FS など) の場所を Web クライアント コンピューターに通知するために SharePoint Server または SharePoint Foundation を実行しているサーバーから送信される HTTP リダイレクト メッセージを監視できます。
Web クライアント コンピューターとフェデレーション サーバー (AD FS など) の間のトラフィック
たとえば、Web クライアント コンピューターから送信される HTTP メッセージと、セキュリティ トークンおよびそのクレームが含まれる可能性があるフェデレーション サーバーの応答を監視できます。
注:
Fiddler を使用する場合、認証は試行が 3 回要求された後失敗します。 この動作を回避するには、「SAML および SharePoint と共に Fiddler を使用する場合に認証の 3 回の試行に対処する方法」をご覧ください。
手順 5: 認証ネットワーク トラフィックを取得および分析する
Network Monitor 3.4 などのネットワーク トラフィック ツールを使用して、Web クライアント コンピューター、SharePoint Server または SharePoint Foundation を実行しているサーバー、および SharePoint Server または SharePoint Foundation がクレーム認証のために利用するシステムの間のトラフィックを取得および分析します。
注:
多くの場合、クレーム認証には、コンピューター間で送信されるメッセージを暗号化するハイパーテキスト転送プロトコル セキュア (HTTPS) ベースの接続が使用されます。 暗号化されたメッセージの内容をネットワーク トラフィック ツールで表示するには、アドインまたは拡張機能が必要です。 たとえば、ネットワーク モニターの場合は、Expert をインストールして ネットワーク モニターに構成する必要があります。 HTTPS メッセージの暗号化解除を試行する代わりに、SharePoint Server または SharePoint Foundation をホストするサーバーで Fiddler などのツールを使用すると、暗号化されていない HTTP メッセージのレポートを生成できるため簡単です。
ネットワーク トラフィックを分析すると、以下のことがわかります。
クレーム認証プロセスに関係するコンピューター間で送信されている正確な一連のプロトコルおよびメッセージ。 応答メッセージにはエラー条件情報を含めることができます。この情報を使用すると、より多くのトラブルシューティング手順を決定できます。
要求メッセージに対応する応答があるかどうか。 応答を受信しない複数の送信された要求メッセージは、ネットワーク トラフィックが目的の宛先に到達していないことを示すことができます。 その場合は、パケット ルーティングの問題、パスにあるパケット フィルター デバイス (ファイアウォールなど)、または接続先のパケット フィルター (ローカル ファイアウォールなど) を調べます。
複数のクレーム方法が試行されているかどうか、およびどの方法が失敗しているか。
Windows クレーム認証の場合は、以下のコンピューター間のトラフィックを取得および分析できます。
Web クライアント コンピューターと SharePoint Server または SharePoint Foundation を実行しているサーバー
SharePoint Server または SharePoint Foundation を実行しているサーバーとそのドメイン コントローラー
フォーム ベース認証の場合は、以下のコンピューター間のトラフィックを取得および分析できます。
Web クライアント コンピューターと SharePoint Server または SharePoint Foundation を実行しているサーバー
SharePoint Server または SharePoint Foundation を実行しているサーバーと ASP.NET メンバーシップ プロバイダーおよびロール プロバイダー
SAML ベースのクレーム認証の場合は、以下のコンピューター間のトラフィックを取得および分析できます。
Web クライアント コンピューターと SharePoint Server または SharePoint Foundation を実行しているサーバー
Web クライアント コンピューターとその ID プロバイダー (AD DS ドメイン コントローラーなど)
Web クライアント コンピューターとフェデレーション プロバイダー (AD FS など)
関連項目
その他のリソース
Configure forms-based authentication for a claims-based web application in SharePoint Server
Configure SAML-based claims authentication with AD FS in SharePoint Server