マネージドWindowsコンピューターにOkta Device Trustを強制適用するOkta Device Trust

Windows向けOkta Device Trustを使用すると、管理外のWindowsコンピューターが企業のSAMLやWS-Fedクラウドアプリにアクセスできないようにすることが可能です。この強制適用は、Oktaへのフェデレーション認証フローを実行する際に証明書ストアにアクセスできる任意のブラウザーまたはアプリで動作します。

Windows向けOkta Device Trustは以下のようなメリットを提供します。

• ドメイン参加Windowsコンピューターを使用するエンドユーザーのみがSAMLおよびWS-FedクラウドアプリにシームレスにSSOできるようにする
• ネットワーク境界が定義されていない場合でもエンタープライズデータを保護する
• Okta認証局を使用することで、スムーズなエンドユーザーエクスペリエンスを提供する
• マルチフォレスト環境でのDevice Trustの登録をサポートする

前提条件

クライアントワークステーション

• Active Directoryドメインに参加し、Microsoft Windowsの対応バージョンを実行しているコンピューター。「サポートされているプラットフォーム、ブラウザー、オペレーティングシステム」を参照してください。

• .NET Frameworkバージョン4.5.2以降。デバイス登録タスク（Device Registration Task）は、サポートされているバージョンの.NET Frameworkがあることを確認して、ない場合はサポートされているバージョンを自動的にインストールします。「既知の問題」を参照。

Active DirectoryとIWAサーバー

「Active Directory統合の管理」とIWAエージェントの資料を参照してください。

IWAエージェント

Okta IWA WebエージェントのDevice Trust対応バージョン。インストールの詳細は、IWAの資料を参照してください。

あるフォレストで実行されているIWA Webアプリは、別の信頼されたフォレストにあるWindowsデスクトップデバイスのTrust状態を検出して評価します。その後、これらのデバイスがWindows向けDevice Trustに登録できるようになります。

サポートされるブラウザー

• Microsoft Edgeの最新と旧リリース
• Google Chromeの最新と旧リリース
• Microsoft Internet Explorerのバージョン10および11

開始する前に

• Webビューはデバイス証明書ストアにアクセスできなければなりません。Windows向けOkta Device Trustは、Webビューによる認証をサポートするSAMLアプリまたはWS-Fed対応アプリで動作します。認証が実行されるWebビューは、デバイスの証明書ストアにアクセスできる必要があります。これには、先進認証をサポートするOffice 365クライアントが含まれます。Microsoftの記事「更新されたOffice 365先進認証」を参照してください。

• デバイスとエンドユーザーの認証を同時に使用するには、ネットワーク接続が必要です。IWA Webアプリがエンドユーザーとデバイスを認証するには、デバイス登録タスク（Device Registration Task）の実行時にエンドユーザーが会社のネットワークにサインインしている必要があります。IWA Webアプリを参照してください。

• Okta orgが属するセルが読み取り専用モードの場合は、デバイスをDevice Trustに登録できません。

• プロキシサーバーが実装された環境でこのDevice Trustソリューションを機能させるには、デバイス登録タスク（Device Registration Task）のバージョン1.2.1以降をコマンドラインからインストールする必要があります。適切なHttpProxyパラメーターをインストールコマンドに追加します。登録タスクのインストールを参照してください。

• 対象となるコンピューターに証明書がインストールされていることを確認します。アプリサインオンポリシー（App Sign On Policy）（Trusted）ルールでアプリに信頼（Trusted）（App Sign On Policy）オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアに証明書がインストールされていることを確認する必要があります。

  証明書がインストールされておらず、信頼（Trusted）の設定を有効にした場合、ユーザーはアプリへのアクセスを拒否され、管理者への連絡を促すセキュリティメッセージにリダイレクトされます。詳細情報への詳細（Learn more）リンクを含めるようにメッセージを設定できます。「orgのグローバルのDevice Trustの設定を有効化する」を参照してください。

  証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアー（Windows Event Viewer）を解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。 Okta MTLS証明書を探します。

• アプリサインオンポリシーで信頼できるWindowsデバイスを許可するように設定している場合は、セキュリティ（Security） > Device Trust ページでWindows向けDevice Trust設定を無効にしないでください。

  無効にすると、Device Trustの設定に矛盾が生じた状態になります。非信頼のデバイスを使用しているユーザーには、管理者への連絡を促すセキュリティメッセージは表示されません。詳細情報への詳細（Learn more）リンクを設定した場合も、そのリンクは表示されません。「orgのグローバルのDevice Trustの設定を有効化する」を参照してください。

• OktaサポートにWindows向けOkta Device Trustの無効化を依頼する前に、アプリサインオンポリシールールのDevice Trust設定を任意（Any）に変更してください。この設定は、アプリケーション（Applications） > アプリ（app） > サインオン（Sign On）にあります。

  この変更を行わずに後でOktaサポートにOrgのDevice Trust機能の再有効化を依頼した場合、アプリサインオンポリシールールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。

• デバイス登録タスク（Device Registration Task）のインストールを確認するには、適切な検出設定を使用します。デバイス登録タスク（Device Registration Task）を管理対象のWindowsコンピューターにインストールした後、SCCM（System Center Configuration Manager）がスクリプトを実行してそのインストールが成功したことを確認します。

  検出ルール（Detection Rule）（File System）でファイルシステム（File System）（Registry）またはレジストリ（Registry）（Detection Rule）を必ず指定してください。インストールを検出する手段としてWindowsインストーラー（Windows Installer）設定タイプを使用しないでください。その設定では、SCCMはデバイス登録タスク（Device Registration Task）を検出できません。

• クライアントがMTLSハンドシェイクを完了できることを確認します。プロキシサーバー、プロキシクライアントまたはエンドポイント保護ソフトウェアをOrgで実装している場合は、このDevice Trustフローで行われる相互TLS証明書交換（ハンドシェイク）をブロックしない方法で設定してください。トラブルシューティング（Troubleshooting）を参照してください。

• Windows向けOkta Device Trustは、複数のエンドユーザーが同じドメイン参加ワークステーションにサインインする共有端末のシナリオをサポートしていません。

• Device Trustによって保護されたアプリは、Okta End-User Dashboardにロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。

  • エンドユーザーがデスクトップまたはモバイルのブラウザー（Okta Mobile以外）でダッシュボードにアクセスした。
  • OrgでDevice Trustが有効になっている。
  • デバイスが信頼されていない。
  • エンドユーザーがダッシュボードからDevice Trustで保護されたアプリにアクセスしようとした。

手順

orgのグローバルのDevice Trustの設定を有効化する

1. Admin Consoleでセキュリティ（Security） > Device Trust に移動します。

2. Windows向けDevice Trust セクションで、編集（Edit）をクリックします。

3. を有効にするWindows向けDevice Trust を選択します。

4. 任意。詳細（Learn more）リンクフィールドには、外部からアクセス可能なリダイレクトURLを入力できます。非信頼デバイスを使用するエンドユーザーは、このURLで詳細情報を参照できます。これらのエンドユーザーに表示されるセキュリティメッセージには、指定したURLにリダイレクトする詳細（Learn more）リンクが含まれます。

   

   この任意フィールドにURLを指定しないオプションを選択した場合、これらのエンドユーザーには同じメッセージが表示されますが、詳細（Learn more）リンクは表示されません。

   

5. 保存（Save）をクリックします。

ドメイン参加WindowsコンピューターにDevice Trust証明書を登録する

ドメインに参加しているWindowsコンピューターにDevice Trust証明書を正しくインストールするには、このセクションにある4つの手順を実行します。

2.1：ADドメインにOkta IWA WebアプリのDevice Trust対応バージョンをインストールする

Windows向けOkta Device Trustでは、IWA Webアプリを使用して、Windowsコンピューターとユーザーの両方がActive Directoryドメインに参加していることを検証することで、セキュリティポスチャを確認します。その後、Oktaは、OktaフェデレーションアプリにDevice Trustフローを有効化するWindowsコンピューターに証明書を発行します。

Okta証明書に関連した秘密鍵は、Windowsコンピューターを離れることはありません。証明書は年に1回、有効期限の約30日前に自動更新されます。

登録は、複数フォレスト環境でもサポートされています。前提条件を参照してください。

IWA Webアプリのロールは、証明書の登録と更新プロセスに制限されます。証明書がインストールされた後は、エンドユーザーがアプリにアクセスする際に、デバイス登録タスク（Device Registration Task）がIWA Webアプリとやり取りする必要がなくなります。Windows向けOkta Device Trustデスクトップを機能させるために、セキュリティ（Security） > 委任認証（Delegated Authentication）でデスクトップSSOをオン（On）にする必要はありません。

1. IWA Webアプリをダウンロードするには、次のリンクを構成します。

   https://<org>.<okta/oktapreview>.com/static/agents/iwa/OktaSsoIwa-x.x.x.exe

   以下のようになります。

   • <org>：Orgの名前

   • <okta/oktapreview>：Oktaの本番環境またはプレビュー環境。

   • oktaSsoIwa-x.x.x.exeは、Windows向けDevice TrustをサポートするIWA Webアプリのバージョン。最新のDevice Trust対応バージョンについては、「SSO IWA Webアプリのバージョン履歴」を参照してください。

   たとえば、example.oktapreview.comOrgにバージョン1.11.0をダウンロードするリンクは次のようになります。

   https://example.oktapreview.com/static/agents/iwa/OktaSsoIwa-1.11.0.exe

2. Okta IWA Webアプリを「Desktop SSO用にOkta IWA Webアプリをインストールして構成する」に詳述されている手順に従ってインストールします。

3. IWA Webエージェントが運用可能であることを確認するには、このガイドに示す手順どおりにテストします。

4. IWAにHTTPSを使用する場合には、IWA web.configファイルを次のように変更する必要があります。

   1. IWA Webエージェントを実行しているサーバー上で、C:\inetpub\wwwroot\IWA\web.configファイルにアクセスします

   2. <system.serviceModel>セクションを見つけて、以下で置き換えます。

      <system.serviceModel>
      <bindings>
      <webHttpBinding>
      <binding name = "SecureBindingForDeviceTrust">
      <security mode="Transport">
      <transport clientCredentialType = "Windows" proxyCredentialType="Windows"/>
      </security>
      </binding>
      <binding name = "HttpBindingForDeviceTrust">
      <security mode="TransportCredentialOnly">
      <transport clientCredentialType = "Windows" proxyCredentialType="Windows"/>
      </security>
      </binding>
      </webHttpBinding>
      </bindings>
      <services>
      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">
      <endpoint binding="webHttpBinding" bindingConfiguration="SecureBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>
      </service>
      </services>
      <behaviors>
      <endpointBehaviors>
      <behavior name="webHttp">
      <webHttp/>
      </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
      <behavior name="OktaSSO.DeviceTrustBehavior">
      <!-- To avoid disclosing metadata information, set the value below to false before deployment -->
      <serviceMetadata httpGetEnabled="false"/>
      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="false"/>
      <serviceCredentials>
      <windowsAuthentication allowAnonymousLogons="False" includeWindowsGroups="True"/>
      </serviceCredentials>
      </behavior>
      </serviceBehaviors>
      </behaviors>
      </system.serviceModel>

      以下にHTTPSまたはHTTPバインドを構成する値の詳細を示します。

      HTTPSバインドの構成：

      <services>
      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">
      <endpoint binding="webHttpBinding" bindingConfiguration="SecureBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>
      </service>
      </service

      HTTPバインドの構成：

      <services>
      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">
      <endpoint binding="webHttpBinding" bindingConfiguration="HttpBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
      </services>

   3. web.configファイルを保存して閉じます。

   4. Windowsコマンドプロンプトから、次のコマンドを発行することでインターネットインフォメーションサービス（IIS）を再起動します。

      iisreset /stop

      iisreset /start

   5. 先に進む前に、IWA Webアプリを「デスクトップSSO用にIWA Webアプリをインストールして構成する」に示す手順どおりに再起動します。

   6. まだ行っていない場合は、デバイス登録タスク（Device Registration Task）をデバイス登録タスクを取得してインストールするの手順に従ってインストールします。

2.2：デバイス登録タスクを取得してインストールする

開始する前に次の情報を確認してください。

Trusted Platform Module（TPM）

Trusted Platform Module（TPM）でWindows向けDevice Trustのセキュリティを強化するを参照してください。

エンドユーザーが会社のネットワークに接続しているときに登録タスクをスケジュールする

ドメインに参加しているコンピューターに登録タスクをインストールすると、登録タスクが以下の状況で実行されます。

• インストールの直後
• ユーザーがコンピューターにサインオンするたび
• デバイス登録タスク（Device Registration Task）が最初に実行されてから24時間ごと

管理ツールを構成して、エンドユーザーが会社のネットワークに接続しているときに登録タスクをスケジュールします。登録タスクを実行すると、証明書登録フローがトリガーされ、24時間ごとおよびユーザーがコンピューターにサインオンするたびの実行スケジュールを持つタスクが作成されます。この再試行の動作は、証明書の登録と更新シナリオの両方に役立ちます。

証明書の自動更新は、エンドユーザーが会社のネットワークに接続しているときにのみ行われます。

証明書の有効期限は1年間で、有効期限満了の30日前までに自動更新されます。

自動更新が正常に実行されるには、エンドユーザーがドメイン参加したコンピューターにサインインしており、企業ネットワークに接続されている必要があります。

証明書の手動更新の強制実行

証明書の手動更新を強制的に実行して（デバイス登録タスク（Device Registration Task）の1.3.1以降が必要）、以下のような問題を修正できます。

• 管理者がAdmin Consoleでエンドユーザーの証明書を誤って失効した（失効（Revoke）を参照）。
• 不慮の削除、ファイルの破損、または秘密鍵の喪失により、クライアント上の証明書が破損した。

「特定の状況下で証明書の更新を強制実行する」を参照してください。

証明書の自動選択

デバイス登録タスク（Device Registration Task）はデフォルトでドメイン参加Windowsコンピューター上にレジストリキーを構成して、サポートされているChrome、Edge、Internet Explorerのブラウザーに、Oktaに提示されるDevice Trust証明書を自動的に選択させます。

お使いの環境に適している場合、SkipBrowserSetup=trueフラグをインストールコマンドに追加することで、この機能を無効化できます。登録タスクの取得を参照してください。

たとえば、グループポリシーオブジェクト（GPO）ツールを使って証明書の自動選択を構成する場合などに必要です。

デバイス登録タスク（Device Registration Task）またはGPOを通して証明書の自動選択を構成しないオプションを選んだ場合、エンドユーザーにはアプリへのアクセス時に証明書の選択が促されます。その際には、エンドユーザーが選択しやすいように、Okta Device Trust証明書のみが表示されます。

プロキシサーバー環境

組織がインターネットトラフィックをプロキシサーバーを通してルーティングしている場合、以下にご注意ください。

• デバイス登録タスク（Device Registration Task）のバージョン1.2.1以降をコマンドラインからインストールし、インストールコマンドに適切なHttpProxyパラメーターを追加します。

  登録タスクのインストールを参照してください。

• プロキシサーバー、プロキシクライアントまたはエンドポイント保護ソフトウェアをOrgで実装している場合は、このDevice Trustフローで行われる相互Transport Layer Security（MTLS）証明書交換（ハンドシェイク）を妨げないように構成します。

  トラブルシューティング（Troubleshooting）を参照してください。

証明書の失効化

Okta認証局からのエンドユーザーのDevice Trust証明書を取り消すことが必要な場合もあります。これは、コンピューターが紛失したか、盗難にあった場合に推奨されます。

証明書を失効させた後で、エンドユーザーのコンピューターをDevice Trustで再度保護するには、新しい証明書を登録する前に、Device Trust証明書をコンピューターから削除します。証明書の失効は、管理対象のWindowsコンピューターから既存の証明書を削除するものではありません。

「Device Trust証明書の失効化と削除 」を参照してください。

SCCMで適切な設定タイプを使用して、デバイス登録タスクのインストールを確認します。

Device TrustクライアントをマネージドWindowsコンピューターにインストールした後、SCCMがスクリプトを実行してそのインストールが成功したことを確認します。

検出ルール（Detection Rule）でFile SystemまたはRegistryを指定します。インストールの検出にWindowsインストーラー（Windows Installer）設定タイプを使用してはいけません。その設定では、SCCMはDevice Trustクライアントを検出できません。

登録タスクの取得

デバイス登録タスクの早期アクセス（EA）バージョンを取得するには

GAバージョンとは異なり、デバイス登録タスク（Device Registration Task）のEAバージョンはOkta Admin Consoleのダウンロード（Downloads）ページからは利用できません。EAバージョンを取得するには、以下のようにリンクを構成する必要があります。

https://<org>.<okta/oktapreview>.com/static/devicetrust/OktaDeviceRegistrationTaskSetup-x.x.x.<msi/exe>

以下のようになります。

• <org>：Orgの名前

• <okta/oktapreview>：Oktaの本番環境またはプレビュー環境。

• OktaDeviceRegistrationTaskSetup-x.x.x：登録タスクのバージョン。登録タスクの最新バージョンについては、Windows向けDevice Trustデスクトップ登録タスクバージョン履歴を参照してください。

• <msi/exe>はデバイス登録タスク（Device Registration Task）のファイルタイプであり、.msiまたは.exeです。

たとえば、.msi デバイス登録タスク（Device Registration Task）のバージョン1.4.0をexample.oktapreview.comにダウンロードするリンクは次のようになります。

https://example.oktapreview.com/static/devicetrust/OktaDeviceRegistrationTaskSetup-1.4.0.msi

バージョン履歴については、「Windows Desktopの登録タスク向けDevice Trustバージョン履歴」を参照してください。

デバイス登録タスクの一般提供（GA）バージョンを取得するには

デバイス登録タスク（Device Registration Task）の最新GAバージョンは、ダウンロード（Downloads）ページから.msi形式と.exe形式で取得できます。バージョン履歴については、「Windows Desktopの登録タスク向けDevice Trustバージョン履歴」を参照してください。

1. Admin Consoleで、設定（Settings） > ダウンロード（Downloads）に移動します。

2. Windows向けOkta Device Trust > エージェント（Agent）までスクロールし、使用するインストーラータイプの最新をダウンロード（Download Latest）をクリックします。

登録タスクのインストール

以下のいずれかの方法で登録タスクをインストールします。

方法1：管理ツール（SCCM）を使用して登録タスクを配信する

Organizationの手順に従って、ドメイン参加ワークステーションにソフトウェアを配信します。組織がSCCMを使用する場合は、Microsoft記事「構成マネージャーでアプリケーションをデプロイする方法」を参照してください。

.exeまたは.msiのインストールに適切なコマンドを実行します。

デバイス登録タスクとプロキシサーバーについて

Organizationがプロキシサーバーを介してインターネットトラフィックをルーティングしている場合、次のことを行う必要があります。

コマンドラインを使用してデバイス登録タスクをインストールし、パラメーターを含める

デバイス登録タスク（Device Registration Task）のバージョン1.2.2以降をコマンドラインからインストールし、インストールコマンドに適切なHttpProxyパラメーターを追加します。これは、デバイス登録タスク（Device Registration Task）のインストーラーが次の2つのスケジュールタスクをインストールするために必要となります。

• サインインユーザーとして実行されるユーザータスク。
• ネットワークサービスとして実行されるデバイスタスク。Internet Explorer（IE）設定の一部としてプロキシサーバーをセットアップした場合、以下の例に示すように、コマンドラインでその動作を指定しない限り、デバイスタスクでIEの設定が検出されることはありません。

お使いの環境に適したパラメーターを含めてください。

プロキシサーバー環境

HttpProxy=http://<your proxy http url>:<port number>

たとえば、プロキシサーバーパラメーターを含むインストールコマンドは、次のようになります。

MSIのインストール：

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ HttpProxy=http://<your proxy http url>:<port number>"

EXEのインストール：

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com HttpProxy=http://<your proxy http url>:<port number>

プロキシ自動構成（PAC）環境

A. PACの場所を指定する。

HttpProxyPacLocation=http://mypacfile.url.location

たとえば、PACの場所のパラメーターを含むインストール​コマンドは、次のようになります。

MSIのインストール：

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ HttpProxyPacLocation=http://mypacfile.url.location"

EXEのインストール：

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com HttpProxyPacLocation=http://mypacfile.url.location

B. 任意。Okta orgを許可する。

プロキシ環境にPACファイルを実装している場合、以下のようにPACファイルに例外を追加してOkta orgを許可することを検討してください。

if(localHostOrDomainIs(host,"*.okta.com"))

{ return "DIRECT"; }

クライアントがMTLSハンドシェイクを完了できることを確認する

このDevice Trustフローの相互TLS証明書の交換（ハンドシェイク）は、Okta orgのURLとは別のOktaのURLで行われます（以下の例ではワイルドカード文字（*）で示されています）。クライアントがOktaとの証明書交換を完了する際に妨げにならないように、プロキシサーバー、プロキシクライアント、および実装するエンドポイント保護ソフトウェアを構成してください。たとえば、orgが許可リストを使用してアウトバウンドトラフィックを制限している場合、ワイルドカード文字（*）を含めたこれらの正確なURLを許可リストに追加します。

• *.okta.com
• *.okta-emea.com
• *.okta-gov.com

自動証明書チャレンジハンドルを使用：

• MSIのインストール

  msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>"

• EXEのインストール

  OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com

自動証明書チャレンジハンドルを使用しない：

• MSIのインストール

  msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ SkipBrowserSetup=true"

• EXEのインストール

  OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com/ SkipBrowserSetup=true

方法2：登録タスクの手動インストール

この手順は、概念実証または実装時にデバイス登録タスク（Device Registration Task）を手動でインストールするものです。

1. デバイス登録タスク（Device Registration Task）をドメイン参加Windowsコンピューターにコピーします。
2. 管理者としてコマンドプロンプトを実行します。
   1. スタート（Start）をクリックします。
   2. 検索ボックスにcmdと入力し、CTRL+SHIFT+ENTERを押します。
3. ディレクトリをファイルがある場所に変更します。
4. ファイルタイプ（.msiまたは.exe）に適切なコマンドを発行します。インストールとプロキシサーバーの詳細は、前のセクション「管理ツール（SCCM ）を使用して登録タスクを配信する」を参照してください。

2.3 アプリサインオンポリシールールでTrusted（信頼）オプションを構成する前に証明書の登録を確認する

アプリサインオンポリシールールでアプリに信頼（Trusted）オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアにDevice Trustがインストールされていることを確認する必要があります。

証明書がインストールされておらず、［Trusted（信頼）］の設定が有効になっている場合、ユーザーはアプリへのアクセスを拒否され、管理者への連絡を促すセキュリティメッセージにリダイレクトされます。詳細情報への詳細（Learn more）リンクを含めるようにメッセージを設定できます。OrgのグローバルDevice Trust設定を有効化するを参照してください。

証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアーを解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。Okta MTLS証明書（Okta MTLS certificate）を探します。

証明書が複数のドメイン参加コンピューター上にインストールされていることを確認するには管理ツールの使用が最も簡単な方法ですが、1台のコンピューター上の登録をチェックする2つの方法を以下に示します。

Windowsのイベントビューアで確認する

1. スタート（Start）に移動して、［検索］フィールドにeventと入力します。

2. イベントビューア（Event Viewer）がスタート（Start）メニューのトップに表示されたら、入力（Enter）を押して開きます。

3. アプリケーションとサービスログ（Applications and Services Logs）を展開します。

4. Okta Device Trust をクリックしてイベントIDの1000を見つけます。

   

Microsoft管理者コンソールで確認する

1. スタート（Start）に移動して、［Search（検索）］フィールドにmmcと入力してコンソールを開きます。

2. ファイル（File）に移動して、スナップインの追加と削除（Add/Remove Snap-in）をクリックします。

3. 証明書（Certificates）を選択し、追加（Add）をクリックします。

4. 証明書スナップイン（Certificates snap-in）ダイアログで、マイユーザーアカウント（My user account）を選択します。

5. 終了（Finish）をクリックします。

6. OKをクリックします。

7. コンソールルート（Console Root）で、証明書 - 現在のユーザー（Certificates - Current User）を展開します。

8. 個人（Personal）フォルダを展開し、証明書（Certificates）をクリックします。 Okta MTLS証明書（ MTLS certificate）を確認します。

   

2.4. 任意。GPOを使用してブラウザーを構成し、証明書を自動的に選択します。

環境に適している場合、デバイス登録タスク（Device Registration Task）のデフォルト機能ではなく、グループポリシーオブジェクト（GPO）ツールを使用して、Device Trust証明書を自動的に選択するようにブラウザーを構成できます。GPOツールを使用する場合、デバイス登録タスク（Device Registration Task）のインストールコマンドにSkipBrowserSetup=trueフラグを追加したことを確認してください。「ADドメインにOkta IWA WebアプリのDevice Trustサポートバージョンをインストールする」を参照してください。

デバイス登録タスク（Device Registration Task）またはGPOを通して証明書の自動選択を構成していない場合、エンドユーザーにはアプリへのアクセス時に証明書の選択が促されます。その際には、エンドユーザーが選択しやすいように、Okta Device Trust証明書のみが表示されます。

Device Trust証明書が自動的に選択されるようにChromeを構成するには

1. ポリシーテンプレートをダウンロードし、Active Directoryドメインコントローラーのデスクトップにzipファイルを抽出します。

   ファイルをフォルダにコピーします：

   1. C:\end users\Administrator\Desktop\policy_templates\windows\admx\en-US\chrome.admlをC:\Windows\PolicyDefinitions\en-US\にコピー

   2. C:\end users\Administrator\Desktop\policy_templates\windows\admx\chrome.admxをC:\Windows\PolicyDefinitions\にコピー

2. グループポリシー管理者コンソール（GMPC）を開きます。

   1. スタート（Start）メニューに実行（Run）と入力します。

   2. 実行（Run）にgpmc.mscと入力します。

3. 適切なドメインまで展開してグループポリシーオブジェクト（Group Policy Objects）に移動し、デフォルトドメインポリシー（Default Domain Policy）を右クリックして編集（Edit）をクリックします。

   

4. コンピューターの構成（Computer Configuration） > ポリシー（Policies） > 管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル）（Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer） > Google Chrome > コンテンツ設定（Content Settings）に移動します。

5. 右ペインでこれらのサイトのクライアント証明書を自動選択する（Automatically select client certificate for these sites）を選択し、コンテンツ設定（Content Settings）の下でポリシー設定を編集（Edit policy setting）をクリックします。

   

6. 開いたダイアログで有効（Enabled）をクリックします。

7. オプション（Options）の下で表示（Show）をクリックします。

8. 内容の表示（Show Contents）ダイアログにOrgのサブドメインを指定し、Preview Orgと本番Orgのいずれに適用するかを示す値を入力します。

   

   たとえば、Okta Preview OrgのURLがhttps://[*.]oktapreview.comであれば、次の値を入力します。

   {"pattern":"https://[*.]oktapreview.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}

   Okta実働OrgのURLがhttps://[*.]okta.comであれば、次の値を入力します。

   {"pattern":"https://[*.]okta.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}

9. OKをクリックします。

10. 自動証明書の設定がされていることを確認します。

    1. 次回のGPO更新まで待つか、gpupdateコマンドを発行して、GPOを更新します。

    2. Chromeのアドレスバーにchrome://policyと入力し、入力（Enter）を押します。

       

    3. 値を表示（Show value）をクリックし、AutoSelectCertificateForUrlsというポリシーに次の値が表示されていることを確認します。

       {"pattern":"https://[*.]oktapreview.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}

    Windowsレジストリエディターを通して設定を確認することもできます。

    1. スタート（Start）に移動し、［検索］フィールドにregeditと入力します。

    2. レジストリエディターで次のように移動します：HKEY_LOCAL_MACHINE > ソフトウェア（SOFTWARE） > ポリシー（Policies） > Google > Chrome > AutoSelectCertificateForUrls

       

Device Trust証明書が自動的に選択されるようにIEを構成するには

1. Active Directoryドメインコントローラーから、グループポリシー管理者コンソール（GMPC）を開きます。

   1. スタート（Start）メニューにRunと入力します。

   2. 実行（Run）でgpmc.mscと入力し、Enterキーを押します。

2. 適切なドメインまで展開してグループポリシーオブジェクト（Group Policy Objects）に移動し、デフォルトドメインポリシー（Default Domain Policy）を右クリックして編集（Edit）をクリックします。

   

3. コンピューターの構成（Computer Configuration） > ポリシー（Policies） > 管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル）（Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer） > Windowsコンポーネント（Windows Components） > Internet Explorer > インターネットコントロールパネル（Internet Control Panel） > セキュリティページ（Security Page） > 信頼済みサイトゾーン（Trusted Sites Zone）に移動します。

4. 右ペインの設定（Settings）の下で証明書がないか1つしかない場合にはクライアント証明書の選択をプロンプトしない（Don't prompt for client certificate selection when no certificates or only one certificate exists）をダブルクリックします。

   

5. 開いたダイアログで有効（Enabled）をクリックします。

6. 開いているウィンドウを閉じます。

7. コンピューターの構成（Computer Configuration） > ポリシー（Policies） > 管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル）（Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer） > Windowsコンポーネント（Windows Components） > Internet Explorer > インターネットコントロールパネル（Internet Control Panel） > セキュリティページ（Security Page）に移動します。

8. 右ペインの設定（Settings）の下でサイトからゾーンへの割り当てリスト（Site to Zone Assignment List）をダブルクリックします。

   

9. 開いたダイアログで有効（Enabled）をクリックします。

10. オプション（Options）の下のゼロ割り当てをここに入力（Enter the zone assignments here）の隣の表示（Show）をクリックします。

11. 内容の表示（Show Contents）ダイアログに以下を入力します。

    1. この機能をOkta本番OrgとPreview Orgのいずれにデプロイするかに応じて、値の名前（Value name）列にhttps://*.okta.comまたはhttps://*.oktapreview.comと入力します。

    2. 値（Value）列に2と入力します。この値は、ステップ3（Trusted sites zone）で構成したセキュリティゾーン設定の信頼済みサイトゾーン（Trusted sites zone）に対応します。

       

12. OKをクリックして開いているウィンドウを閉じます。

13. GPOの設定が構成されていることを確認します。

    1. 次回のGPO更新まで待つか、コマンドラインでgpupdateコマンドを発行してGPOを更新します。

    2. スタート（Start）メニューにRunと入力します。

    3. 実行（Run）でgpedit.mscと入力し、Enterキーを押します。

    4. コンピューターの構成（Computer Configuration） > ポリシー（Policies） > 管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル）（Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer） > Windowsコンポーネント（Windows Components） > Internet Explorer > インターネットコントロールパネル（Internet Control Panel） > セキュリティページ（Security Page） > インターネットゾーン（Internet Zone）に移動します。

    5. 右ペインの設定（Settings）の下で証明書がないか1つしかない場合にはクライアント証明書の選択をプロンプトしない（Don't prompt for client certificate selection when no certificates or only one certificate exists）をダブルクリックします。

    6. 開いたダイアログで設定が有効（Enabled）であることを確認します。

       

ステップ3. Oktaでアプリサインオンポリシールールを構成する

手順

1. Admin Consoleでアプリケーション（Applications） > アプリケーション（Applications）に進み、Device Trustで保護するSAMLまたはWS対応アプリをクリックします。
2. サインオン（Sign On）タブをクリックします。
3. 下にスクロールしてサインオンポリシー（Sign On Policy）に移動し、ルールを追加（Add Rule）をクリックします。
4. 次の例をガイドとして使用して、1つ以上のルールを構成します。

許可リストの例

ルール例1：Exchange ActiveSyncまたはレガシー認証、すべてのプラットフォーム、任意の信頼、アクセスを許可

1. ルールに記述名を付けて入力します。

2. ユーザー（PEOPLE）で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。

3. ロケーション（LOCATION）で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。

4. クライアント（CLIENT）で、次の設定を構成します。

   • Webブラウザー（Web browser）の選択を解除します。

   • Modern Authクライアント（Modern Auth client）の選択を解除します。

   • Exchange ActiveSyncクライアントまたはレガシー認証クライアント（Exchange ActiveSync client or Legacy Auth client）を選択します。

   • モバイル（Mobile）

   • iOS を選択します。

   • Android を選択します。

   • 他のモバイル（［Other mobile）BlackBerryなど（］）を選択します（Other mobile (e.g. BlackBerry)）。

   • デスクトップ

   • Windows を選択します。

   • macOS を選択します。

   • 他のデスクトップ（Other desktop）（Other desktop (e.g. Linux)）（Linuxなど）を選択します

5. Device Trust（DEVICE TRUST）で以下を構成します。

   Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

   • Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
   • Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
   • Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））

   • すべて（Any）を選択します。

   • 信頼（Trusted）の選択を解除します。

   • 信頼できない（Not trusted）の選択を解除します。

6. アクセス（Access）を構成します。

   許可（Allowed）を選択します。

7. 保存（Save）をクリックします。

8. ルール2（Rule 2）を作成します。

ルール例2：Webブラウザーまたはモダン認証、Windows、信頼できる、アクセスを許可+MFA

1. ルールの記述名を入力します。

2. ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。ユーザーオプションは、この例のすべてのルールで同じでなければなりません。

3. ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じロケーションオプションを選択します。ロケーションオプションは、この例のすべてのルールで同じでなければなりません。

4. クライアント（CLIENT）で、次の設定を構成します。

   • Webブラウザー（Web browser）を選択します。

   • Modern Authクライアント（Modern Auth client）を選択します。

   • Exchange ActiveSyncクライアント（Exchange ActiveSync client）の選択を解除します。

   • モバイル（Mobile）

   • iOS の選択を解除します。

   • Android の選択を解除します。

   • Other mobile (e.g. BlackBerry)（他のモバイル（BlackBerryなど））の選択を解除します。

   • デスクトップ

   • Windows を選択します。

   • macOS の選択を解除します。

   • Other desktop (e.g. Linux)（他のデスクトップ（Linuxなど））の選択を解除します。

5. Device Trust（DEVICE TRUST）で以下を構成します。

   Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

   • Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
   • Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
   • Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））

   • すべて（Any）の選択を解除します。

   • 信頼（Trusted） を選択します。

   • 信頼できない（Not trusted）の選択を解除します。

6. アクセス（Access）を構成します。

   • 許可（Allowed）を選択します。

   • 要素をプロンプト（Prompt for factor）を選択します。

7. 保存（Save）をクリックします。

8. ルール3（Rule 3）を作成します。

ルール例3：Webブラウザーまたはモダン認証、Windowsを除くすべてのプラットフォーム、任意の信頼、アクセスを許可+MFA

1. ルールの記述名を入力します。

2. ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。

3. ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。

4. クライアント（CLIENT）で、次の設定を構成します。

   • Webブラウザー（Web browser）を選択します。

   • Modern Authクライアント（Modern Auth client）を選択します。

   • Exchange ActiveSyncクライアント（Exchange ActiveSync client）の選択を解除します。

   • モバイル（Mobile）

   • iOS を選択します。

   • Android を選択します。

   • 他のモバイル（［Other mobile）BlackBerryなど（］）を選択します（Other mobile (e.g. BlackBerry)）。

   • デスクトップ

   • Windows を選択します。

   • macOS を選択します。

   • 他のデスクトップ（Other desktop）（Other desktop (e.g. Linux)）（Linuxなど）を選択します

5. Device Trust（DEVICE TRUST）で以下を構成します。

   • Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

     • Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
     • Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
     • Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））

   • すべて（Any）を選択します。

   • 信頼（Trusted）の選択を解除します。

   • 信頼できない（Not trusted）の選択を解除します。

6. アクセス（Access）を構成します。

   • 許可（Allowed）を選択します。

   • 要素をプロンプト（Prompt for factor）を選択します。

7. 保存（Save）をクリックします。

8. ルール4（Rule 4）を作成します。

ルール例4：任意のクライアント、すべてのプラットフォーム、任意の信頼、アクセスを拒否

1. ルールの記述名を入力します。

2. ユーザー（PEOPLE）で、ルール1（Rule 1）で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。

3. ロケーション（LOCATION）で、ルール1（Rule 1）で選択したものと同じロケーションオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。

4. クライアント（CLIENT）で、次の設定を構成します。

   • Webブラウザー（Web browser）を選択します。

   • Modern Authクライアント（Modern Auth client）を選択します。

   • Exchange ActiveSyncクライアント（Exchange ActiveSync client）を選択します。

   • モバイル（Mobile）

   • iOS を選択します。

   • Android を選択します。

   • 他のモバイル（［Other mobile）BlackBerryなど（］）を選択します（Other mobile (e.g. BlackBerry)）。

   • デスクトップ

   • Windows を選択します。

   • macOS を選択します。

   • 他のデスクトップ（Other desktop）（Other desktop (e.g. Linux)）（Linuxなど）を選択します。

5. Device Trust（DEVICE TRUST）で以下を構成します。

   • Device Trust セクションの信頼（Trusted）と非信頼（Not trusted）オプションは、クライアント（Client）セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。

     • Exchange ActiveSyncまたはレガシー認証クライアント（Exchange ActiveSync or Legacy Auth client）
     • Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））
     • Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））

   • すべて（Any）を選択します。

   • 信頼（Trusted）の選択を解除します。

   • 信頼できない（Not trusted）の選択を解除します。

6. アクセス（Access）を構成します。

   拒否（Denied）を選択します。

7. 保存（Save）をクリックします。

ルール例5：デフォルトのサインオンルール：任意のクライアント、すべてのプラットフォーム、任意の信頼、アクセスを許可

デフォルトサインオンルールは作成済みであり、編集できません。この許可リストの例では、デフォルトルールがルール4により実質的に無効化されているため、デフォルトルールに到達することはありません。

Device Trust証明書の失効化と削除

Okta認証局からのエンドユーザーのDevice Trust証明書を取り消すことが必要な場合もあります。コンピューターを紛失、盗難した場合や、エンドユーザーが非アクティブ化された場合などに推奨されます。Device Trust証明書を失効させた後で、エンドユーザーのコンピューターをDevice Trustで再度保護するには、新しい証明書を登録する前に、失効した証明書をコンピューターから削除する必要があります。

以下に注意してください。

トラブルシューティング

Windows向けOkta Device Trustは、ドメインで結合したWindowsデバイス上に証明書を生成し、Device TrustによるセキュアなWS-FedまたはSAMLアプリが起動されたときにこの証明書をOktaに渡します。次の2つが最も遭遇しやすい問題です。

• 信頼済みのデバイスが、Device Trustでセキュリティ保護されたアプリにアクセスできない。
• 非信頼デバイスが、Device Trustでセキュリティ保護されたアプリにアクセスできてしまう。

いずれかの問題が発生した場合は、基本的なトラブルシューティングを実行して修正を試みてください。問題が解決しない場合は、高度なトラブルシューティングを実行してください。

基本的なトラブルシューティング

基本的なトラブルシューティングを行うには、次の領域を確認します。

IWA Webアプリのインストールとセットアップ

次を確認します。

• Active DirectoryドメインにIWA WebアプリのDevice Trust対応バージョンをインストール済みであること。
• HTTPS for IWAを使用する場合、HTTPSバインドをサポートするようにIWA web.configファイルを変更済みであること。

問題が再発する場合には、「高度なトラブルシューティング」に進みます。

有効化

セキュリティ（Security）Device Trust でグローバルなDevice Trust設定を有効にしていることを確認します。

登録タスク

デバイス登録タスク（Device Registration Task）をWindowsドメイン参加ワークステーションに配信（Device Registration Task）済みであることを確認します。

プロキシサーバー環境：プロキシサーバーを実装する環境で登録タスクのインストールが成功するためには、デバイス登録タスク（Device Registration Task）のバージョン1.2.1以降をコマンドラインからインストールし、適切なHttpProxyパラメータをインストールコマンドに追加する必要があります。

登録タスクのインストールを参照してください。

証明書

サインオンポリシー

以下を確認します。

次のサインオンポリシーが構成されました。

• Device Trustで保護したいWS-FedまたはSAMLアプリに適用されている。

• 正しいユーザーまたはグループに適用されている。

• 最低限、非信頼デバイスへのアクセスを拒否するアクティブなルールが含まれている。

システムログ

システムログ（System Log）を確認し、以下のDevice Trustシステムログイベントを検証します。

認証

• DisplayMessage：証明書によるデバイスの認証
• EventType：user.authentication.authenticate

登録

• DisplayMessage：Device Trust証明書の登録
• EventType：user.credential.enroll

発行

• DisplayMessage：Device Trust証明書の発行
• EventType：pki.cert.issue

撤回

• DisplayMessage：Device Trust証明書の失効化
• EventType：pki.cert.revoke

有（Renewal）

• DisplayMessage：Device Trust証明書の更新
• EventType：pki.cert.renew

高度なトラブルシューティング

基本的なトラブルシューティングで問題が解決されず、証明書がWindowsワークステーションにインストールされていない場合は、以下の場所を確認してください。

Oktaで、

次を確認します。

• OrgにアクティブなActive Directory（AD）統合（ディレクトリ（Directory） > ディレクトリの統合（Directory Integrations））がある

• ドメイン参加Windowsコンピューターのエンドユーザーが：

  • ディレクトリ（Directory） > ユーザー（People）に存在する

  • アクティブ化（Activated）

  • Active Directoryドメインのメンバー

• IWA Webアプリは：

  • プライマリ

  • 有効

• Device Trust対応バージョン（version）

IWAサーバー上

IWA Webアプリ用IIS設定をチェックする

1. スタート（Start）をクリックします。
2. 検索ボックスにIISと入力します。
3. インターネット情報サービスマネージャー（ ［Internet Information Services Manager）］を右クリックして、管理者として実行（Run as administrator）を選択します。
4. IWA WebアプリをSSLに構成した場合、SSL設定を開いてSSLが必要（Require SSL）オプションが選択されていることを確認します。
5. 認証機能を開いて、Windows認証が有効（Enabled）になっていることを確認します。
   

web.configファイルでエラーをチェックする

1. C:\Inetpub\wwwroot\IWA\web.configに移動します。
2. 検証ツールを使用して、web.configファイルに有効なXML構文が含まれていることを確認します。
3. HTTPSがサイトのIISで有効になっていれば、web.configファイルでSecureBindingForDeviceTrustが有効に設定されていることを確認します。

Windowsログでエラーを確認する

1. スタート（Start）をクリックします。
2. 検索ボックスにEvent Viewerと入力します。
3. アプリケーションとサービスログ（Application and Services Logs）を展開します。
4. Oktaシングルサインオン（ Single Sign On）のエラーを確認します。
   

Windowsドメイン参加コンピューター上

Okta Device Trust Taskがインストールされており、正常に機能していることを確認します。

1. スタート（Start）をクリックします。
2. 検索ボックスにTask Schedulerと入力します。
3. タスクスケジュール（Task Scheduler）を右クリックし、管理者として実行（Run as administrator）を選択します。
4. okta-devicetrust-devicetaskとokta-devicestrust-usertaskのタスクが表示され、問題なく完了したことを確認します。
   

Windowsログでエラーを確認します。

1. スタート（Start）をクリックします。
2. 検索ボックスにEvent Viewerと入力します。
3. アプリケーションとサービスログ（Application and Services Logs）を展開します。
4. Okta Device Trust をクリックします。
   

デバッグモードでログオンユーザーとしてタスクを実行する

1. タスクの実行中にIWAサーバーにアクセスできることを確認します（インターネットで直接またはVPN経由で）。

2. コマンドプロンプトを開いて次のコマンドを発行します。

   "C:\Program Files\Okta\DeviceTrust\OktaDeviceReg.exe" --user --debug

3. Device Trust証明書がデバイス上で生成されていない場合、タスクは以下のアクションを実行します。

   • HKLM\Software\Okta\DeviceTrust\OktaOrgUrlに示されているレジストリ値でOktaに連絡し、OrgのIWAサーバーの場所を取得する。

   • IWAサーバーに連絡して、デバイス用のデバイストークンを生成する。

   • IWAサーバーに連絡して、デバイストークンに基づいてユーザートークンを生成する。

   • 生成したユーザートークンでOktaに連絡し、証明書を生成する。

   • 証明書をユーザーの個人用ストアにインストールする。

ユーザートークンは、IWAサーバーが署名したJWTクレームのセットです。分析目的で、トークンをコピーしてOktaサポートに提供するように求められることがあります。

既知の問題

• Device Trustによって保護されている複数のアプリが、エンドユーザーがInternet ExplorerまたはEdgeのブラウザーからOkta Dashboardにサインインした際に自動的に開くように構成されている場合、Device Trustフローを完了できるアプリは1つのみです。残りのアプリへのアクセスは失敗し、エンドユーザーには管理者への連絡を促すメッセージが表示されます。OrgのグローバルのDevice Trustの設定を有効化するを参照してください。

• Windows向けOkta Device TrustおよびSSO用証明書ベースIWA：このDevice Trustソリューションを構成すると、iOSおよびAndroidモバイルデバイスのSSOをサポートするようにOrgが証明書ベースのIWAで構成されている場合に非互換性の問題が発生する可能性があります。

  このシナリオでは、Device Trust証明書とIWA証明書がインストールされているWindowsコンピューターからIWAを使用してOktaにサインインするエンドユーザーに対して、デスクトップSSOフロー中に両方の証明書を含む証明書ピッカーが表示されて、混乱が生じることがあります。エンドユーザーがDevice Trust証明書を選択すると、IWAフロー中に403エラーが表示されます。

  IISにある証明書を有効にすることで、1つの証明書のみがユーザーに表示されるようにできます。Microsoftの記事「Schannel SSP技術概要」を参照してください。

• デバイス登録タスク（Device Registration Task）は、管理対象のWindowsコンピューターで実行されている.NET Frameworkのバージョンを確認します。バージョンが4.5.2以降でない場合、デバイス登録タスク（Device Registration Task）によってバージョン4.5.2が自動的にインストールされ、インストール中はエンドユーザーページに進捗インジケーターやその他のインストールダイアログが表示されます。