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

Okta Device Trust for Windowsを使用すると、アンマネージドWindowsコンピューターから企業のSAMLやWS-Fedクラウドアプリにアクセスできないようにすることが可能です。Okta Device Trust for Windowsは、Oktaへのフェデレーション認証フローを実行する際に証明書ストアにアクセスできる任意のブラウザーまたはネイティブアプリで動作します。これには、Edge、Internet Explorer、Chrome、Modern Authentication（先進認証）をサポートするMicrosoft Officeクライアントが含まれます。

アンマネージドWindowsコンピューターに対してOkta Device Trustを強制適用する方法を示す図。

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

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

前提条件

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

  • Microsoft Windows 7、Windows 8.1、またはWindows 10を実行するActive Directoryドメイン参加Windowsコンピューター
  • .NET Frameworkバージョン4.5.2以降。デバイス登録タスクは、サポートされているバージョンの.NET Frameworkがあることをチェックし、なければ、サポートされているバージョンを自動的にインストールします。「既知の問題」を参照。

Active DirectoryとIWAサーバー

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

IWAエージェント

Okta IWA WebエージェントのDevice Trust対応バージョン。インストールの詳細は、IWAの資料を参照してください。注：マルチフォレスト環境でのDevice Trustの登録には、IWA Webアプリのバージョン1.12.2以降が必要です。これにより、あるフォレストで実行されているIWA Webアプリは、信頼されている別のフォレストにあるWindowsデスクトップデバイスを検出して信頼ポスチャーを評価し、これらのデバイスがDevice Trust for Windowsに登録できるようにします。

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

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

はじめに

  • Webビューはデバイス証明書ストアへのアクセス権が必要：Windowsコンピューター用のOkta Device Trustは、Webビューによる認証をサポートするSAML/WS-Fed対応アプリで動作します。認証が実行されるWebビューは、デバイスの証明書ストアにアクセスできる必要があります。これには、Modern Authentication（先進認証）をサポートするMicrosoft Officeクライアントが含まれます。Microsoftの記事「Updated Office 365 modern authentication（アップデートされたOffice 365先進認証）」を参照してください。
  • デバイス + エンドユーザー認証にはネットワーク接続が必要：IWA Webアプリがエンドユーザーとデバイスを認証するには、デバイス登録タスクの実行時にエンドユーザーが会社のネットワークにログインしている必要があります。「IWA Webアプリ」を参照してください。
  • Oktaが読み取り専用モードのときはDevice Trust登録はサポートされない：Okta orgが属するセルが読み取り専用モード の時は、デバイスはDevice Trustに登録されません。
  • プロキシサーバー環境のサポート：このDevice Trustソリューションを、プロキシサーバーを実装する環境で機能させるには、デバイス登録タスクバージョン1.2.1以降をコマンドラインからインストールし、適切なHttpProxyパラメータをインストールコマンドに追加する必要があります。「Registration Taskのインストール」を参照してください。
  • 証明書がターゲットコンピューターにインストールされていることを確認する：App Sign On Policy（アプリサインオンポリシー）ルールでアプリに［Trusted（信頼）］オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアに証明書がインストールされていることを確認する必要があります。証明書がインストールされておらず、［Trusted（信頼）］の設定が有効になっている場合、ユーザーはアプリへのアクセスを拒否され、管理者に連絡するようにとのセキュリティメッセージにリダイレクトされます。（詳細情報への［Learn more（詳細）］リンクを含めるようにメッセージを設定できます。「OrgのグローバルDevice Trust設定を有効にする」を参照してください）。証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアーを解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。Okta MTLS証明書を探します。
  • WindowsのDevice Trust設定を無効にする場合は注意が必要：信頼済みのWindowsデバイスを許可するアプリサインオンポリシーも構成している場合は、［Security（セキュリティ）］［Device Trust］ページでWindowsのDevice Trust設定を無効にしないでください。この設定を無効にすると、Device Trustの設定が一貫性のない状態になり、非信頼デバイスを使用しているユーザーに、管理者への連絡を促すセキュリティメッセージや、［Learn more（詳細）］リンクが表示されなくなります（設定されている場合は、「OrgのグローバルのDevice Trustの設定を有効化する」を参照してください）。

  • OktaサポートにWindows向けOkta Device Trustの無効化を依頼する前に：まず、アプリサインオンポリシールールのDevice Trust設定を［任意］に変更してください（［Applications（アプリケーション）］［app（アプリ）］［Sign On（サインオン）］）。この変更を行わず、後でOktaサポートに組織のDevice Trust機能の再有効化を依頼した場合、アプリのサインオンポリシールールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。

  • Registration Taskのインストールを確認するには適切な検出設定を使用する：管理対象のWindowsコンピューターにデバイス登録タスクをインストールした後、SCCMはスクリプトを実行してインストールが成功したことを確認します。［Detection Rule（検出ルール）］で［File System（ファイルシステム）］または［Registry（レジストリ）］を必ず指定してください。インストールを検出する手段として［Windows Installer（Windowsインストーラー）］設定タイプを使用しないでください。その設定では、SCCMはデバイス登録タスクを検出できません。

  • クライアントがMTLSハンドシェイクを完了できるようにする：プロキシサーバー/プロキシクライアントまたはエンドポイント保護ソフトウェアをOrgで実装している場合は、このDevice Trustフローで行われる相互のTLS証明書交換（ハンドシェイク）をブロックしない方法で設定してください。「トラブルシューティング」を参照してください。
  • 端末共有のシナリオはサポートされていない：Windows向けOkta Device Trust は、複数エンドユーザーが同じドメイン参加ワークステーションから同じアカウントにログインする共有端末のシナリオをサポートしていません。

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

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

