Identity EngineのDevice Trustに関する既知の問題

サポートに問い合わせる前に、既知の問題に関する情報を活用して、発生したエラーの原因を特定してください。

次の表に、Identity EngineのDevice Trustに関する既知の問題を示します。

Classic EngineからIdentity Engineへのアップグレードについては、Identity EngineのDevice Trustへのアップグレードに関する情報を参照してください。

プラットフォーム

発行

すべてのプラットフォーム

Okta Verify登録の同期に関する問題

ユーザーがOkta Verifyにデバイスを登録すると、Oktaはユーザーに関連する以下の2つの登録を作成して管理します。

  • ユーザーのデバイス内のローカル登録
  • Oktaでのサーバー側の登録

Okta Verifyが正しく動作するには、2つの登録が同期している状態を維持する必要があります。ただし、特定の管理者アクションとエンド・ユーザー・アクションによって、2つの登録の同期が解除されることがあります。

管理者によるサーバー側登録の同期解除アクション

Okta管理コンソールを使用してデバイスを一時停止または非アクティブ化すると、関連するユーザーのサーバー側にあるOkta Verify登録も一時停止または非アクティブになります。管理者がデバイスを再アクティブ化しても、ローカルおよびサーバー側の登録は同期しないままの状態です。この場合、ユーザーはOkta Verifyでアカウントを削除または追加したり、どのデバイスにもOkta Verifyを登録したりすることができません。これを解消するには、IT管理者に問い合わせる必要があります。

ユーザーによるローカル登録の同期解除アクション

  • ユーザーがOkta End-User Dashboardの[設定]ページから、Okta Verifyの登録をリセットした場合。ユーザーがOkta Verifyアプリからアカウントを削除してローカル登録を削除するまで、ローカルの登録とサーバー側の登録は同期しないままの状態です。
  • ユーザーがデバイス設定で生体認証(前もって有効にしている場合)を無効にした場合。ユーザーがデバイス設定で生体認証を再度有効にしても、[Okta Verifyアカウントの詳細]で[ユーザー検証]を再度有効にするまで、ユーザー検証の登録は同期しないままの状態です。
  • 新しい指紋またはFace IDを追加してデバイス設定の生体認証を更新すると、部分的に非同期になります。[このデバイス]をオーセンティケーターとして使用する場合、ポリシーによってユーザー検証(生体認証)が求められなければ引き続き機能します。部分的な非同期状態を解消するには、[Okta Verifyアカウントの詳細]に移動してユーザー検証をオフにしてからオンに切り替えるか、[Face IDの同期]または[Touch IDの同期]をクリックする必要があります。
  • ネットワーク接続が中断されている状況(WiFi接続やスマートフォンの通信の切断など)で、[Okta Verifyアカウントの詳細]からオーセンティケーターとしてのOkta Verifyを削除した場合(登録されている場合)。
  • デバイスからOkta Verifyアプリを不適切に削除した場合。ユーザーがOkta Verifyに登録されていて、ほかのOkta認証要素に登録されていない状況で、最初に(1)Okta Verifyアカウントを削除せずに、または(2)[Okta End-User Dashboard] > [設定] > [追加認証]でOkta Verify登録を削除せずに、デバイスから手動でOkta Verifyアプリを削除すると、Okta Verify登録の同期が解除されます(「現在のデバイスまたは新しいデバイスでOkta Verifyをリセットする」を参照)。これを解消するには、IT管理者に問い合わせる必要があります。
  • デバイスのデータをバックアップしてから復元します。同じデバイスでデータを復元した後でも、TOTPサインイン方法のみは有効なままになります。ほかのサインイン方法はすべて無効になります。別のデバイスでデータを復元すると、すべてのサインイン方法が無効になります。

Okta Verifyを削除する前にアカウントを削除する

デバイスからOkta Verifyを削除する前に、エンド・ユーザーはまずアプリからアカウントを削除する必要があります。

同じOkta Verifyアプリ・インスタンスへの複数のOktaアカウント追加をサポートする

各アカウントが異なるOkta組織の単一のユーザー用である限り、エンド・ユーザーは複数のアカウントをOkta Verifyに追加できます。エンド・ユーザーはOkta組織ごとに複数のOkta Verifyアカウントを追加することはできません。

Okta Verifyでアカウントを削除しようとすると、非アクティブ化してから再アクティブ化したユーザーにエラーが表示される

非アクティブ化してから再アクティブ化したユーザーがOkta Verifyでアカウントを削除しようとすると失敗し、「リソースが見つかりません」というエラーが返されます。これを解消するには、IT管理者に問い合わせる必要があります。

ユーザーを一時停止してから再アクティブ化する

ユーザーを一時停止してから再アクティブ化すると、別のデバイスにOkta Verifyを登録できなくなります。これを解消するには、エンド・ユーザーがIT管理者に問い合わせる必要があります。

一部の状況で、生体認証を有効にしないとアプリにアクセスできない

Okta Verifyアカウントでユーザー検証(生体認証、Windows Hello)を有効にしていないエンド・ユーザーが、Oktaで保護されたアプリにアクセスできないケースがあります。

シナリオ

ユーザーが次のすべてを実行した場合:

  1. デバイスにOkta Verifyをインストールします。
  2. Okta Verifyにアカウントを追加しますが、その時点でもそれ以降もアカウントのユーザー検証(Windows Hello)は有効にしません。
  3. 次のいずれかから、Oktaで保護されたアプリへのアクセスを試みます。
    • Okta End-User Dashboard、その際ダッシュボードへのサインインにOkta Verifyを使わない(IDPを起点とするサインイン)。
    • -または-

    • Okta Verifyにアカウントを追加したものと同じブラウザーおよび同じブラウザー・セッション(SPを起点とするサインイン)。
  4. アプリはアプリ・サインオン・ポリシーによってゲート制御され、すべてのルールで以下が要求されます。
    • ユーザーが所有要素を提供する
    • 再認証の頻度を[サインインが試行されるたび]または[N分/時間/日後に再認証]のいずれかに設定する
  5. 次の画面で[Okta Verifyを使用してサインインする]をクリックせずに、メール・アドレスを入力します。

次の既知の問題のいずれかが発生します。

  • 想定どおりにアプリにアクセスできず、ユーザーはアクセスを拒否され、「appinsstance Idへ完全に認証できません」というエラー・メッセージが表示されます。
  • -または-

  • ユーザーにオーセンティケーターのリストが表示される場合、アカウントで生体認証を有効にしていないため、[このデバイスでOkta Verifyを使用する]は含まれません。この場合、[このデバイスでOkta Verifyを使用する]オプションがないため、アプリにアクセスできません。
以下が表示されます。こちらは表示されません。

解決策

管理者は、アプリのサインオン・ポリシーのすべてのルールについて、再認証の頻度を[デバイスごとに1回]に設定できます。

-または-

エンド・ユーザーは次のいずれかを実行できます。

  • Okta End-User Dashboardからアプリにアクセスする際に、[Okta Verifyを使用してサインインする]をクリックします。
  • Okta Verifyアカウントの[追加認証]を有効にします(関連するプラットフォームについては、「Okta Verify」に移動し、「アカウントを管理する」 > 「アカウントの詳細を構成する」を参照)。
  • (Okta End-User Dashboardからではなく)アプリに直接アクセスします。Okta Verifyにアカウントを追加したときに使用したものとは異なるブラウザーまたはブラウザー・セッションを使用するようにしてください。

アプリへのアクセス中にユーザーが必要な生体認証の提供を拒否した場合、ポーリングがループする

