Identity EngineのDevice Trustに関する既知の問題
サポートに問い合わせる前に、既知の問題に関する情報を活用して、発生したエラーの原因を特定してください。
次の表に、Identity EngineのDevice Trustに関する既知の問題を示します。
Classic EngineからIdentity Engineへのアップグレードについては、Identity EngineのDevice Trustへのアップグレードに関する情報を参照してください。
プラットフォーム | 発行 | |||
---|---|---|---|---|
すべてのプラットフォーム
| Okta Verify登録の同期に関する問題ユーザーがOkta Verifyにデバイスを登録すると、Oktaはユーザーに関連する以下の2つの登録を作成して管理します。
Okta Verifyが正しく動作するには、2つの登録が同期している状態を維持する必要があります。ただし、特定の管理者アクションとエンド・ユーザー・アクションによって、2つの登録の同期が解除されることがあります。 管理者によるサーバー側登録の同期解除アクションOkta管理コンソールを使用してデバイスを一時停止または非アクティブ化すると、関連するユーザーのサーバー側にあるOkta Verify登録も一時停止または非アクティブになります。管理者がデバイスを再アクティブ化しても、ローカルおよびサーバー側の登録は同期しないままの状態です。この場合、ユーザーはOkta Verifyでアカウントを削除または追加したり、どのデバイスにもOkta Verifyを登録したりすることができません。これを解消するには、IT管理者に問い合わせる必要があります。 ユーザーによるローカル登録の同期解除アクション
| |||
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回]に設定できます。 -または- エンド・ユーザーは次のいずれかを実行できます。
| ||||
アプリへのアクセス中にユーザーが必要な生体認証の提供を拒否した場合、ポーリングがループするアクセスにユーザー検証(生体認証またはPIN)が必要なアプリにアクセスする場合、ユーザー認証を求められたときに[キャンセル]をクリックまたはタップすると、Okta Verifyは組織のホームページにリダイレクトせずに引き続きユーザー検証を求めます。解決策として、ユーザーは以下を試すことができます。
| ||||
管理対象外のデバイスの修復メッセージに、間違ったデバイス管理ソリューションが表示される場合がある前提
制限事項同じプラットフォームの構成が複数ある場合、修復メッセージはそのプラットフォーム用に作成した最も古いデバイス管理構成から情報を取得します。そのため、一部の修復メッセージでは間違ったデバイス管理ソリューションを参照し、間違った登録Webサイトへのリンクが含まれる可能性があります。 | ||||
ADで非アクティブ化されているADソースのユーザーが、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をアンインストールするには、ユーザーは以下の手順を次の順序で実行する必要があります。
| ||||
管理者が [アクセス権を取り消す] オプションを使用した後も、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にアップグレードされたとします。
| ||||
macOS
| Googleドライブ・ファイル・ストリームのネイティブ・アプリOktaへのアクセスで問題が発生するパスワードを使わないアクセスを許可するポリシーで保護されたGoogleドライブ・ファイル・ストリームのネイティブ・アプリにアクセスしようとすると、Okta Verify SSOは失敗します。 回避策として、ページの下部にある[代わりにブラウザーでログイン]リンクをクリックしてアプリにアクセスしてください。 | |||
Jamf Proを使ったデバイスでのOkta Verifyの自動更新中に問題が発生するJamf Proのバージョンに応じて、次のいずれかの手順を実行してOkta Verifyを自動更新します。
| ||||
Windows
| [デバイス属性]ページに専用ハードウェア属性のハッシュが表示されないTrusted Platform Module(TPM)を備えたデバイスは、[デバイス属性]ページの[専用ハードウェア]属性の下に表示されますが、一意識別子(ハッシュ)は表示されません。代わりに、[あり-使用可能なハッシュがありません]というプレースホルダーが表示されます。 | |||
Okta Verifyアカウントの追加時にエラーが起きる可能性があるOkta Verifyにアカウントを追加する際に、エラー・メッセージ「エラーが発生しました。再試行してください」が表示される場合、表示されている順に以下を試してください。
| ||||
Okta Verify、Windows Hello、リモート・デスクトップユーザーがリモート・デスクトップでマシンにログインしているときに、Okta Verifyのユーザー検証(Windows Hello)を求められた場合、認証がスタックして進行状況インジケーターが回転します。アプリに適用されるアプリ・サインオン・ポリシーがWindows Helloを必要としない場合、この問題は発生しません。 | ||||
macOSとWindows | すでにインストールされているにもかかわらず、Okta Verifyをインストールするように求められるデスクトップ・デバイスにすでにOkta Verifyをインストールしているエンド・ユーザーが特定のアプリにアクセスしようとすると、Okta Verifyを再度インストールするように誤って求められる場合があります。これは、ユーザーがOkta Verifyでユーザー検証(生体認証)を有効にしておらず、アクセスしようとしているアプリでユーザー検証が必要な場合に発生する可能性があります。ループに陥らないように、エンド・ユーザーは次のいずれかを行う必要があります。
–あるいは– | |||
管理対象デバイスが特定の状況で[非管理対象]と表示される管理対象のmacOSおよびWindowsデバイスは、管理対象になってから、ユーザーがデバイスからOkta Verifyを使って保護されたリソースに初めてアクセスするまでの間、[ディレクトリー] > [デバイス]に[非管理対象]と表示されます。Oktaサーバーは認証イベント中にデバイスの管理ステータスをプローブし、それに応じてデバイスのステータスを更新します。これは予想される動作です。 | ||||
複数のデスクトップ・デバイスにOkta Verifyを登録するうえでの制約
上記の制約に従わずに、2台目のデスクトップ・デバイスでOkta Verifyを登録しようとすると、Okta Verifyを使用して登録するよう繰り返し求められますが、この状況では実行できません。 | ||||
Okta Verifyが実行されておらず、サインオン・ポリシーで特定のルールが設定されている場合に、保護されたリソースへのアクセスが失敗する前提
問題アプリへのアクセスが拒否され、「要求されたアクションを実行する権限がありません」というメッセージが表示されます。これは予想される動作です。アプリにアクセスするためにデバイスの登録を要求するルール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アカウントには制限があることに注意してください。
制限:
これらの機能を有効にするには、エンド・ユーザーがアカウントを削除して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でユーザー名が変更されているユーザーのユーザー検証を設定できない前提
問題ユーザー検証の有効化が失敗し、「サインインしているユーザーがアカウントのユーザーと一致しませんでした」というメッセージが表示されます。 解決策ユーザーは、「現在のデバイスまたは新しいデバイスで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 Push登録に関連付けられた鍵が、Classic Engine組織に最初に登録されたときにハードウェアに保存されなかったため、アプリへのアクセスが失敗します。 | ||||
カスタム・サインイン・ページの要素が表示されないケースがある組織でカスタムのOktaサインイン・ページをデプロイしている場合、Oktaがエンド・ユーザーに会社のデバイス管理ソリューションへの登録を求めると、カスタマイズの一部が失われたり、操作できなくなったりする可能性があることに注意してください。 | ||||
ユーザーのOkta End-User DashboardのOkta Verify構成に、1つではなく2つのOkta Verify登録が表示されるケースがあるこの問題は、プッシュが有効になっていないClassic Engine組織が、プッシュとTOTPがデフォルトで有効なIdentity Engine組織にアップグレードした場合を前提にしています。 前提
問題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秒)前にコードを入力する必要があります。 [このデバイス]をサインイン方法として有効にする前に、ほかのサインイン方法が有効かどうかを確認します。[認証コード]のみがオンになっている場合、ユーザーは以下を行う必要があります。
| ||||
エンド・ユーザーがネイティブのモバイル・ブラウザーでセキュリティーで保護されたWeb認証(SWA)アプリケーションにアクセスする場合、Okta Verifyで認証できないユーザーがOkta End-User DashboardまたはアプリのURLを使用して、ネイティブのモバイル・ブラウザーでセキュリティーで保護されたWeb認証(SWA)アプリケーションにアクセスしようとしても、Okta Verify認証は成功しません。[デバイス]のサインイン方法と生体認証がOkta Verifyで有効になっている場合でも、ユーザーはアプリのサインイン・ページにリダイレクトされます。 |