手順

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

信頼できるWindowsデバイスを許可するアプリサインオンポリシーも設定している場合は、［Security（セキュリティ）］［Device Trust（Device Trust）］ページでWindowsのDevice Trust設定を無効にしないでください。この設定を無効にすると、Device Trustの設定が一貫性のない状態になり、非信頼デバイスを使用しているユーザーに、管理者への連絡を促すセキュリティメッセージや、［Learn more（詳細）］リンクが表示されなくなります（設定されている場合は、「OrgのグローバルのDevice Trustの設定を有効化する」を参照してください）。

  1. Admin Consoleで［Security（セキュリティ）］［Device Trust（Device Trust）］に移動します。
  2. ［WindowsDevice Trust］セクションで［Edit（編集）］をクリックします。
  3. ［ WindowsDevice Trustを有効にする］を選択します。
  4. 任意。［Learn more（詳細）］リンクフィールドには、外部からアクセス可能なリダイレクトURLを入力できます。非信頼デバイスを使用するエンドユーザーは、このURLで詳細情報を参照できます。これらのエンドユーザーに表示されるセキュリティメッセージには、指定したURLにリダイレクトされる［Learn more（詳細）］リンクが含まれます。

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

  5. ［Save（保存）］をクリックします。
  6. ステップ2に進みます。

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

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

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

Okta Device Trust for Windowsでは、IWA Webアプリを使用して、Windowsコンピューターとユーザーの両方がActive Directoryドメインに参加していることを検証することでセキュリティ体制を確認します。（登録は、マルチフォレスト環境でもサポートされています。「前提条件」を参照してください）。次に、OktaがWindowsコンピューターに証明書を発行し、OktaフェデレーションアプリへのDevice Trustのフローを有効にします。Okta証明書に関連した秘密鍵は、Windowsコンピューターを離れることはありません。証明書は年に1回、有効期限の約30日前に自動更新されます。

IWA Webアプリのロールは、証明書の登録と更新プロセスに制限されます。証明書がインストールされると、デバイス登録タスクはエンドユーザーがアプリにアクセスするにあたってIWA Webアプリとやり取りする必要がなくなります。Windows向けOktaDevice 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は、Device Trust for Windowsをサポートする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"/>
      <!-- デバッグ目的でエラーの例外の詳細を受け取るには、以下の値をtrueに設定します。例外情報の開示を避けるには、展開前にfalseに設定します -->
      <serviceDebug includeExceptionDetailInFaults="false"/>
      <serviceCredentials>
      <windowsAuthentication allowAnonymousLogons="False" includeWindowsGroups="True"/>
      </serviceCredentials>
      </behavior>
      </serviceBehaviors>
      </behaviors>
      </system.serviceModel>

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

      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. まだの場合、デバイス登録タスクを「デバイス登録タスクを取得してインストールする」に示す手順どおりにインストールします。

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

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

Trusted Platform Module（TPM）

TPMのセキュリティ上のメリットを活用するにあたり、「Trusted Platform Module（TPM）でWindows Device Trustのセキュリティを強化する」を参照してください。

エンドユーザーが会社のネットワークにオンライン中にRegistration Taskをスケジュールする

ドメイン参加コンピューターにインストールした後にRegistration Taskが実行される形式：

  • インストール次第実行
  • ユーザーがコンピューターにログインするとすぐに実行
  • 最初の実行から24時間ごとに実行

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

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

証明書の有効期限は1年間で、有効期限満了の30日前までに自動更新されます。自動更新が正常に実行されるには、エンドユーザーがドメイン参加したコンピューターにログオンしており、企業ネットワークに接続されている必要があります。

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

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

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

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

証明書の自動選択

Registration Taskはデフォルトでドメイン参加Windowsコンピューター上にレジストリキーを構成して、サポートされているChrome、Edge、IEブラウザーに、Oktaに提示されるDevice Trust証明書を自動的に選択させます。お使いの環境に適している場合、SkipBrowserSetup=trueフラグをインストール​コマンドに追加することで、この機能を無効化できます。

「Registration Taskの取得」を参照してください。たとえば、グループポリシーオブジェクト（GPO）ツールを使用して証明書の自動選択を構成する場合などに必要です。

Registration TaskまたはGPOを通して証明書の自動選択を構成しないオプションを選んだ場合、エンドユーザーはアプリにアクセスする時に証明書を選択するように求められます。その場合、エンドユーザーが選択しやすいように、Okta Device Trust証明書のみが表示されます。

プロキシサーバー環境

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

  • デバイス登録タスク version 1.2.1以降をコマンドラインからインストールし、インストール​コマンドに適切なHttpProxyパラメーターを追加します。

    「Registration Taskのインストール」を参照してください。

  • プロキシサーバー/プロキシクライアントまたはエンドポイント保護ソフトウェアをOrganizationで実装している場合は、このDevice Trustフローで行われる相互のTLS証明書交換（ハンドシェイク）をブロックしない方法で設定してください。

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

証明書の失効化

Okta認証局からエンドユーザーのDevice Trust証明書を撤回する必要がある場合があります。これは、コンピューターが紛失したか、盗難にあった場合に推奨されます。証明書を失効化した後で、エンドユーザーのコンピューターをDevice Trustで再度保護するには、新しい証明書を登録する前に、Device Trust証明書をコンピューターから削除する必要があります。証明書の失効は、管理されたWindowsコンピューターから既存の証明書を削除するものではありません。

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

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

Device TrustクライアントをマネージドWindowsコンピューターにインストールした後、SCCMがスクリプトを実行してそのインストールが成功したことを確認します。［Detection Rule（検出ルール）］で［File System（ファイルシステム）］または［Registry（レジストリ）］を必ず指定してください。インストールの検出に［Windows Installer（Windowsインストーラー）］設定タイプを使用しないでください。その設定では、SCCMはDevice Trustクライアントを検出できません。

Registration Taskの取得

Trusted Platform Module（TPM）のセキュリティ上のメリットを活用するには、「Trusted Platform Module（TPM）でWindows Device Trustのセキュリティを強化する」を参照してください。

Registration Taskの早期アクセス（EA）バージョンを取得するには

GAバージョンとは異なり、デバイス登録タスクのEAバージョンはOktaAdmin 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：Registration Taskのバージョン。Registration Taskの最新バージョンについては、「Windows向けDevice Trustデスクトップ登録タスクバージョン履歴」を参照してください。

  • <msi/exe>はRegistration Taskのファイルタイプであり、.msiまたは.exeです。

たとえば、.msi Registration Task version 1.4.0をexample.oktapreview.comにリンクする場合、次のようになります。

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

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

Registration Taskの一般利用可能な（GA）バージョンを取得するには

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

  1. Admin Consoleで［Settings（設定）］［Downloads（ダウンロード）］に移動します。
  2. ［Okta Device Trust for Windows Agents（Windows向けOktaDevice Trustエージェント）］までスクロールし、使用するインストーラータイプ（.msiまたは.exe）の［Download Latest（最新をダウンロード）］をクリックします。

Registration Taskのインストール

以下のいずれかの方法でRegistration Taskをインストールします。

方法1：管理ツール（SCCM）を使用してRegistration Taskを配信する

Organizationの手順に従って、ドメイン参加ワークステーションにソフトウェアを配信します。OrganizationがSCCMを使用する場合は、Microsoft記事 「How to Deploy Applications in Configuration Manager（構成マネージャーでアプリケーションをデプロイする方法）」を参照してください。*.exeまたは*.msiのインストールに適切なコマンドを実行します。

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

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

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

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

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

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

プロキシサーバー環境

HttpProxy=http://<お使いのプロキシのhttp url>:<ポート番号>

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

MSIのインストール：

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ HttpProxy=http://<お使いのプロキシのhttp url>:<ポート番号>"

EXEのインストール：

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com HttpProxy=http://<お使いのプロキシのhttp url>:<ポート番号>

証明書の自動処理を無効にするパラメーターも追加する場合は、必ずスペースを入れてください。

プロキシ自動構成（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://<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との証明書交換を完了する際に妨げにならないように、プロキシサーバー/プロキシクライアント、および実装しているエンドポイント保護ソフトウェアを設定してください。たとえば、許可リストを使用して送信トラフィックを制限している場合、ワイルドカード文字（*）を含めたこれらの正確な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://<お使いの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：Registration Taskの手動インストール

この手順は、概念実証または実装時にRegistration Taskをインストールするものです。

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

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

アプリサインオンポリシールールでアプリに［Trusted（信頼）］オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアに証明書がインストールされていることを確認する必要があります。証明書がインストールされておらず、［Trusted（信頼）］の設定が有効になっている場合、ユーザーはアプリへのアクセスを拒否され、管理者に連絡するようにとのセキュリティメッセージにリダイレクトされます。（詳細情報への［Learn more（詳細）］リンクを含めるようにメッセージを設定できます。「OrgのグローバルDevice Trust設定を有効にする」を参照してください）。証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアーを解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。Okta MTLS証明書を探します。

エンドユーザーがディアクティベートされると、ドメイン参加WindowsコンピューターにインストールされているすべてのDevice Trust証明書が自動的に失効化します（削除はされない）。失効化した証明書を削除するには、「Device Trust証明書の失効化と削除 」を参照してください。

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

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

  1. ［Start（スタート）］に移動して、［Search（検索）］フィールドにeventと入力します。
  2. ［Event Viewer（イベントビューア）］が［Start（スタート）］メニューのトップに表示されたら、Enterを押して開きます。
  3. ［Applications and Services Logs（アプリケーションとサービスログ）］を展開します。
  4. ［Okta Device Trust］をクリックしてEvent ID1000を見つけます。

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 certificate（Okta MTLS証明書）］が表示されます。

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

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

Registration TaskまたはGPOを通して証明書の自動選択を構成しないオプションを選んだ場合、エンドユーザーはアプリにアクセスする時に証明書を選択するように求められます。その場合、エンドユーザーが選択しやすいように、Okta Device Trust証明書のみが表示されます。

更新頻度によっては、GPOを使用して行った変更はWindowsクライアント​コンピューターに即時表示されない場合があります。詳細は、Microsoft記事「Group Policy refresh interval for computers（コンピューターのグループポリシー更新頻度）」を参照してください。

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

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

    コピー元：

    C:\end users\Administrator\Desktop\policy_templates\windows\admx\en-US\chrome.adml

    コピー先：

    C:\Windows\PolicyDefinitions\en-US\

    コピー元：

    C:\end users\Administrator\Desktop\policy_templates\windows\admx\Chrome.admx

    コピー先：

    C:\Windows\PolicyDefinitions\

  4. グループポリシー管理者コンソール（GMPC）を開きます。
    1. ［Start（スタート）］メニューにRunと入力します。
    2. ［Run（実行）］にgpmc.mscと入力します。
  5. 適切なドメインまで展開して［Group Policy Objects（グループポリシーオブジェクト）］に移動し、［Default Domain Policy（デフォルトドメインポリシー）］を右クリックして［Edit（編集）］をクリックします。

  6. ［Computer Configuration（コンピューターの構成）］［Policies（ポリシー）］［Administrative Templates: Policy definitions (ADMX files)（管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル））］［Google Chrome］［Content Settings（コンテンツ設定）］に移動します。
  7. 右ペインで［Automatically select client certificate for these sites（これらのサイトのクライアント証明書を自動選択する）］を選択し、［Content Settings（コンテンツ設定）］の下で［Edit policy setting（ポリシー設定を編集）］をクリックします。

  8. 開いたダイアログボックスで［Enabled（有効）］をクリックします。
  9. ［Options（オプション）］の下で［Show（表示）］をクリックします。
  10. ［Show Contents（内容の表示）］ダイアログボックスにOrgのサブドメインを指定し、Preview Orgと実働Orgのいずれに適用するかを示す値を入力します。

    例：

    OktaPreview 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"}}}

  11. ［OK］をクリックします。
  12. 自動証明書の設定がされていることを確認します。
    1. 次回のGPO更新まで待つか、gpupdateコマンドを発行して、GPOを更新します。
    2. Chromeのアドレスバーに「chrome://policy」と入力し、Enterキーを押します。

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

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

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

    1. ［Start（スタート）］に移動し、［検索］フィールドにregeditと入力します。
    2. レジストリエディターで次のように移動します： HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChromeAutoSelectCertificateForUrls

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（ポリシー）］［Administrative Templates: Policy definitions (ADMX files) （管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル））］［Windows Components（Windowsコンポーネント）］［Internet Explorer］［Internet Control Panel（インターネットコントロールパネル）］［Security Page（セキュリティページ）］［Trusted Sites Zone（信頼済みサイトゾーン）］に移動します。
  4. 右ペインの［Settings（設定）］の下で［Don't prompt for client certificate selection when no certificates or only one certificate exists（証明書がないか1つしかない場合にはクライアント証明書の選択をプロンプトしない）］をダブルクリックします。

  5. 開いたダイアログボックスで［Enabled（有効）］をクリックします。
  6. 開いているウィンドウを閉じます。
  7. ［Computer Configuration（コンピューターの構成）］［Policies（ポリシー）］［Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer（管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル））］［Windows Components（Windowsコンポーネント）］［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（信頼済みサイトゾーン）］に対応します。

  12. ［OK］をクリックして開いているウィンドウを閉じます。
  13. GPOの設定が構成されていることを確認します。
    1. 次回のGPO更新まで待つか、コマンドラインでgpupdateコマンドを発行してGPOを更新します。
    2. ［Start（スタート）］メニューにRunと入力します。
    3. ［Run（実行）］にgpedit.mscと入力し、［Enter］キーを押します。
    4. ［Computer Configuration（コンピューターの構成）］［Policies（ポリシー）］［Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer（管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル））］［Windows Components（Windowsコンポーネント）］［Internet Explorer］［Internet Control Panel（インターネットコントロールパネル）］［Security Page（セキュリティページ）］［Internet Zone（インターネットゾーン）］に移動します。
    5. 右ペインの［Settings（設定）］の下で［Don't prompt for client certificate selection when no certificates or only one certificate exists（証明書がないか1つしかない場合にはクライアント証明書の選択をプロンプトしない）］をダブルクリックします。
    6. 開いたダイアログボックスで設定が［Enabled（有効）］であることを確認します。

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

アプリサインオンポリシールールについて

［App Sign On Rule（アプリサインオンルール）］ダイアログボックス内のすべてのクライアント​オプションはデフォルトで事前選択されています。アプリへのアクセスを詳細設定するには、以下を反映させるルールを作成します。

  • 対象となるユーザー、または対象者が属するグループ
  • 対象者がネットワークに接続しているか、接続していないか、定義されたネットワークゾーンに属しているか
  • 対象者のデバイスで実行されているクライアントのタイプ（Office 365アプリのみ）
  • 対象者のモバイルまたはデスクトップ​デバイスのプラットフォーム
  • 対象者のデバイスが信頼されているかどうか

サインオンポリシールールへの許可リストによるアプローチ

  1. アプリへのアクセスを許可するシナリオをサポートする1つまたは複数の許可ルールを作成し、これらのルールに最高優先度を割り当てます。
  2. ステップ1で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストのアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。

アプリサインオンポリシールールの作成に関する重要なセキュリティ情報については、「アプリのサインオンポリシー」を参照してください。

手順

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

この例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。他のアプリでは、［If the user's client is any of these（ユーザーのクライアントが次のいずれかに該当する場合）］セクションは表示されません。

許可リストの例

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

  1. ルールに記述名を付けて入力します。
  2. ［PEOPLE（ユーザー）］で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  3. ［LOCATION（ロケーション）］で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  4. ［CLIENT（クライアント）］で、次の設定を構成します。
    • ［Web browser（Webブラウザー）］の選択を解除します。
    • ［Modern Auth client（Modern Authクライアント）］の選択を解除します。
    • ［Exchange ActiveSync client or Legacy Auth client（Exchange ActiveSyncクライアントまたはレガシー認証クライアント）］を選択します。
    • モバイル
    • ［iOS］を選択します。
    • ［Android］を選択します。
    • ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
    • デスクトップ
    • ［Windows］を選択します。
    • ［macOS］を選択します。
    • ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します
  5. ［Device Trust（Device Trust）］で以下を構成します。

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

    • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
    • ［Other mobile (for example, BlackBerry)（他のモバイル（BlackBerryなど））］
    • ［Other desktop (for example, Linux)（他のデスクトップ（Linuxなど））］
    • ［Any（すべて）］を選択します。
    • ［Trusted（信頼）］を選択解除します。
    • ［Not trusted（非信頼）］を選択解除します。
  6. ［Access（アクセス）］を構成します。

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

  7. ［Save（保存）］をクリックします。
  8. ［Rule 2（ルール2）］を作成します。

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

  1. ルールの記述名を入力します。
  2. ［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。［ユーザー］オプションは、この例のすべてのルールで同じでなければなりません。
  3. ［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。［Location（場所）］オプションは、この例のすべてのルールで同じでなければなりません。
  4. ［CLIENT（クライアント）］で、次の設定を構成します。
    • ［Web browser（Webブラウザー）］を選択します。
    • ［Modern Auth client（Modern Authクライアント）］を選択します。
    • ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］を選択解除します。
    • モバイル
    • ［iOS］を選択解除します。
    • ［Android］を選択解除します。
    • ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
    • デスクトップ
    • ［Windows］を選択します。
    • ［macOS］を選択解除します。
    • ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します。
  5. ［Device Trust（Device Trust）］で以下を構成します。

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

    • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
    • ［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. ［Rule 3（ルール3）］を作成します。

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

  1. ルールの記述名を入力します。
  2. ［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
  3. ［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
  4. ［CLIENT（クライアント）］で、次の設定を構成します。
    • ［Web browser（Webブラウザー）］を選択します。
    • ［Modern Auth client（Modern Authクライアント）］を選択します。
    • ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］を選択解除します。
    • モバイル
    • ［iOS］を選択します。
    • ［Android］を選択します。
    • ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
    • デスクトップ
    • ［Windows］を選択します。
    • ［macOS］を選択します。
    • ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します。
  5. ［Device Trust（Device Trust）］で以下を構成します。

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

      • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
      • ［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. ［Rule 4（ルール4）］を作成します。

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

  1. ルールの記述名を入力します。
  2. ［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
  3. ［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
  4. ［CLIENT（クライアント）］で、次の設定を構成します。
    • ［Web browser（Webブラウザー）］を選択します。
    • ［Modern Auth client（Modern Authクライアント）］を選択します。
    • ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］を選択します。
    • モバイル
    • ［iOS］を選択します。
    • ［Android］を選択します。
    • ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
    • デスクトップ
    • ［Windows］を選択します。
    • ［macOS］を選択します。
    • ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します。
  5. ［Device Trust（Device Trust）］で以下を構成します。

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

      • ［Exchange ActiveSync or Legacy Auth client（Exchange ActiveSyncまたはレガシー認証クライアント）］
      • ［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で再度保護するには、新しい証明書を登録する前に、撤回した証明書をコンピューターから削除する必要があります。

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

  • この手順のステップ1～4では、Okta認証局からエンドユーザーに発行されたすべてのDevice Trust証明書が失効になります。証明書の失効は、管理されたWindowsコンピューターから既存の証明書を削除するものではありません。証明書を失効させたWindowsコンピューターをDevice Trustで再保護するには、まずコンピューターから既存のDevice Trust証明書を削除し、手順5で説明するように新しい証明書でコンピューターを再登録する必要があります。デバイス登録タスクでは、コンピューターに別の証明書が存在する場合（失効したかどうかにかかわらず）、新しい証明書を登録しません。
  • Oktaでエンドユーザーを非アクティブ化すると、Okta認証局からのDevice Trust証明書も失効します（ただし、コンピューターから証明書が削除されるわけではありません）。
  1. Admin Consoleで、［Directory（ディレクトリ）］［People（ユーザー）］に進みます。

  2. Device Trust証明書を失効させるエンドユーザーをクリックします。

  3. ［More Actions（その他のアクション）］メニューで、［Revoke Trust Certificate（信頼証明書を取り消す）］をクリックします。

  4. 表示されるメッセージを確認し、［Revoke Trust Certificate（信頼証明書を取り消す）］をクリックします。

  5. 任意。エンドユーザーのコンピューターをDevice Trustで再度保護する場合は、まずコンピューターから既存のDevice Trust証明書をすべて削除します。

    • 証明書を単一のコンピューターから削除する場合は（実装のテスト段階や概念実証段階など）、Certificate Manager Tool（Certmgr.exe）などのサードパーティ製管理ツールを使用して、Okta MTLS認証局から発行された証明書を削除します。

    • 証明書を複数のコンピューターから削除する場合は、GPOやSCCMなどのサードパーティ製管理ツールを使用して、Okta MTLS認証局から発行された証明書を削除します。

トラブルシューティング

Okta Device Trust for Windowsは、ドメインで結合した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設定を有効にしていることを確認します。

Registration Task

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

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

「Registration Taskのインストール」を参照してください。

証明書

証明書がインストールされていることを確認します。

  1. Microsoft管理者コンソールを開きます。「Microsoft管理者コンソールで確認する」を参照。
  2. エンドユーザーの個人用ストアを開きます（ローカルコンピューターストアではなく）。
  3. ［MTLS Certificate Authority（MTLS認証局）］によって発行された単一の証明書が［Personal（個人）］［Certificates（証明書）］に表示されていることを確認します。
  4. 証明書が表示されない場合は「高度なトラブルシューティング」を参照してください。

既知の問題 – 相互のTLS証明書交換のブロックによる認証失敗

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

*.okta.com

*.okta-emea.com

*.okta-gov.com

サインオンポリシー

以下を確認します。

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

  • Device Trustで保護したいWS-FedまたはSAMLアプリに適用されている。
  • 正しいユーザーおよび/またはグループに適用されている。
  • 最低限、非信頼デバイスへのアクセスを拒否するアクティブなルールが含まれている。

システムログ

システムログを確認し、以下の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

更新

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

DebugContextで一意のデバイスIDを表示する

DebugDataは、Device Trustイベントに関連したデバイスの一意のIDを示します。これはデバッグ目的で有用です。またこの情報は、デバイスインベントリ内のデバイスにDevice Trustが適用されていることを確認するのに役立ちます。この確認は、大きなユーザーグループに機能を展開する前に有用となりえます。

debugContext.debugDataに含まれる情報は、お客様のプラットフォームの問題をトラブルシューティングする際に、コンテキストを追加するためのものです。キー名や値は予告なく変更されることがありますので、データ契約としてではなく、主にデバッグの補助に使用するようにしてください。Okta開発者用ドキュメントの「DebugContextオブジェクト」を参照してください。

  1. Admin Consoleで、［Reports（レポート）］［System Log］に移動します。
  2. 関心のあるDevice Trustイベント（日付）を検索し、［Event（イベント）］［AuthenticationContext］［System（システム）］［DebugContext］［DebugData］に移動します。

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

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

Okta Admin Consoleで、

次を確認します。

  • OrgにアクティブなActive Directory（AD）統合（［Directory（ディレクトリ）］［Directory Integrations（ディレクトリの統合）］）がある
  • ドメイン参加Windowsコンピューターのエンドユーザーが：
    • ［Directory（ディレクトリ）］［People（ユーザー）］に存在する
    • アクティブ化されている
    • Active Directoryドメインのメンバー
  • IWA Webアプリは：
    • プライマリ
    • 有効
  • Device Trust対応バージョン

（［Security（セキュリティ）］［Delegated Authentication（委任認証）］［IWA Agents（IWAエージェント）］）

IWAサーバー上

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

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

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

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

［Windows Logs（Windowsログ）］［Applications（アプリケーション）］と［Services Logs（サービスログ）］［Okta Single Sign On（Oktaシングルサインオン）］のエラーをチェックします。

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

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

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

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

［Windows Logs（Windowsログ）］［Applications（アプリケーション）］と［Services Logs（サービスログ）］ ［Okta Device Trust］のエラーをチェックします。

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

特定の状況下で証明書の更新を強制実行する

証明書の有効期限は1年間で、有効期限満了の30日前までに自動更新されます。自動更新が正常に実行されるには、エンドユーザーがドメイン参加したコンピューターにログオンしており、企業ネットワークに接続されている必要があります。

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

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

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

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

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

  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によって保護されている複数のアプリが、エンドユーザーがIEまたは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 Technical Overview（Schannel SSP技術概要）」を参照してください。
  • .NETバージョンのチェック：デバイス登録タスクは、管理対象のWindowsコンピューターで実行されている.NET Frameworkのバージョンを確認します。バージョンが4.5.2以降でない場合、Registration Taskによってバージョン4.5.2が自動的にインストールされ、インストール中はエンドユーザーの画面に進捗インジケーターやその他のインストールダイアログボックスが表示されます。