アクセスにユーザー検証(生体認証またはPIN)が必要なアプリにアクセスする場合、ユーザー認証を求められたときに[キャンセル]をクリックまたはタップすると、Okta Verifyは組織のホームページにリダイレクトせずに引き続きユーザー検証を求めます。解決策として、ユーザーは以下を試すことができます。

  • Okta Verifyを閉じてから再度開き、アプリへのアクセスを再試行します。
  • Okta Verifyの設定に移動し、[ユーザー検証]をオフにしてから再度オンにします。
  • Okta Verifyからアカウントを削除して、再度追加します。

管理対象外のデバイスの修復メッセージに、間違ったデバイス管理ソリューションが表示される場合がある

前提

  1. 組織に、同じプラットフォームに対して複数のデバイス管理構成がある。
  2. 各構成は異なるデバイス管理ソリューションと統合する(たとえば、Windowsデバイス管理構成の1つはIntuneと統合し、別の構成はWorkspace ONEと統合する)。
  3. 管理対象外のデバイスのユーザーがいずれかの構成に関連付けられたアプリにアクセスしようとした場合、アプリ・サインオン・ポリシーによってデバイスの管理が求められる。
  4. 管理対象外のデバイスのユーザーが組織で選択したデバイス管理ソリューションに登録できるように、Oktaにはソリューションの名前と登録サイトへのリンクを含む「追加の設定が必要です」 という修復メッセージが表示される。

制限事項

同じプラットフォームの構成が複数ある場合、修復メッセージはそのプラットフォーム用に作成した最も古いデバイス管理構成から情報を取得します。そのため、一部の修復メッセージでは間違ったデバイス管理ソリューションを参照し、間違った登録Webサイトへのリンクが含まれる可能性があります。

ADで非アクティブ化されているADソースのユーザーが、Okta Verifyに登録できる

前提

  1. Active Directory(AD)をソースとするユーザーが、ADとOktaの両方でアクティブの状態。
  2. ユーザーがOkta End-User Dashboardの[設定]ページからOkta Verifyのセットアップを準備している間に、Okta Verify登録のQRコードが表示される。
  3. QRコードをスキャンする前に、ユーザーがADで非アクティブになる。
  4. ユーザーがQRコードをスキャンし、ユーザー検証のプロンプトを満たした後にOkta Verifyに正常に登録される。

問題

ユーザーのアカウントはADで非アクティブ化されているためOkta Verifyに登録できないはずであり、これは想定外の動作です。ADでユーザーが非アクティブ化される前に生成されたQRコードは、タイムアウトするまでは有効なままです。

解決策

これは、QRコードが生成されてからユーザーがスキャンするまでの間にアカウントが非アクティブ化された場合にのみ発生する、まれなケースです。通常、これはほとんどのユーザーにとって非常に短時間です。

ADで非アクティブ化されたユーザーがOkta Verifyに正常に登録できたとしても、そのユーザーはOktaで保護されたアプリケーションにはサインインできません。管理者は、必要に応じて管理コンソールから不要なOkta Verifyの登録を削除できます。

デバイスの管理を要求するアプリ・サインオン・ポリシーを作成する前に、デバイス管理を構成する

デバイスの管理を要求するポリシーで保護されたアプリにアクセスする場合、[セキュリティー] > [デバイス統合]でデバイス管理が構成されていなければ内部サーバー・エラーが発生します。デバイスの管理を要求するアプリ・サインオン・ポリシーを作成する前に、必ずデバイス管理を構成してください。

エラー・メッセージが具体性に欠ける

ユーザーが削除または一時停止されたモバイル・デバイスからOktaで保護されたアプリにアクセスしようとした場合や、ユーザーが一時停止または非アクティブ化された場合、「Oktaとの通信中に予期せぬエラーが発生しました。再試行してください」という一般的なエラー・メッセージが表示されます。

メール・リンクからOkta Verifyを設定する際に、ユーザーが間違ったメールを入力するとエラーになる

Okta Verifyをセットアップする際、QRコードをスキャンする代わりに[メール・リンクからOkta Verifyをセットアップする]オプションをエンド・ユーザーが選択した場合、Oktaプロファイルで指定されているプライマリまたはセカンダリのメール・アドレスを入力する必要があります。そのほかのメールアドレスを入力すると、エラーが生成されます。

