SharePoint Server のクレーム認証でユーザーが検証されない
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
ユーザーが Web アプリケーションに接続しようとして認証に失敗した場合は、その認証イベントがログに記録されます。 Microsoft によって提供されているツールを使用して体系的な手法で失敗について調べると、クレーム ベース認証に関連する一般的な問題について理解を深め、解決することができます。
SharePoint リソースに正常にアクセスするには、認証と承認の両方が必要です。 クレームを使用する場合は、認証によってセキュリティ トークンが有効であることが確認されます。 承認によって、セキュリティ トークン内の一連のクレームとリソースに対する構成済みの権限に基づいて、リソースへのアクセスが許可されることが確認されます。
認証と承認のどちらがアクセスの問題の原因になっているかを判断するには、ブラウザー ウィンドウのエラー メッセージをよく確認してください。
エラー メッセージがユーザーにサイトへのアクセス権がないことを示している場合は、認証には成功して承認に失敗しています。 承認のトラブルシューティングを行うには、次の解決策を試します。
Security Assertion Markup Language (SAML) クレーム ベース認証を使用している場合に承認に失敗する最も一般的な理由は、ユーザーの SAML ID クレームではなくユーザーの Windows ベース アカウント (ドメイン\ユーザー) に権限が割り当てられていることです。
ユーザーまたはそのユーザーの属しているグループが適切な権限を使用するように構成されていることを確認します。 詳細については、「SharePoint Server でのユーザー アクセス許可とアクセス許可レベル」を参照してください。
この記事に示すツールや手法を使用してユーザーのセキュリティ トークン内の一連のクレームを確認し、構成済みの権限と比較できるようにします。
メッセージが認証に失敗したことを示している場合は、認証の問題が発生しています。 クレーム ベース認証を使用する SharePoint Web アプリケーション内にリソースが含まれている場合は、この記事の情報を使用してトラブルシューティングを開始します。
トラブルシューティング ツール
以下に、SharePoint Server のクレーム認証に関する情報を収集するために Microsoft によって提供されている主なトラブルシューティング ツールを示します。
統合ログ システム (ULS) ログを使用すると、認証トランザクションの詳細を取得できます。
サーバーの全体管理を使用すると、SharePoint Web アプリケーションおよび領域のユーザー認証設定の詳細を確認し、ULS ログ レベルを構成することができます。
Security Assertion Markup Language (SAML) ベースのクレーム認証用のフェデレーション プロバイダーとして Active Directory フェデレーション サービス 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 フォルダー ウィンドウの一覧の一番上にあるログ ファイルをダブルクリックし、メモ帳でファイルを開きます。
メモ帳で、[編集]、[検索] の順にクリックして「Authentication Authorization」または「Claims Authentication」と入力し、[次を検索] をクリックします。
[ キャンセル] をクリックし、[ Message] 列の内容に目を通します。
ULS Viewer を使用するには、「ULS Viewer」からダウンロードし、SharePoint Server または SharePoint Foundation を実行しているサーバーのフォルダーに保存します。 インストール後に、以下の手順に従って失敗した認証を探します。
ULS Viewer を使用して失敗した認証を確認するには
SharePoint Server または SharePoint Foundation を実行しているサーバーで、保存先のフォルダーにある Ulsviewer をダブルクリックします。
ULS Viewer で [ File] (ファイル) をクリックし、[ Open From] (開く場所) をポイントして [ 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 folder または \Microsoft Shared\Web Server Extensions\15\LOGS フォルダーを指定します。
%CommonProgramFiles% は、SharePoint Server または SharePoint Foundation を実行しているサーバーの CommonProgramFiles 環境変数の値に置き換えます。 たとえば、その場所が C ドライブの場合は、%CommonProgramFiles% を C:\Program Files\Common Files に設定します。
[OK] をクリックします。
[Edit] (編集) をクリックし、[Modify Filter] (フィルターの変更) をクリックします。
[ フィルター処理 ] ダイアログの [ フィールド] で、[ カテゴリ] をクリックします。
[Value] (値) に「Authentication Authorization」または「Claims Authentication」と入力し、[OK] をクリックします。
認証の試行を繰り返します。
ULS Viewer ウィンドウで表示された行をダブルクリックし、[Message] (メッセージ) 部分を表示します。
OAuth 以外の要求に対するメッセージのクレーム エンコード部分で、クレーム エンコード文字列 (例: i:0#.w|contoso\chris) から認証方法とエンコードされたユーザー ID を特定できます。 詳細については、「SharePoint 2013 と SharePoint 2010 のクレーム エンコード」をご覧ください。
手順 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) ベースの接続が使用されます。 暗号化されたメッセージの内容をネットワーク トラフィック ツールで表示するには、アドインまたは拡張機能が必要です。 たとえば、Network Monitor の場合は、Network Monitor Decryption 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