マネージド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組織が属するセルが読み取り専用モード
  • プロキシサーバー環境のサポート:このDevice Trustソリューションを、プロキシサーバーを実装する環境で機能させるには、Device Registration Taskバージョン1.2.1以降をコマンドラインからインストールし、適切なHttpProxyパラメータをインストールコマンドに追加する必要があります。「Registration Taskのインストール」を参照してください。
  • 証明書がターゲットコンピューターにインストールされていることを確認する:アプリのサインオンポリシールールでアプリに[Trusted(信頼)]オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアに証明書がインストールされていることを確認する必要があります。証明書がインストールされておらず、[Trusted(信頼)]の設定が有効になっている場合、ユーザーはアプリへのアクセスを拒否され、管理者に連絡するようにとのセキュリティメッセージにリダイレクトされます。(詳細情報への[Learn more(詳細)]リンクを含めるようにメッセージを設定できます。「組織のグローバルDevice Trust設定を有効にする」を参照してください)。証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアーを解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。 Okta MTLS証明書を探します。
  • Windowsのデバイストラスト設定を無効にする場合は注意が必要:信頼済みのWindowsデバイスを許可するアプリサインオンポリシーも構成している場合は、[Security(セキュリティ)]>[Device Trust(デバイスの信頼)]ページでWindowsのデバイストラスト設定を無効にしないでください。この設定を無効にすると、Device Trustの設定が一貫性のない状態になり、非信頼デバイスを使用しているユーザーに、管理者への連絡を促すセキュリティメッセージや、[Learn more(詳細)]リンクが表示されなくなります(設定されている場合は、「組織のグローバルのDevice Trustの設定を有効化する」を参照してください)。
  • Oktaサポートに Okta Device Trust for Windowsの無効化を依頼する前に:まず、アプリのサインオンポリシールールの[Device Trust]設定を[Any(任意)]に変更してください([Applications(アプリケーション)]>[app(アプリ)]>[Sign On(サインオン)])。この変更を行わず、後でOktaサポートに組織のDevice Trust機能の再有効化を依頼した場合、アプリのサインオンポリシールールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。

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

  • クライアントがMTLSハンドシェイクを完了できるようにする:プロキシサーバー/プロキシクライアントまたはエンドポイント保護ソフトウェアを組織で実装している場合は、このDevice Trustフローで行われる相互のTLS証明書交換(ハンドシェイク)をブロックしない方法で設定してください。「トラブルシューティング」を参照してください。
  • 端末共有のシナリオはサポートされていない:Okta Device Trust for Windowsは、複数エンドユーザーが同じドメイン参加ワークステーションから同じアカウントにログインする共有端末のシナリオをサポートしていません。
  • Device Trustによって保護されたアプリは、Okta End-User Dashboard(Oktaエンドユーザーダッシュボード)にロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。

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

手順

これらの手順は次の3つの主要ステップから成ります。

ステップ1. 組織のグローバルDevice Trust設定を有効にする

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

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

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

  5. [Save(保存)]をクリックします。
  6. ステップ2に進みます。

ステップ2. Device Trust証明書をドメイン参加Windowsコンピューターに登録する

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

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アプリとやり取りする必要がなくなります。Okta Device Trust for Windowsデスクトップが機能する条件として、デスクトップSSOを [Security(セキュリティ)] >[Delegated Authentication(代理認証)][On(オン)] にする必要はありません。

  1. IWA Webアプリをダウンロードするには、次のリンクを構成します。
  2. https://<org>.<okta/oktapreview>.com/static/agents/iwa/OktaSsoIwa-x.x.x.exe

    以下のようになります。

    • <org>:組織の名前
    • <okta/oktapreview>Oktaの本番環境またはプレビュー環境。
    • oktaSsoIwa-x.x.x.exeは、Device Trust for WindowsをサポートするIWA Webアプリのバージョン。最新のDevice Trust対応バージョンについては、「SSO IWA Webアプリのバージョン履歴」を参照してください。

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

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

  3. Okta IWA Webアプリを「Desktop SSO用にOkta IWA Webアプリをインストールして構成する」に詳述されている手順に従ってインストールします。
  4. IWA Webエージェントが運用可能であることを確認するには、このガイドに示す手順どおりにテストします。
  5. 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. まだの場合、Device Registration Taskを「Device Registration Taskを取得してインストールする」に示す手順どおりにインストールします。

2.2:Device Registration Taskを取得してインストールする

開始する前に知っておくべき重要事項

Trusted Platform Module(TPM)

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

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

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

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

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

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

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

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

証明書の手動更新を強制的に実行することで以下のような問題を修正できます(Device Registration Task 1.3.1以降が必要)。

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

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

証明書の自動選択

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

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

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

プロキシ・サーバー環境

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

  • Device Registration Task version 1.2.1以降をコマンド・ラインからインストールし、インストール・コマンドに適切なHttpProxyパラメーターを追加します。

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

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

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

