SharePoint 2013 の高信頼アプリのトラブルシューティングに関するさらなるヒント

  • Article

原文の記事の投稿日: 2012 年 11 月 2 日 (金曜日)

こんにちは、アプリ ガイです。開発作業は好きだけど、正直なところ、新しい SharePoint アプリで "このトークンの発行元は、信頼できる発行元ではありません" という問題の原因追跡をもう 1 件やらなければいけないとしたら、コンピューターの前で叫び続けて声がかれてしまうかもしれません。そこで、皆さんの声 (と正気) を守るために、この問題が発生したときに僕が確認する項目をこのブログでリストしていこうと思い立ちました。このエラーの再現と解決のための新しい効果的な方法を見つけるたびに、この投稿を更新し、タイトルに "更新" と表示します。

ここで "高信頼アプリ" と言うとき、その意味は、SharePoint アプリの信頼ブローカーとして ACS を使わず、代わりに OAuth トークンを作成し、自分自身の証明書を使ってトークンに署名しているということです。この手順は全部どこかで説明されていると思うので、ここで説明を繰り返すことはしません。このブログは、皆さんがその説明を読み、実際に試してみた結果、モニターに八つ当たりせずにはいられない状態になっていることを前提に進めます。この前提を踏まえて、僕が見たこのエラーが発生するいくつかの状況を次に示します。

  1. SPTrustedRootAuthority リストに追加している - 証明書を使って OAuth トークンに署名するときは、New-SPTrustedRootAuthority を作成する必要があります。SharePoint 2010 の New-SPTrustedIdentityTokenIssuer と同じように、トークン署名証明書とチェーンに含まれるすべての証明書を SharePoint の信頼された機関リストに追加する必要があります。この処理には、https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx (英語) の投稿で説明しているのと同じ手順が使えます。ADFS からの証明書のエクスポートに関する説明は無視してください。ここでは、高信頼アプリ用の証明書を他の手段 (GoDaddy、VeriSign などの公的ルート CA、自己署名証明書、またはドメイン発行証明書) で作成したと想定しています。
  2. クライアント ID ですべて大文字を使っている - 別の投稿で説明しているように、アプリケーションの AppManifest.xml ファイル (または、セルフホスト ソリューションを構築する場合は Web アプリケーションの web.config) にクライアント ID を組み込むときは、大文字を使わないでください。詳細については、https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx (英語) を参照してください。
  3. トークン発行者が信頼ブローカーとして構成されていない - この問題も、このブログの別の投稿で解説しています (https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx (英語))。この問題の要点は、New-SPTrustedSecurityTokenIssuer を作成するときに必ず -IsTrustBroker フラグを指定するということです。
  4. 更新: web.config に IssuerId キーがない - SharePoint 2013 でアプリの信頼ブローカー機能を使うためには、アプリケーションで SharePoint に送信する JWT トークンを作成するときに、信頼ブローカーの IssuerId が何かわかっている必要があります。アプリケーションで IssueId を知る方法は、web.config で IssuerId というアプリ プロパティを探すことです。このプロパティは、アプリケーションの web.config の ClientId、ClientSecret などと同じ場所にあります。次のように指定されています: <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>
  5. 更新: Visual Studio 用 Office ツール RTM プレビューを使っている - プレビュー 2 で修正されていますが、RTM プレビューのコードには実際に少々バグがあります。認証トークンを SharePoint に送信するコードが web.config 内の IssuerId 要素を探さず、違う値を送信します。何を送信するか、どうしてそれを送信するかは、重要ではありません。重要なのは、そのバージョンのツールを使ってこれを回避する方法であり、その方法とは、web.config の ClientId キーで常に SPTrustedSecurityTokenIssuer の IssuerId 値を使うということです。プレビュー 2 のコードを入手したらすぐにインストールし、ClientId を、(以下に説明するように Register-SPAppPrincipal を使って) 作成して登録した一意の GUID に変更してください。ClientId は、OAuth トークンに署名したアプリケーションが何かを識別し、SharePoint UI 全体で使われるため、ClientId がすべて同じにならないようにすることをお勧めします。トラブルシューティングや監査の実施が必要になったとき、すべてのアプリで同じ値を使っていると問題になります。

