アップグレード後のDevice Trustのトラブルシューティング
Device Trust（Okta Classic Engine）からOkta FastPassに移行する場合は、次のトラブルシューティングと検証手順を検討してください。
Device Trustの無効化エラー
Okta Identity Engineでは、信頼されていないデバイスの認証ポリシーが必要です。これらを正しく構成しなかった場合、Device Trust（Okta Classic Engine）を非アクティブ化しようとしたときにエラーが発生します。エラーメッセージは、影響を受ける認証ポリシーによって異なります。
たとえば、Device Trust（Okta Classic Engine）のアプリサインオンポリシーは、次の構成にする必要がある場合があります。
- ［CLIENT（クライアント）］：［Windows］および/または［macOS］
- ［Device Trust（Device Trust）］：［Not trusted（非信頼）］
- ［ACCESS（アクセス）］：［Denied（拒否）］
このポリシーは、次のようにOkta Identity Engineに移行されます。
- AND［Device state is（デバイスの状態）］：［Registered（登録済み）］
- AND［Device management is（デバイス管理）］：［Not managed（非管理対象）］
- THEN［Access is（アクセスの可否）］：［Denied（拒否）］
次の画像は、これら2つの構成を示しています。
|
Okta Classic Engineのアプリサインオンポリシー |
Okta Identity Engineの認証ポリシー |
|---|---|
|
|
レガシーのDevice Trust構成を削除する前に、Okta Identity Engine認証ポリシーを修正して、Okta FastPassに登録されていないデバイスへのアクセスを拒否してください。
- アプリへのアクセスを許可するタイミングを定義する1つまたは複数の許可ルールを作成します。これらのルールに最高優先度を割り当てます。
- ステップ1で作成した許可ルールに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、Oktaのデフォルトルールのすぐ上の最低優先度を割り当てます。
最初のルールでは、登録済みの管理対象デバイスを許可する必要があります。
- AND［Device state is（デバイスの状態）］：［Registered（登録済み）］
- AND［Device management is（デバイス管理）］：［Managed（管理対象）］
- THEN［Access is（アクセスの可否）］：［Allow（許可）］
後のルールでは、他のすべてのデバイスを拒否する必要があります。
- AND［Device state is（デバイスの状態）］：［Any（すべて）］
- THEN［Access is（アクセスの可否）］：［Denied（拒否）］
例1：
| ルール | ルール名 | ユーザーグループ | IF | THEN |
|---|---|---|---|---|
| 1 | グループA管理対象 | A | 登録済み管理対象デバイスが必要 | 1つのFAで許可 |
| 2 | グループAその他 | A | すべてのデバイスの状態 | 2つのFAで許可 |
| 3 | グループB管理対象 | B | 登録済み管理対象デバイスが必要 | 1つのFAで許可 |
| 4 | キャッチオールルール | すべて | すべて | 拒否済み |
例2：
Windowsデバイスのトラブルシューティング
統合Windows認証が想定どおりに機能することを確認する
クライアントデバイスで次のURLにアクセスし（[IWA_DOMAIN_NAME] をIWAドメイン名に置き換えます）、想定どおりに動作することを確認します。
- http://[IWA_DOMAIN_NAME]/IWA/iwa_test.aspx
ブラウザーに正しく表示されることを確認します。
- http://[IWA_DOMAIN_NAME]/IWA/authenticatd.aspx
［Userid］、［UserPrincipalname］、［UserprincipalName］（変換後）、および［Security Identifier（セキュリティ識別子）］が表示されていることを確認します。
- http://[IWA_DOMAIN_NAME]/IWA/auth.aspx
Oktaサインインページに移動していることを確認します。
Device Trustクライアントがクライアントデバイスにデプロイされていることを確認する
- Windowsで、をクリックします。
- ［Okta Device Registration Task（Oktaデバイス登録タスク）］を探します。
Device Trust相互TLSクライアント証明書がインストールされていることを確認します
-
Microsoft管理者コンソール（MMC）で、証明書マネージャーを開きます（をクリック）。
-
［Okta MTLS - ［userName（ユーザー名）］証明書が存在することを確認します。
証明書が存在しない場合は、タスクスケジューラーを開き（をクリック）、okta-devicetrust-usertaskを実行します。
Device Trustの登録が想定どおりに機能することを確認する
- Microsoft管理者コンソール（MMC）で、証明書マネージャーを開きます（をクリック）。
- ［Okta MTLS - ［username（ユーザー名）］証明書を削除します。
- コマンドプロンプトを開きます。
- ディレクトリを「Program Files\Okta\DeviceTrust」に変更します。
- OktaDeviceReg.exe --user --verbose --forceを実行します。
新しいコマンドウィンドウが表示されます。
- エラーが存在しないこと、および新しい証明書がクライアントデバイスに登録されていることを確認します。
ルールに登録済み管理対象デバイスが必要であることを確認する
- Admin Consoleで、に移動します。
- アップデートするポリシーを選択します。
- ［Rules（ルール）］タブをクリックします。
- ポリシー情報を表示し、ポリシー内のルールの1つで次のように指定されていることを確認します。
- ［Device（デバイス）］：［Registered, Managed（登録済み、管理対象）］
- ［User must authenticate with（ユーザーが使用する認証方法）］：［Any 1 factor type（任意の1要素タイプ）］
管理者システムのログを確認する
［Enforce Okta Device Trust for managed Windows computers（管理対象のWindowsコンピューターにOkta Device Trustを強制適用する）］に移動し、セクションを参照してください。
Trusted Platform Module（TPM）を使用している場合は、「Trusted Platform Module（TPM）によるWindows Device Trustのセキュリティ強化」を参照してください。
macOSデバイスのトラブルシューティング
Device Trustクライアントがクライアントデバイスにデプロイされていることを確認します。「Jamf Proの管理対象macOSデバイスへのOkta Device Trustの適用」の「端末からインストールを確認するには」を参照してください。