View a markdown version of this page

デスクトップでの Amazon Quick のエンタープライズサインインのトラブルシューティング - Amazon Quick

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

デスクトップでの Amazon Quick のエンタープライズサインインのトラブルシューティング

 適用先: Enterprise Edition 
   対象者: システム管理者 

使用する ID プロバイダーに関係なく、一般的なエンタープライズサインインの問題を解決するには、次のガイダンスを使用します。

ヒント

サインインの問題の診断に役立つように、サインイン画面からアプリケーションログをエクスポートできます。管理者または AWS サポートに連絡するときは、これらのログを含めます。

注記

アプリケーションがサインインページにアクセスできない場合、認証を完了できない場合、またはコンテンツをロードできない場合、問題はネットワークに関連する可能性があります。制限された環境では、必要なドメインが許可リストにあり、ファイアウォールと VPN の設定が接続をブロックしていないことを確認します。必要なドメインのリストについては、「」を参照してくださいネットワークアクセスと必要なドメイン。

redirect_mismatch エラー

IdP のリダイレクト URI が正確にhttp://localhost:18080設定されており、パブリッククライアントまたはネイティブプラットフォームとして設定されていることを確認します。

サインイン後にユーザーが見つかりません

このエラーには 2 つの一般的な原因があります。

  1. E メールクレームはトークンで返されません。Microsoft Entra ID の場合、トークン設定の ID トークンにemailオプションのクレームを追加する必要があります (ステップ 1 を参照）。さらに、ユーザーの Mail 属性を Entra ID プロファイルに入力する必要があります。ユーザープリンシパル名 (UPN) だけでは不十分です。

  2. Amazon Quick に一致するユーザーは存在しません。トークン内の E メールは、プロビジョニングされたユーザーの E メールと完全に一致する必要があります。IAM Identity Center アカウントの場合は、Identity Center のユーザーの E メールが一致していることを確認します。E メールマッチングでは、大文字と小文字が区別されます。

トークン検証の失敗

拡張機能アクセス設定の発行者 URL が IdP の OIDC 設定の発行者 URL と正確に一致することを確認します。

無効な発行者エラー (Microsoft Entra ID)

「無効な発行者: https://login.microsoftonline.com/TENANT_ID/v2.0」でサインインに失敗した場合、拡張アクセス設定の発行者 URL に/v2.0パスサフィックスが含まれていることを確認します。Entra ID v2.0 エンドポイントは、 を含む issクレームでトークンを発行します/v2.0。サフィックスがない場合は、拡張機能アクセスを削除し、正しい発行者 URL で再作成します。

このアカウントにエンタープライズサインインが設定されていません

このエラーは、拡張機能アクセスが作成されたが、拡張機能自体は作成されなかったことを意味します。Amazon Quick コンソールの左側のナビゲーションペインで、拡張機能 (詳細を選択して検索する必要がある場合があります) を選択し、拡張機能を作成し、以前に設定した拡張機能アクセスを選択します。

ユーザー情報リクエストが失敗しました (HTTP 504)

これは一時的なバックエンドタイムアウトです。まずウェブブラウザから Amazon Quick アカウントにサインインしてから、デスクトップサインインを再試行してください。エラーが解決しない場合は、Amazon Quick サービスエンドポイントへのネットワーク接続を確認します。必要なドメインのリストについては、「」を参照してくださいネットワークアクセスと必要なドメイン。

同意またはアクセス許可エラー (Microsoft Entra ID)

Azure ポータルで必要な API アクセス許可に対する管理者の同意を付与します。アプリ登録の API アクセス許可ページに移動し、[組織] の管理者同意を付与を選択します。

セッションは頻繁に期限切れになる

更新トークンを発行するように IdP が設定されていることを確認します。Microsoft Entra ID の場合、offline_accessスコープは必須です。Google Workspace の場合は、認可リクエストaccess_type=offlineに を含めます (Quick によって自動的に処理されます）。Okta の場合、更新トークン許可タイプを有効にし、offline_accessスコープを付与する必要があります。Ping Identity の場合、更新トークンの付与タイプを有効にし、offline_accessスコープを付与する必要があります。PingFederate の場合、OIDC ポリシーで Return ID Token On Refresh Grant が選択されていることを確認します。

invalid_scope エラー (Okta)

認可サーバーで offline_accessが有効になっていることを確認します。Security → API → Authorization Servers → default → Scopes に移動し、スコープが存在することを確認します。また、アプリケーションのアクセスポリシーで、Refresh Token 許可タイプが許可されていることを確認します。

アプリケーションが有効になっていない (PingOne)

PingOne ログインページに到達せずに認証がすぐに失敗する場合は、PingOne 管理者コンソールでアプリケーションの切り替えが有効に設定されていることを確認します。

更新後の E メールクレームの欠落 (PingFederate)

email クレームが OIDC ポリシー属性契約に含まれ、正しいユーザー属性にマッピングされていることを確認します。マッピングは、初期認証と更新トークンの両方の許可の emailクレームを生成する必要があります。