MDM修復メッセージが表示されない場合がある

デバイスの管理を要求するアプリ・サインオン・ポリシーを構成したものの、デバイス管理([セキュリティー] > [デバイス統合])をまだ構成していない場合、選択されているMDMベンダーへの登録を案内するメッセージの代わりに、「要求されたアクションを実行する権限がありません」というメッセージが管理対象外のデバイスのユーザーに表示されます。

再アクティブ化されたデバイスのSP開始アクセスが失敗する

管理者が登録済みのデバイスを非アクティブ化して後で再アクティブ化し、ユーザーがデバイスからOktaで保護されたアプリに対してSPが起点の認証を試行した場合、アプリへのアクセスは失敗しますが、エラー・メッセージは表示されません。

解決策

登録済みのデバイスを非アクティブ化してから再アクティブ化する場合はエンド・ユーザーに通知し、アカウントを削除してからOkta Verifyに再度追加するように伝えます。

ユーザーの[デバイス]タブにデバイスが20台しか表示されない

ユーザーにリンクされている実際のデバイス数が20を超えている場合でも、ユーザーのプロファイルの[デバイス]タブには最大20個のデバイスしか表示できません。

デバイスからのOkta Verifyの削除は、正しい順序で実行する必要がある

間違った順序でデバイスからOkta Verifyをアンインストールすると、ユーザーのローカルのOkta Verify登録とOktaサーバーに保持されている対応する登録との間の接続が切断されます。接続が切断された場合、Oktaサーバーは変更を認識できず、登録はそのままであると見なし続けます。そのため、ユーザーはIT管理者のサポートなしに登録をリセットしたり、元のデバイスや別のデバイスで新しい登録を作成したりできなくなります。

デバイスからOkta Verifyをアンインストールするには、ユーザーは以下の手順を次の順序で実行する必要があります。

  1. デバイスでOkta Verifyを開き、アプリから任意のアカウントを削除します。
  2. ブラウザーで、[Okta End-User Dashboard] > [設定]に移動します。[追加認証]まで下にスクロールして、[Okta Verifyを削除]をタップまたはクリックします。これにより、Oktaサーバーから登録が削除されます。
  3. モバイル・デバイスでOkta Verifyを探し、アイコンを長押しして、[アンインストール]をタップします。デスクトップでOkta Verifyアイコンをダブルクリックし、[アンインストール]をクリックします。

管理者が [アクセス権を取り消す] オプションを使用した後も、Okta Verifyの登録がアクティブのままになる

管理者がOkta管理コンソールからアクセス権を取り消してユーザーとデバイスの関係を削除した後でも、ユーザーはOkta Verifyを使って保護されたリソースにアクセスできます。デバイスでのユーザーのOkta Verifyオーセンティケーター登録を削除する場合、ユーザーのプロファイル・ページに移動し、 [そのほかのアクション]をクリックします。 [オーセンティケーターをリセット]をクリックし、 [Okta Verify]を選択してから [選択したオーセンティケーターをリセット]をクリックします。

ユーザー・デバイスの生体認証を変更すると、Okta Verifyのユーザー検証登録が無効になる

Okta Verifyにユーザー検証(生体認証)を登録しているユーザーがデバイスの生体認証を変更すると、既存のユーザー検証の登録は無効になります。この問題を解決するために、ユーザーは[Face IDの同期]または[Touch IDの同期]を求められます。ユーザー検証が必要で、ユーザーがほかの認証方法を登録していない場合、IT管理者に問い合わせる必要があります。

すでに組織に複数のOkta Verifyアカウントを持っているユーザーがIdentity Engineにアップグレードする