さらに、注意していただきたい関連する問題があります。このエラーを回避したと思っていたのに、セルフホスト アプリケーションで SharePoint サイトからコンテンツを取得しようとしたら、アクセスが拒否されたというエラーが返されたとします。この場合は次のことが考えられます。

  1. SharePoint アプリの AppManifest.xml ファイル内の ClientId 値が、セルフホスト アプリの web.config 内の ClientId 値と一致していません。Microsoft では、この問題の進行を抑えるための改善を Visual Studio ツールに加えているところです。

次に、同じようにいい質問として、このような問題が発生したときに、どうやって原因追跡するかということがあります。それが簡単にできれば声をからすこともないし、モニターに悪態をつくこともありません。ただし、この問題が発生したときに利用できる、これまで見つけた中でベストのデータ ソースがあります。冒頭にも書きましたが、新しいものを見つけたらリストに追加していきます。

  1. ULS のログ - ULS のログは 1 年中楽しめて特に休日のパーティにはもってこいです。僕は ULS のログを開き、その圧倒的なデータのボリュームを称賛するのが好きです。もちろん皮肉ですが。実際にできる対処方法は、サーバーの全体管理で [監視] の [診断ログの構成] に移動することです。そして SharePoint Foundation のカテゴリを展開し、[アプリ認証]、[アプリケーションの認証]、[認証承認]、[クレーム認証] の各項目を選択します。これらの項目のログ記録とトレース レベルを [詳細] に設定し、変更を保存します。それからアプリケーションを再度起動します。たくさんある ULS ログ表示ツールのうちのどれかを取得して、要求が受信されて処理されていることを確認します。これはアプリ認証の問題についてのヒントを集める優れた方法です。
  2. Fiddler - 気に入っているファンが多い Fiddler も、こういった状況で大変役に立ちます。最も頻繁に目にするのは 401 認証失敗エラーです (基になる問題が "このトークンの発行元は、信頼できる発行元ではありません" である場合など)。要求の直前のフレームを確認し、応答フレームの [ヘッダー] タブをクリックすると、次のような WWW-Authenticate Cookie が表示されます。 Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" さて、これから何がわかるでしょうか? これを見てわかるのは、ClientId 値を e9134021-0180-4b05-9e7e-0a9e5a524965 とし、レルムを 8a96481b-6c65-4e78-b2ef-a446adb79b59 とするよう求められていることです。ClientId 値は簡単に確認できます。AppManifest.xml ファイルとセルフホスト アプリ用の web.config をご覧ください。レルムが間違っている可能性は極端に低いものの、次の PowerShell を実行することでいつでも検証できます。

$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm

これにより、レルムが画面に出力されます。最後に、検証のためにできることがもう 1 つあります。それは、使おうとする ClientId に対して appPrincipal が作成されているか確認することです。これを確認するために使える PowerShell を次に示します。上記の WWW-Authenticate ヘッダー情報を使います。

Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo

エラーが返された場合、または結果が何も返されない場合は、ご察しのとおり有効な SPAppPrincipal がないということなので、PowerShell を使って作成する必要があります。念のため、その例を次に示します。

$clientId = "some guid you create"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "My Cool App"

これでよし。僕が集めた高信頼アプリのトラブルシューティングに関するヒントは、今日のところはこれで全部です。僕も全部を出し切りました。新しい情報を得たときはこの投稿を更新するので、待っていてください。

 

 

 

 

これはローカライズされたブログ投稿です。原文の記事は、「More TroubleShooting Tips for High Trust Apps on SharePoint 2013」をご覧ください。