概要

Federated ID (SSO)を使用してアドビの製品、サービス、またはモバイルアプリケーションにログインしようとすると、次のエラーメッセージのいずれかが表示されます。

Adobe Admin Console で SSO を正常に設定できたら、「メタデータをダウンロード」をクリックしてコンピューターに SAML XML メタデータファイルを保存していることを確認します。 このファイルがシングルサインオンに対応するように ID プロバイダーを設定する必要があります。XML 設定の詳細を ID プロバイダー(IdP)にインポートする必要があります。このことは、SAML と IdP の統合に必要であり、データが正しく設定されていることが確認されます。

以下は一般的な構成上の問題です。

  • 証明書が PEM 以外の形式である。
  • 拡張子が .cer、.pem、および .cert 以外の証明書は動作しない。
  • 証明書が暗号化されている。
  • 証明書が単一行の形式である。 複数行が必要である。
  • 証明書の失効確認が有効になっている(現在サポート対象外)。
  • SAML の IdP 発行者が Admin Console に指定されているものと同一ではない(スペリングのエラー、文字が抜けている、https と http など)。

SAML XML メタデータファイルを使用して IdP を設定する方法について質問のある場合は、手順について直接 IdP にお問い合わせください(手順は IdP ごとに異なります)。

特定の IdP の場合の例を以下に示します(総合的な一覧ではありません、SAML 2 規格に準拠した IdP であれば問題ありません)。

Okta: 手動により、XML ファイルから入手した必要情報を所定の UI フィールドに入力してデータを正しく設定します。

Ping Federate: XML ファイルをアップロードするか、または、UI フィールドにデータを正しく入力します。

Microsoft ADFS:証明書は PEM 形式でなければなりませんが、ADFS のデフォルトは DER 形式です。 以下のように、openssl コマンドを使用して証明書を変換できます(OS X、Windows または Linux で利用可能)。

openssl x509 -in certificate.cer -out certificate.pem -outform PEM

上記の手順を実行したら、証明書 .cer の名前を変更します。

複数ある場合は、正しい証明書が使用されていることを確認します(要求に署名するものと同一でなければなりません)。(「トークン署名」証明書が要求に署名されている場合は、それが使用する証明書です。) 証明書の失効確認を無効にする必要があります。

わかる範囲で正しく IdP を設定した場合は、表示されるエラーに応じて、以下のいずれかを試してみてください。

メタデータリンクをダウンロードする

トラブルシューティング/初級編

シングルサインオンに関する問題は、見逃しやすい非常に基本的なエラーが原因で引き起こされることがよくあります。 特に、次の点を確認してください。

  • ユーザーは、資格のある製品構成に割り当てること。
  • ユーザーの名、姓、電子メールアドレスは、Enterprise Dashboard に表示されているとおりに SAML で送信し、SAML には正しいラベルを付けること。
  • Admin Console と ID プロバイダーのすべてのエントリで、スペリングエラーや構文エラーを確認すること。
  • Creative Cloud Desktop アプリケーションを最新バージョンにアップデートされていること。
  • ユーザーは正しい場所(CC デスクトップアプリケーション、CC アプリケーションまたは adobe.com)にログインしていること。

エラー「エラーが発生しました」(ラベル「もう一度やり直してください」のボタン付き)

エラーが発生しました - もう一度やり直してください

このエラーは通常、ユーザー認証が成功し、認証応答が Okta から Adobe に正常に転送された後に発生します。

Adobe Admin Console で、以下を確認します。

「Identity」タブ:

  • 関連するドメインをアクティベートしていることを確認します。

「Products」タブ:

  • ユーザーが正しい製品ニックネームに関連付けられていること、また、ドメイン内で Federated ID としての設定を行っていることを確認します。
  • 製品ニックネームに適切な資格が割り当てられていることを確認します。

「Users」タブ:

  • ユーザー名が完全な電子メールアドレスの形式になっていることを確認します。

エラー「アクセス拒否」(ログイン時)

アクセス拒否エラー