Identity Engine組織では、組織ごとに複数のOkta Verifyアカウントを追加することはサポートされていません。ただし、Classic EngineからIdentity Engineのアップグレードするシナリオで、Classic Engine組織内でユーザーが複数のOkta Verifyアカウントを作成した場合、以下の予想される動作が適用されます。

Okta Classic組織のユーザーがその組織のOkta Verifyアカウントを2つ持っていて、組織がIdentity Engineにアップグレードされたとします。

  • 両方のアカウントが以前と同じように機能します。
  • どちらのアカウントでも、アプリの[アカウントの詳細]の[このデバイス]の認証方法に[セット・アップ]ボタンが表示されます。このボタンを使用すると、Classic Engineで作成したOkta Verifyアカウントの1つで、ユーザーのデバイスをオーセンティケーター(サインインの方法)として使用できるようになります。このようなアカウントのうち1つを更新した後に、ユーザーが[セット・アップ]をクリックしてほかのアカウントの方法を有効にした場合、エラーが表示され、そのアカウントではこの方法は有効になりません。これは予想される動作です。

macOS

Googleドライブ・ファイル・ストリームのネイティブ・アプリOktaへのアクセスで問題が発生する

パスワードを使わないアクセスを許可するポリシーで保護されたGoogleドライブ・ファイル・ストリームのネイティブ・アプリにアクセスしようとすると、Okta Verify SSOは失敗します。 回避策として、ページの下部にある[代わりにブラウザーでログイン]リンクをクリックしてアプリにアクセスしてください。

Jamf Proを使ったデバイスでのOkta Verifyの自動更新中に問題が発生する

Jamf Proのバージョンに応じて、次のいずれかの手順を実行してOkta Verifyを自動更新します。

Windows

[デバイス属性]ページに専用ハードウェア属性のハッシュが表示されない

Trusted Platform Module(TPM)を備えたデバイスは、[デバイス属性]ページの[専用ハードウェア]属性の下に表示されますが、一意識別子(ハッシュ)は表示されません。代わりに、[あり-使用可能なハッシュがありません]というプレースホルダーが表示されます。

Okta Verifyアカウントの追加時にエラーが起きる可能性がある

Okta Verifyにアカウントを追加する際に、エラー・メッセージ「エラーが発生しました。再試行してください」が表示される場合、表示されている順に以下を試してください。

  1. 正しいサインインURLを入力したことを確認します。
  2. 問題が解決しない場合は、「現在のデバイスまたは新しいデバイスでOkta Verifyをリセットする」の説明に従って、Okta Verifyにデバイスの再登録を試みます。
  3. (管理者のみに推奨)問題が解決しない場合は、アプリを削除して再インストールしてから、再登録する必要があります。アプリを削除する前に、「現在のデバイスまたは新しいデバイスでOkta Verifyをリセットする」の説明に従って、エンド・ユーザーの設定で登録を削除してください。
  4. 問題を報告します(アプリのアイコンを右クリックして[問題の報告]を選択します)。ユーザーがOktaに情報を送信すると、関連するログが自動的に添付されます。

Okta Verify、Windows Hello、リモート・デスクトップ

ユーザーがリモート・デスクトップでマシンにログインしているときに、Okta Verifyのユーザー検証(Windows Hello)を求められた場合、認証がスタックして進行状況インジケーターが回転します。アプリに適用されるアプリ・サインオン・ポリシーがWindows Helloを必要としない場合、この問題は発生しません。

macOSとWindows

すでにインストールされているにもかかわらず、Okta Verifyをインストールするように求められる

デスクトップ・デバイスにすでにOkta Verifyをインストールしているエンド・ユーザーが特定のアプリにアクセスしようとすると、Okta Verifyを再度インストールするように誤って求められる場合があります。これは、ユーザーがOkta Verifyでユーザー検証(生体認証)を有効にしておらず、アクセスしようとしているアプリでユーザー検証が必要な場合に発生する可能性があります。ループに陥らないように、エンド・ユーザーは次のいずれかを行う必要があります。

  • アカウントの隣の縦に並んだ3つの点をクリックしてOkta Verifyでユーザー検証を有効にし、[Touch IDを有効にする](mac)または[Windows Hello](Windows)をクリックして、アプリへのアクセスを再試行します。
  • –あるいは–

  • 別のデバイスにOkta VerifyをインストールしてプッシュとTOTPに登録し、このデバイスを使用してアプリにアクセスします。

管理対象デバイスが特定の状況で[非管理対象]と表示される

管理対象のmacOSおよびWindowsデバイスは、管理対象になってから、ユーザーがデバイスからOkta Verifyを使って保護されたリソースに初めてアクセスするまでの間、[ディレクトリー] > [デバイス][非管理対象]と表示されます。Oktaサーバーは認証イベント中にデバイスの管理ステータスをプローブし、それに応じてデバイスのステータスを更新します。これは予想される動作です。

複数のデスクトップ・デバイスにOkta Verifyを登録するうえでの制約

  • 複数のデスクトップ・デバイスでOkta Verifyを登録するには、YubiKey、SMS、Okta Verify with Pushなど、追加デスクトップにサインインするために使える別の要素を使用して登録を済ませておく必要があります。
  • 最初のOkta Verify登録がデスクトップ・デバイスで行われた場合、次のOkta Verify登録はモバイル・デバイスで行う必要があります。エンド・ユーザーの登録については、「Okta Verify」を参照してください。

上記の制約に従わずに、2台目のデスクトップ・デバイスでOkta Verifyを登録しようとすると、Okta Verifyを使用して登録するよう繰り返し求められますが、この状況では実行できません。

Okta Verifyが実行されておらず、サインオン・ポリシーで特定のルールが設定されている場合に、保護されたリソースへのアクセスが失敗する

前提

  1. Okta Verifyがエンド・ユーザーのデバイスにインストールされていないか、実行されていない。
  2. アプリ・サインオン・ポリシーが次のルールで構成されている。
    • ルール1:アプリにアクセスするにはデバイスの登録が必要
    • ルール2:[許可]にデバイスの登録は必要ない
    • ルール3:キャッチオール・ルールがアクセスの[拒否]に設定されている
  1. ユーザーがアプリへのアクセスを試みる。

問題

アプリへのアクセスが拒否され、「要求されたアクションを実行する権限がありません」というメッセージが表示されます。これは予想される動作です。アプリにアクセスするためにデバイスの登録を要求するルール1によって、Oktaはデバイスの信号をサイレントにプローブします。Okta Verifyが実行されていないため、プローブは失敗します。ルール2によって未登録のデバイスによるアプリへのアクセスが許可されているため、OktaはユーザーにOkta Verifyの起動を要求しません。認証の試行がユーザーのグループ・メンバーシップやネットワークの場所など、ルール2のほかの条件と一致しない場合、認証の試行によってキャッチオールの拒否ルールがトリガーされます。

iOS

ユーザーがOkta Verifyアカウントを削除しても、Okta Verifyをオーセンティケーターとして設定するよう誤って求められる

この問題が発生するユーザーは、セットアップ画面で[キャンセル]をクリックして、[セットアップ必須]のメッセージを無視して構いません。Okta Verifyアカウントは想定どおり削除されています。

特定のタイプのOkta VerifyをClassic Engineに戻した後に生じる制限

Identity EngineからClassic Engineに組織を戻す場合、次のタイプのOkta Verifyアカウントには制限があることに注意してください。

  • Classic Engineに戻す前にIdentity Engineで作成されたアカウント
  • Identity Engineへのアップグレード前にClassic Engineで作成されたアカウントで、Classic Engineに戻した後にユーザーが[アカウントの詳細]で[サインイン方法][このデバイス]とセットアップしたアカウント

制限:

  • iOSデバイスのOkta Verifyの設定[Okta VerifyにTouch IDまたはFace IDを要求する]は無効です。
  • サインイン試行のリスクを評価し、Okta Verifyユーザーに3桁の番号チャレンジの成功を求めるリスクベースの認証は無効です。

これらの機能を有効にするには、エンド・ユーザーがアカウントを削除してOkta Verifyに再登録する必要があります。「iOSデバイスにOkta Verifyをセットアップする」を参照してください。

Android

Google Pixel 4 XLデバイスで、デバイスでサポートされていない指紋スキャンを求められる

Pixel 4 XLデバイスでは、デバイスで生体認証を有効にしていないユーザーが、ユーザー認証(生体認証)が必要なOkta Verifyフローを完了するために指紋をスキャンするようデバイスのオペレーティング・システムから求められます。Pixel 4 XLデバイスはFace IDをサポートしていますが、指紋スキャンはサポートしていません。

Identity Engineで作成されたユーザーの番号チャレンジ・オプション「すべてのプッシュ・チャレンジ」はOkta Verify 6.1.1でサポートされていない

[すべてのプッシュ・チャレンジ]で番号チャレンジを提示するオプションを選択すると、Identity Engineで作成されたユーザーに対してAndroidバージョン6.1.1向けのOkta Verifyがクラッシュします。こうした場合、ユーザーにはOkta Verifyを最新のバージョンに更新するように推奨してください。

Okta Verifyでアカウントの追加中にエラーが発生する

Okta Verifyの登録設定で[必須]オプションを選択している場合、Android向けOkta Verifyバージョン6.2.2以前を実行しているユーザーがOkta Verifyでアカウントを追加しようとすると、エラーが発生します。エラーを回避するには、最新バージョンのOkta Verifyをインストールする必要があります。

Oktaでユーザー名が変更されているユーザーのユーザー検証を設定できない

前提

  1. ユーザーがデバイスにOkta Verifyをインストールしている。
  2. ユーザーがOkta Verifyでアカウントを追加したが、ユーザー検証(生体認証)はOkta Verifyでまだ有効にしていない。
  3. 管理者がOktaでユーザーのユーザー名を変更する。
  4. ユーザーがOkta Verifyでユーザー検証の有効化を試みる。

問題

ユーザー検証の有効化が失敗し、「サインインしているユーザーがアカウントのユーザーと一致しませんでした」というメッセージが表示されます。

解決策

ユーザーは、「現在のデバイスまたは新しいデバイスでOkta Verifyをリセットする」の説明に従って、Okta Verifyの登録をリセットする必要があります。

Okta Verify IDプロバイダー・アカウントを持っているユーザーが、同じデバイスでサインインURLを使ってサービス・プロバイダー・アカウントを追加できません。

問題

ユーザーはOkta Verify IDプロバイダー(IdP)アカウントを持っています。[プッシュ通知][このデバイス]、生体認証がサインイン方法として構成されます。ユーザーはサインインURLを使用してサービス・プロバイダーのアカウントを追加します。ユーザーはユーザー名を入力し、IdPアカウントによって生成されたプッシュ通知と生体認証プロンプトに応答します。アカウントが追加されず、Okta Verifyが終了します。

解決策

ユーザーはQRコードを使用して、同じデバイスにサービス・プロバイダー・アカウントを追加できます。

ユーザーがOkta Verifyからダッシュボードを起動すると、前のセッションでキャッシュされたデータがブラウザーに表示される場合があります。

問題

ユーザーがモバイル・ブラウザーでOkta End-User DashboardまたはOktaで保護されたアプリにアクセスし、別のOkta Verifyアカウントからダッシュボードを起動すると、前のセッションのダッシュボードがブラウザーに表示される場合があります。

解決策

確実に適切なダッシュボードが使用されるようにするには、ユーザーはサインアウトしてから再度サインインする必要があります。

AndroidおよびiOS

Okta MobileはIdentity Engine組織でサポートされていません。

アプリ・サインオン・ポリシーでハードウェア保護制約が有効になっている場合、Classic EngineからIdentity Engineに移行したOkta Verify with Push登録は機能しない

