デバイスの既知の問題と回避策

この問題は、orgが同じプラットフォームで複数のデバイス管理構成を使用し、各構成が異なるソリューションと統合している場合に発生します。たとえば、Windowsデバイス管理構成の1つはMicrosoft Intuneと統合し、別の構成はWorkspace ONEと統合している場合などです。

管理対象外デバイスのユーザーが構成の1つに関連付けられたアプリにアクセスしようとし、認証ポリシーでデバイスが管理対象であることが要求されている場合、Oktaは［Additional setup required（追加のセットアップが必要です）］という修復メッセージを表示します。メッセージには、ソリューションの名前とその登録サイトへのリンクが記載されています。

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

Active Directory（AD）ソースのユーザーが、Okta End-User Dashboardの［Settings（設定）］ページからOkta Verifyをセットアップする準備をすると、登録QRコードが表示されます。ユーザーがQRコードをスキャンする前にADで非アクティブ化された場合でも、QRコードをスキャンしてOkta Verifyに登録できます。ADでユーザーが非アクティブ化される前に生成されたQRコードは、タイムアウトするまでは有効なままです。

そのユーザーがOkta Verifyに正常に登録できたとしても、Oktaで保護されたアプリにはアクセスできません。

この問題を解決するには、不要なOkta Verify登録をOkta Admin Consoleから削除します。

Okta FastPassを使用して複数org環境にサインインしていて、すべてのorgにOkta FastPassが設定されていない場合、Okta FastPassの登録プロンプトが表示されないことがあります。

この問題を回避するには、すべてのorgでOkta FastPassが設定されていることを確認してください。

この問題を解決するには、Oktaからユーザー登録を手動で削除します。

Oktaはデバイスコンテキストをプローブできないため、ユーザーはユーザー名とパスワードで認証するときにアクセスを拒否されます。この問題は、サービスアカウントを使用していて、認証ポリシールールが次の場合に発生します。

• ルール1：登録されているが非管理対象のデバイス、またはいずれかの認証要素で登録および管理されているデバイスでサインインする非サービスアカウント。

• ルール2：任意のデバイスからサインインする任意のサービスアカウントは、任意の2つの要素でアプリにアクセスできる。

• ルール3：すべてを拒否する。

この問題に対処するには、次の手順に従います。

1. Okta FastPassを有効にします。

2. 手順5で、［Show the "Sign in with Okta FastPass " button（「Okta FastPassを使用してサインインする」ボタンを表示）］チェックボックスをオンにします。

3. アプリにサインインするときに［Sign in with Okta FastPass（Okta FastPassでサインインする）］をクリックするようユーザーに依頼します。

ユーザーがOkta Verifyアカウントを持っていない場合、ブラウザーでorgのURL（例：http://exampleorg.okta.com）を入力すると、登録が自動的にトリガーされます。

しかし、ユーザーが管理者ポータルのURL（http://exampleorg-admin.okta.comなど）を入力すると、orgのURLにリダイレクトされますが、登録は自動的にトリガーされません。

この問題を回避するには、管理者ポータルのURLではなく、orgのURLを使用してください。

Okta FastPassを使用したサインインは、ネイティブAndroidアプリのWebViewではサポートされていません。

Okta Verifyアプリがバックグラウンドで実行されていない場合、Oktaはデバイスコンテキストを調査できず、ユーザーはアプリサインオンポリシーに応じてアクセスを拒否される可能性があります。

以下の回避策をユーザーに伝えてください。

• アプリにログインする前にAndroid Okta Verifyアプリを起動します。

• デバイスの設定アプリでOkta Verifyの通知を有効にします。

• デバイスの設定アプリ内でOkta Verifyの［App battery usage（アプリのバッテリー使用量）］が［Restricted（制限あり）］に設定されていないことを確認します。

• バックグラウンドでオフになったりスリープ状態になったりしないアプリのリストにOkta Verifyを追加します。［Never sleeping apps（スリープ状態にならないアプリ）］リストにOkta Verifyを追加できない、または追加したのに問題が解決しないときは、親設定の［Put unused apps to sleep（未使用アプリをスリープ状態にする）］を無効にします。

• Okta Verifyが仕事用プロファイルにのみインストールされていることを確認します。ユーザーは個人プロファイルにもアプリをインストールしている場合、デバイスプローブが失敗し、デバイスが管理対象として表示されません。

Android 12では、仕事用プロファイルにOkta Verifyがインストールされている場合、生体認証を有効にすることはできません。

この問題を回避するには、可能であれば、生体認証の有効化のステップをスキップします。

アンマネージドデバイスでiCloud Private Relayが有効になっている場合、そのデバイスではフィッシング耐性のある要素の制限が機能しません。認証ポリシーでアンマネージドiOSデバイスが指定されていて、フィッシング耐性のある要素の制限を必須にしたい場合、ユーザーは認証の前にiCloud Private Relayを無効にする必要があります。

以下の回避策をユーザーに伝えてください。

• 認証の前に iCloud Private Relayを無効にしてください。認証が完了したら、再度有効にします。

• その他の回避策については、ナレッジベースの記事を参照してください。

Okta Verify for iOSでアカウントをアクティブ化しようとすると、設定済みのパスワードを持たない新規ユーザーは「Authenticator operation is not allowed（Authenticatorでの操作は許可されていません）」 というエラー メッセージが表示されます。このため、登録プロセスを完了できなくなります。

この問題を回避するために、ユーザー（または管理者）はデバイスをOkta Verifyに登録する前にパスワード要素を設定することができます。あるいは、ユーザーはiOS以外のデバイスを使用してOkta Verifyに登録し、その後iOSデバイスにアカウントを追加することもできます。

パスワードレスアクセスを許可するポリシーで保護されたGoogle Driveファイルストリームのアプリにユーザーがアクセスしようとすると、Okta Verifyシングルサインオン（SSO）は失敗します。

この問題を解決するには、［Sign in with your browser instead（代わりにブラウザーでサインインする）］をクリックしてアプリにアクセスします。

これは、macOS Big Sur以前の既知の問題です。AppleはmacOS Montereyでこの問題を修正しました。

この問題を解決するには、ユーザーがOkta Verifyを再起動する必要があります。

デバイスライフサイクルのメッセージは、SSO拡張プロファイルを使用するmacOSデバイスでは使用できません。

これは、macOS Big Sur以前を使用しているSafariユーザーにのみ影響します。