このエラーの考えられる原因:

  • SAML アサーションで送信される名、姓、電子メールアドレスがAdmin Consoleで入力されて情報と一致しない。
  • ユーザーが正しい製品に関連付けられていない、または製品が適切な資格に関連付けられていません。
  • SAML ユーザー名が電子メールアドレス以外のものとして見られています。すべてのユーザーは、セットアッププロセスの一環として設定したドメインに存在しなければなりません。
  • ご使用の SSO クライアントは Javascript をログインプロセスの一部として使用します。Javascript をサポートしないクライアントにログインしようとしています(Creative Cloud Packager など)。

解決方法:

  • ユーザーに関するダッシュボード設定を確認します(ユーザー情報と製品設定)。
  • SAML トレースを実行し、送信される情報がダッシュボードと一致することを検証し、不一致があれば修正します。

エラー「別のユーザーが現在ログインしています」

エラー「別のユーザーが現在ログインしています」は、SAML アサーションで送信された属性がログイン手順の開始に使用された電子メールアドレスと一致しない場合に発生します。

SAML アサーションの属性を確認し、使用するユーザー ID と完全に一致していること、および Admin Console と完全に一致していることを確認します。

エラー「システムプリンシプルとしてコールできませんでした」または「ユーザー作成に失敗しました」

エラー「システムプリンシプルとしてコールすることができませんでした」(ランダムコードが続く)または「ユーザー作成に失敗しました」は、SAML 属性に問題があることを示します。属性名のケースが正しいこと(大文字と小文字の区別、名前付けなど)(FirstName、LastName、Email など)を確認してください。例えば、属性名の末尾を「email」(「Email」でなく)とすると、これらのエラーが発生する可能性があります。

また、これらのエラーは、SAML アサーションで「件名/NameId エレメント」にユーザーの電子メール情報がない場合に発生する可能性があります(SAML Tracer の使用時)。フォーマット: emailAddress + 実際の電子メール(テキスト)にしてください。

弊社サポートにお問い合わせになる場合は、SAML トレースも含めてください。

 

エラー「SAML 応答の発行者は ID プロバイダーに設定されている発行者と一致しませんでした」

SAML アサーションの IDP 発行者は、インバウンド SAML で構成されているものと異なります。 タイプミス(http や https など)を探します。IDP 発行者の文字列と顧客の SAML システムをチェックするときは、入力された文字列との正確な一致を探します。この問題は、末尾にスラッシュがないために発生することがあります。

このエラーについてお問い合わせになる場合は、Adobe ダッシュボードに入力した SAML トレースと値をご提示ください。

エラー「SAML 応答のデジタル署名は ID プロバイダー証明書で検証されませんでした」

証明書ファイルが誤っている可能性が高いため、再アップロードする必要があります。この問題は一般に、変更が行われてから、管理者が誤った証明書ファイルを参照することで発生します。  また、形式タイプも確認します(ADFS の場合は、PEM 形式にします)。

エラー「現在時刻はアサーション条件で指定された時間範囲よりも前です」

Windows

システムクロックを修正するか、時間スキュー値を調整します。

システム時間の設定:

以下のコマンドでシステムクロックを確認します。

w32tm /query /status

以下のコマンドを使用して、Windows Server でシステムクロックを修正できます。

w32tm /resync

システムクロックが正しく設定されている場合は、IdP と、IdP に認証されているシステムとの間の差異の許容値を作成する必要があります。

クロックスキュー

まず、スキュー許容値を 2 分に設定します。接続できるかどうかを確認してから、結果に応じて、この値を増減します。詳細については、Microsoft ナレッジベースをご覧ください。

要約すると、Powershell から以下のコマンドを実行できます。

Get-ADFSRelyingPartyTrust –identifier “urn:party:sso”  #Just to see what the values were originally
Set-ADFSRelyingPartyTrust –TargetIdentifier “urn:party:sso” –NotBeforeSkew 2  #Set the skew to 2 minutes

ここで、「urn:party:sso」は証明書利用者の識別番号の 1 つです

メモ:パラメータを指定しなくても、Get-ADFSRelyingPartyTrust cmdlet を使用して、すべての証明書利用者のトラストオブジェクトを取得できます。

UNIX ベースのシステム