証明書の失効化

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

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

SCCMで適切な設定タイプを使用して、Device Registration Taskのインストールを確認します。

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バージョンとは異なり、Device Registration TaskのEAバージョンはOkta管理コンソールの[Downloads(ダウンロード)]ページからは利用できません。EAバージョンを取得するには、以下のようにリンクを構成する必要があります。

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

以下のようになります。

  • <org>:組織の名前

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

  • OktaDeviceRegistrationTaskSetup-x.x.x:Registration Taskのバージョン。Registration Taskの最新バージョンについては、「Device Trust for Windows Desktop Registration Taskバージョン履歴」を参照してください。

  • <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

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

Registration Taskの一般に入手可能な(GA)バージョンを取得するには

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

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

Registration Taskのインストール

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

方法1:管理ツール(SCCM)を使用してRegistration Taskを配信する

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

Device Registration Taskとプロキシサーバーについて

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

コマンドラインを使用してDevice Registration Taskをインストールし、パラメーターを含める

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

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

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

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

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

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

  1. [Start(スタート)]に移動して、検索フィールドに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を使用してブラウザーを構成し、証明書を自動的に選択します。

環境に適している場合、Device Registration Taskのデフォルト機能ではなく、グループポリシーオブジェクト(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. ファイルをフォルダにコピーします:
  4. コピー元:

    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\

  5. グループ・ポリシー管理コンソール(GMPC)を開きます。
    1. [Start(スタート)]メニューにRunと入力します。
    2. [Run(実行)]gpmc.mscと入力します。
  6. 適切なドメインまで展開し、[Group Policy Objects(グループポリシーオブジェクト)]に移動して、[Default Domain Policy(デフォルトドメインポリシー)][Edit(編集)]の順に選択します。
  7. [Computer Configuration(コンピューターの構成)]>[Policies(ポリシー)]>[Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer(管理テンプレート:ローカルコンピューターから取得したポリシー定義(ADMXファイル))]>[Google Chrome]>[Content Settings(コンテンツ設定)]に移動します。
  8. 右ペインで、[Automatically select client certificate for these sites(これらのサイトのクライアント証明書を自動選択する)]を選択し、[Content Settings(コンテンツ設定)]の下で[Edit policy setting(ポリシー設定を編集)]をクリックします。
  9. 開いたダイアログボックスで[Enabled(有効)]をクリックします。
  10. [Options(オプション)]の下で[Show(表示)]をクリックします。
  11. [Show Contents(内容の表示)]ダイアログ・ボックスに組織のサブドメインを指定し、プレビュー組織と実働組織のいずれに適用するかを示す値を入力します。
  12. 例:

    Oktaプレビュー組織のURLがhttps://[*.]oktapreview.comであれば、次の値を入力します。

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

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

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

  13. [OK]をクリックします。
  14. 自動証明書の設定がされていることを確認します。
    1. 次回のGPO更新まで待つか、gpupdateコマンドを発行して、GPOを更新します。
    2. Chromeのアドレスバーに「chrome://policy」と入力し、Enterキーを押します。
    3. [Show value(値を表示)]をクリックし、AutoSelectCertificateForUrlsというポリシーに次の値が表示されていることを確認します。
    4. {"pattern":"https://[*.]oktapreview.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}

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

    1. [Start(スタート)]に移動して、検索フィールドにregeditと入力します。
    2. レジストリエディターで、以下に移動します。
    3. >HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Google > Chrome > AutoSelectCertificateForUrls

Device Trust証明書を自動的に選択するようにIEを構成するには
  1. Active Directoryドメイン・コントローラーから、グループ・ポリシー管理コンソール(GMPC)を開きます。
    1. [Start(スタート)]メニューにRunと入力します。
    2. [実行]gpmc.mscと入力し、Enterキーを押します。
  2. 適切なドメインまで展開し、[Group Policy Objects(グループポリシーオブジェクト)]に移動して、[Default Domain Policy(デフォルトドメインポリシー)][Edit(編集)]の順に選択します。
  3. [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(セキュリティページ)]>[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本番組織とプレビュー組織のいずれにデプロイするかに応じて、[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. [実行]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. 管理コンソール[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. ルールにわかりやすい名前を付けて入力します。

条件:

  1. [PEOPLE(ユーザー)]で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  2. [LOCATION(ロケーション)]で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  3. [CLIENT(クライアント)]で、次の設定を構成します。
  4. [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]で以下を構成します。
  6. [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(非信頼)]を選択解除します。

アクション:

  1. [Access(アクセス)]を構成します。
  2. [Allowed(許可)]を選択します。

  3. [Save(保存)]をクリックします。
  4. [Rule 2(ルール2)]を作成します。

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

  1. ルールにわかりやすい名前を付けて入力します。

条件:

  1. [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。[People(ユーザー)]オプションは、この例のすべてのルールで同じでなければなりません。
  2. [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。[Location(場所)]オプションは、この例のすべてのルールで同じでなければなりません。
  3. [CLIENT(クライアント)]で、次の設定を構成します。
  4. [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]で以下を構成します。
  6. [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(非信頼)]を選択解除します。

アクション:

  1. [Access(アクセス)]を構成します。
  2. [Allowed(許可)]を選択します。

    [Prompt for factor(要素をプロンプト)]を選択します。

  3. [Save(保存)]をクリックします。
  4. [Rule 3(ルール3)]を作成します。

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

  1. ルールにわかりやすい名前を付けて入力します。

条件:

  1. [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
  2. [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
  3. [CLIENT(クライアント)]で、次の設定を構成します。
  4. [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]で以下を構成します。
  6. [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(非信頼)]を選択解除します。

アクション:

  1. [Access(アクセス)]を構成します。
  2. [Allowed(許可)]を選択します。

    [Prompt for factor(要素をプロンプト)]を選択します。

  3. [Save(保存)]をクリックします。
  4. [Rule 4(ルール4)]を作成します。

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

  1. ルールにわかりやすい名前を付けて入力します。

条件:

  1. [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
  2. [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
  3. [CLIENT(クライアント)]で、次の設定を構成します。
  4. [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]で以下を構成します。
  6. [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(非信頼)]を選択解除します。

アクション:

  1. [Access(アクセス)]を構成します。
  2. [Denied(拒否)]を選択します。

  3. [Save(保存)]をクリックします。

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

デフォルトのサインオンルールは作成済みで、編集できません。この例では、デフォルト・ルールがルール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. Okta 管理コンソールで、[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認証局から発行された証明書を削除します。

    • 証明書を複数のコンピューターから削除する場合は、GPOSCCMなどのサードパーティ製管理ツールを使用して、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

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

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

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

証明書

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

  1. Microsoft管理コンソールを開きます。「Microsoft管理コンソールで確認する」を参照。
  2. エンドユーザーの個人用ストアを開きます(ローカルコンピューターストアではなく)。
  3. 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. 管理コンソールで、[Reports(レポート)]>[System Log(システムログ)]に移動します。
  2. 関心のあるDevice Trustイベント(日付)を検索し、

    [Event(イベント)]>[AuthenticationContext]>[System(システム)]>[DebugContext]>[DebugData]に移動します

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

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

Okta管理コンソールで、

以下を確認します。

  • 組織がアクティブな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-devicetaskokta-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日前までに自動更新されます。自動更新が正常に実行されるには、エンドユーザーがドメイン参加したコンピューターにログオンしており、企業ネットワークに接続されている必要があります。

証明書の手動更新を強制的に実行することで以下のような問題を修正できます(Device Registration Task 1.3.1以降が必要)。

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

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

"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に連絡し、組織のIWAサーバーの場所を取得する。
    • IWAサーバーに連絡して、デバイス用のデバイス・トークンを生成する。
    • IWAサーバーに連絡して、デバイス・トークンに基づいてユーザー・トークンを生成する。
    • 生成したユーザートークンでOktaに連絡し、証明書を生成する。
    • 証明書をユーザーの個人用ストアにインストールする。

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

既知の問題

  • 複数のアプリが同時に開く:Device Trustによって保護されている複数のアプリが、エンドユーザーがIEまたはEdgeブラウザーからOktaダッシュボードにサインインしたときに自動的に開くように構成されている場合、Device Trustフローを完了できるアプリは1つのみです。残りのアプリへのアクセスは失敗し、エンドユーザーには管理者に連絡するようにアドバイスするメッセージが表示されます。「組織のグローバルのDevice Trustの設定を有効化する」を参照してください。
  • Okta Device Trust for Windows + SSO用証明書ベースIWA :このDevice Trustソリューションを構成すると、iOSおよびAndroidモバイル・デバイスのSSOをサポートするように組織が証明書ベースのIWAで構成されている場合、非互換性の問題が発生する可能性があります。この場合、Device Trust証明書IWA証明書がインストールされているWindowsコンピューターからIWAを使用してOktaにサインインするエンドユーザーに対して、デスクトップSSOフロー中に両方の証明書を含む証明書ピッカーが渡され、混乱が生じることがあります。エンドユーザーがDevice Trust証明書を選択すると、IWAフロー中に403エラーが表示されます。IISにある証明書を有効にすることで、1つの証明書のみがユーザーに表示されるようにできます。Microsoftの記事「Schannel SSP Technical Overview(Schannel SSP技術概要)」を参照してください。
  • .NETバージョンのチェック:Device Registration Taskは、管理対象のWindowsコンピューターで実行されている.NET Frameworkのバージョンを確認します。バージョンが4.5.2以降でない場合、Registration Taskによってバージョン4.5.2が自動的にインストールされ、インストール中はエンド・ユーザーの画面に進捗インジケーターやその他のインストール・ダイアログ・ボックスが表示されます。