前提

  • Okta Verify with Pushに登録されているClassic Engine組織のユーザー
  • 組織がIdentity Engineに移行する
  • 特定のアプリについて、所有要素制約でサインオン・ポリシー設定のハードウェア保護が選択されている
  • サインオン・ポリシーで、Okta Verify with Pushを使用した認証を許可している
  • ユーザーがプッシュを使用してアプリへのアクセスを試みる

問題

ユーザーのOkta Verify Push登録に関連付けられた鍵が、Classic Engine組織に最初に登録されたときにハードウェアに保存されなかったため、アプリへのアクセスが失敗します。

カスタム・サインイン・ページの要素が表示されないケースがある

組織でカスタムのOktaサインイン・ページをデプロイしている場合、Oktaがエンド・ユーザーに会社のデバイス管理ソリューションへの登録を求めると、カスタマイズの一部が失われたり、操作できなくなったりする可能性があることに注意してください。

ユーザーのOkta End-User DashboardのOkta Verify構成に、1つではなく2つのOkta Verify登録が表示されるケースがある

この問題は、プッシュが有効になっていないClassic Engine組織が、プッシュとTOTPがデフォルトで有効なIdentity Engine組織にアップグレードした場合を前提にしています。

前提

  1. Okta Verify with Pushが有効になって いない Classic Engine組織
  2. ユーザーがOkta Verifyに登録されている
  3. 組織をClassic EngineからIdentity Engineにアップグレードする
  4. ユーザーは、[Okta Verifyアカウントの詳細]の [サインイン方法]を使用して、デバイスをオーセンティケーターとしてセットアップする

問題

Okta End-User Dashboardの[設定] > [追加認証]セクションで、1つではなく2つのOkta Verify登録がユーザーのOkta Verify構成に含まれ、混乱が生じる場合があります。

解決策

Okta End-User Dashboardの[設定] > [追加認証]セクションから、ユーザーが「Okta Verify」という登録を削除する必要があります。

登録済みのデバイスをOkta Verifyからオーセンティケーターとしてセットアップする際に、セットアップを完了するために同じOkta Verifyインスタンスから仮パスコードを取得するよう求められるケースがある

ユーザーがモバイル・デバイスでOkta Verifyを使用して、パスワードなしの認証用オーセンティケーターにそのモバイル・デバイスをセットアップする(つまり、[Okta Verifyアカウントの詳細]にある[サインイン方法][このデバイス]オプションをセットアップする)際に、簡単にはいかない場合があります。これは、Okta Verifyで[このデバイス]を設定する際に、Okta Verifyで生成された仮コードを入力して本人確認を行うよう求められるためです。この場合、セットアップフローを離れて6桁の仮コードを取得してから、セットアップフローに戻り、コードの有効期限が切れる(約30秒)前にコードを入力する必要があります。

[このデバイス]をサインイン方法として有効にする前に、ほかのサインイン方法が有効かどうかを確認します。[認証コード]のみがオンになっている場合、ユーザーは以下を行う必要があります。

  1. Okta Verifyアカウント・ページに移動します。
  2. 6桁のコードをタップしてコピーします。
  3. [アカウントの詳細]ページにただちに戻り、サインイン方法として[このデバイス]を有効にします。
  4. プロンプトが表示されたら6桁のコードを入力します。

エンド・ユーザーがネイティブのモバイル・ブラウザーでセキュリティーで保護されたWeb認証(SWA)アプリケーションにアクセスする場合、Okta Verifyで認証できない

ユーザーがOkta End-User DashboardまたはアプリのURLを使用して、ネイティブのモバイル・ブラウザーでセキュリティーで保護されたWeb認証(SWA)アプリケーションにアクセスしようとしても、Okta Verify認証は成功しません。[デバイス]のサインイン方法と生体認証がOkta Verifyで有効になっている場合でも、ユーザーはアプリのサインイン・ページにリダイレクトされます。

関連項目