例えば、以下のコマンドを使用して、システムクロックが正しく設定されていることを確認します。

ntpdate -u pool.ntp.org

SubjectConfirmation で指定された受信者はサービスプロバイダーエンティティ ID と一致しませんでした

次の大文字/小文字と正確に一致する必要があるため、属性を確認します: FirstName、LastName、Email。このエラーメッセージは、属性の 1 つで大文字/小文字が誤っていることを意味している場合があります(「Email」ではなく「email」など)。 受信者は ACS 文字列を参照するため、受信者値も確認します。

ACS 文字列

エラー 401 権限のない資格情報

このエラーは、アプリケーションが Federated ログインをサポートしない場合に発生します。そのため、Adobe ID としてログインする必要があります。Framemaker、RoboHelp、および Captivate はこの要件のあるアプリケーションの例です。

エラー「インバウンド SAML ログインで、メッセージ: SAML 応答にアサーションが含まれていません、が表示されて、失敗しました」

ログインワークフローを確認します。 別のマシンまたはネットワークでログインページにアクセスできるが内部的にアクセスできない場合は、問題はブロックエージェント文字列である可能性があります。 また、SAML トレースを実行し、First Name、Last Name、Username が正しくフォーマットされた電子メールアドレスとして SAML 件名にあることも確認します。

エラー 400 不正な要求 / エラー「SAML 要求のステータスは失敗でした」 / SAML 証明書の検証に失敗しました

エラー 400 不正な要求

正しい SAML アサーションが送信されていることを確認します。

  • SAML アサーションにある以下の属性(大文字と小文字を区別)が ID プロバイダーを問題なくパスすることを確認します:FirstName、LastName、Email。上記の属性が SAML 2.0 コネクタ設定の一部として送信されるよう IdP に設定されていない場合、認証は行われません。
  • 件名に NameID エレメントがありません。 件名エレメントに NameId エレメントが含まれていることを確認します。 電子メール属性(つまり、認証対象であるユーザーの電子メールアドレス)と同じでなければなりません。
  • スペルの誤り、特に、見落としやすい https や http などの誤りに注意してください。
  • 証明書情報が正しく入力されたことを確認します。 IDP は非圧縮 SAML 要求/応答を使用するように設定する必要があります。 Okta インバウンド SAML プロトコルは、非圧縮設定(圧縮設定でなく)でのみ動作します。

Firefox の SAML Tracer などのユーティリティを使用すると、アサーションをアンパックして表示して検査を行うのに役立ちます。 弊社サポートにお問い合わせになる場合は、このファイルをご提示ください。 

以下の実施例をご覧いただくと、SAML アサーションを正しくフォーマットしていただけます。

ダウンロード

Microsoft ADFS で:

  1. すべての Active Directory アカウントには、正常にログインするために Active Directory にリストされている電子メールアドレスが必要です(イベントログ: SAML レスポンスにはアサーションに NameId がありません)。これを最初にチェックします。
  2. ダッシュボードにアクセスします。
  3. 「Identity」タブとドメインをクリックします。
  4. 「構成の編集」をクリックします。
  5. IDP バインディングの場所を確認します。HTTP-POST に切り替えてから、保存します。 
  6. ログインエクスペリエンスを再テストします。
  7. 正常に動作するが、前の設定がお気に入りの場合は、HTTP-REDIRECT に戻し、メタデータを ADFS に再度アップロードします。

ほかの IdP で:

  1. エラー 400 が発生した場合は、正常なログインが IdP によって拒否されたことを意味します。
  2. IdP ログを確認してエラーの原因の有無をチェックします。
  3. 問題を修正して再試行します。

Microsoft ADFS の構成

ステップバイステップガイド Microsoft ADFS の構成を参照してください。

Creative Cloud で Mac クライアントのウィンドウが空になる場合は、「Creative Cloud」ユーザーエージェントが信頼されていることを確認してください。

Microsoft Azure の構成

ステップバイステップガイド Microsoft Azure の構成を参照してください。

OneLogin の構成

ステップバイステップガイド OneLogin の構成を参照してください。

Okta の構成

ステップバイステップガイド Okta の構成を参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー