マネージドWindowsコンピューターに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の資料を参照してください。

複数フォレスト環境でのDevice Trustの登録には、IWA Webアプリのバージョン1.12.2以降が必要です。

あるフォレストで実行されている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の記事「Updated Office 365 modern authentication（更新された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（信頼）］オプションを設定する前に、このDevice Trustソリューションの対象となるドメインに参加しているコンピューターの証明書ストアに証明書がインストールされていることを確認する必要があります。

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

証明書の登録を確認するために、Oktaでは管理ツールを使用してWindowsイベントビューアーを解析するか、コマンドラインを使用してユーザー証明書ストアに直接クエリを行うことをお勧めします。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（ファイルシステム）］または［Registry（レジストリ）］を必ず指定してください。インストールを検出する手段として［Windows Installer（Windowsインストーラー）］設定タイプを使用しないでください。その設定では、SCCMは［Device Registration Task（デバイス登録タスク）］を検出できません。
クライアントがMTLSハンドシェイクを完了できることを確認します。プロキシサーバー、プロキシクライアントまたはエンドポイント保護ソフトウェアをOrgで実装している場合は、このDevice Trustフローで行われる相互TLS証明書交換（ハンドシェイク）をブロックしない方法で設定してください。「トラブルシューティング」を参照してください。
Windows向けOkta Device Trustは、複数のエンドユーザーが同じドメイン参加ワークステーションにサインインする共有端末のシナリオをサポートしていません。
Device Trustによって保護されたアプリは、Okta End-User Dashboardにロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。
- エンドユーザーがデスクトップまたはモバイルのブラウザー（Okta Mobile以外）でダッシュボードにアクセスした。
- OrgでDevice Trustが有効になっている。
- デバイスが信頼されていない。
- エンドユーザーがダッシュボードからDevice Trustで保護されたアプリにアクセスしようとした。

手順

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

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

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

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

この任意フィールドにURLを指定しないオプションを選択した場合、これらのエンドユーザーには同じメッセージが表示されますが、［Learn more（詳細）］リンクは表示されません。
［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がWindowsコンピューターに証明書を発行し、OktaフェデレーションアプリへのDevice Trustフローを有効にします。

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

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

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

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

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

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

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>

以下に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>

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

iisreset /stop

iisreset /start
先に進む前に、IWA Webアプリを「デスクトップSSO用にIWA Webアプリをインストールして構成する」に示す手順どおりに再起動します。
まだ行っていない場合は、［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でエンドユーザーの証明書を誤って失効した（「失効」を参照）。
不慮の削除、ファイルの破損、または秘密鍵の喪失により、クライアント上の証明書が破損した。

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

証明書の自動選択

［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）証明書交換（ハンドシェイク）を妨げないように構成します。
「トラブルシューティング」を参照してください。

証明書の失効化

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クライアントを検出できません。

登録タスクの取得

Trusted Platform Module（TPM）にあるセキュリティ上のメリットを活用するには、「Trusted Platform Module（TPM）でWindows向け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 for バージョン履歴」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

［Device Registration Task（デバイス登録タスク）］のバージョン1.2.2以降をコマンドラインからインストールし、インストールコマンドに適切なHttpProxyパラメーターを追加します。これは、［Device 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との証明書交換を完了する際に妨げにならないように、プロキシサーバー、プロキシクライアント、および実装するエンドポイント保護ソフトウェアを構成してください。たとえば、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（デバイス登録タスク）］を手動でインストールするものです。

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

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

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

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

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

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

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

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

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

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

［Start（スタート）］に移動して、［Search（検索）］フィールドにmmcと入力してコンソールを開きます。
［File（ファイル）］に移動して［Add/Remove Snap-in（スナップインの追加と削除）］をクリックします。
［Certificates（証明書）］を選択し、［Add（追加）］をクリックします。
［Certificates snap-in（証明書スナップイン）］ダイアログで、［My user account（マイユーザーアカウント）］を選択します。
［Finish（終了）］をクリックします。
［OK］をクリックします。
［Console Root（コンソールルート）］で、［Certificates - Current User（証明書 - 現在のユーザー）］を展開します。
［Personal（個人）］フォルダを展開し、［Certificates（証明書）］をクリックします。［Okta MTLS certificate（Okta MTLS証明書）］を確認します。

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証明書のみが表示されます。

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

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

ポリシーテンプレートをダウンロードし、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\にコピー
グループポリシー管理者コンソール（GMPC）を開きます。
1. ［Start（スタート）］メニューに［Run（実行）］と入力します。
2. ［Run（実行）］にgpmc.mscと入力します。
適切なドメインまで展開して［Group Policy Objects（グループポリシーオブジェクト）］に移動し、［Default Domain Policy（デフォルトドメインポリシー）］を右クリックして［Edit（編集）］をクリックします。
［Computer Configuration（コンピューターの構成）］［Policies（ポリシー）］［Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer（管理テンプレート：ローカルコンピューターから取得したポリシー定義（ADMXファイル））］［Google Chrome］［Content Settings（コンテンツ設定）］に移動します。
右ペインで［Automatically select client certificate for these sites（これらのサイトのクライアント証明書を自動選択する）］を選択し、［Content Settings（コンテンツ設定）］の下で［Edit policy setting（ポリシー設定を編集）］をクリックします。
開いたダイアログで［Enabled（有効）］をクリックします。
［Options（オプション）］の下で［Show（表示）］をクリックします。
［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"}}}
［OK］をクリックします。
自動証明書の設定がされていることを確認します。
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を構成するには

Active Directoryドメインコントローラーから、グループポリシー管理者コンソール（GMPC）を開きます。
1. ［Start（スタート）］メニューにRunと入力します。
2. ［Run（実行）］でgpmc.mscと入力し、Enterキーを押します。
適切なドメインまで展開して［Group Policy Objects（グループポリシーオブジェクト）］に移動し、［Default Domain Policy（デフォルトドメインポリシー）］を右クリックして［Edit（編集）］をクリックします。
［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（信頼済みサイトゾーン）］に移動します。
右ペインの［Settings（設定）］の下で［Don't prompt for client certificate selection when no certificates or only one certificate exists（証明書がないか1つしかない場合にはクライアント証明書の選択をプロンプトしない）］をダブルクリックします。
開いたダイアログで［Enabled（有効）］をクリックします。
開いているウィンドウを閉じます。
［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（セキュリティページ）］に移動します。
右ペインの［Settings（設定）］の下で［Site to Zone Assignment List（サイトからゾーンへの割り当てリスト）］をダブルクリックします。
開いたダイアログで［Enabled（有効）］をクリックします。
［Options（オプション）］の下の［Enter the zone assignments here（ゼロ割り当てをここに入力）］の隣の［Show（表示）］をクリックします。
［Show Contents（内容の表示）］ダイアログに以下を入力します。
1. この機能をOkta本番OrgとPreview Orgのいずれにデプロイするかに応じて、［Value name（値の名前）］列にhttps://*.okta.comまたはhttps://*.oktapreview.comと入力します。
2. ［Value（値）］列に2と入力します。この値は、ステップ3で構成したセキュリティゾーン設定の［Trusted sites zone（信頼済みサイトゾーン）］に対応します。
［OK］をクリックして開いているウィンドウを閉じます。
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で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストのアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。

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

手順

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

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

許可リストの例

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

ルールに記述名を付けて入力します。
［PEOPLE（ユーザー）］で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
［LOCATION（ロケーション）］で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
［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など）を選択します
［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（信頼できない）］の選択を解除します。
［Access（アクセス）］を構成します。

［Allowed（許可）］を選択します。
［Save（保存）］をクリックします。
［Rule 2（ルール2）］を作成します。

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

ルールの記述名を入力します。
［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。ユーザーオプションは、この例のすべてのルールで同じでなければなりません。
［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じロケーションオプションを選択します。ロケーションオプションは、この例のすべてのルールで同じでなければなりません。
［CLIENT（クライアント）］で、次の設定を構成します。
- ［Web browser（Webブラウザー）］を選択します。
- ［Modern Auth client（Modern Authクライアント）］を選択します。
- ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］の選択を解除します。
- Mobile（モバイル）
- ［iOS］の選択を解除します。
- ［Android］の選択を解除します。
- ［Other mobile (e.g. BlackBerry)（他のモバイル（BlackBerryなど））］の選択を解除します。
- デスクトップ
- ［Windows］を選択します。
- ［macOS］の選択を解除します。
- ［Other desktop (e.g. Linux)（他のデスクトップ（Linuxなど））］の選択を解除します。
［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（信頼できない）］の選択を解除します。
［Access（アクセス）］を構成します。
- ［Allowed（許可）］を選択します。
- ［Prompt for factor（要素をプロンプト）］を選択します。
［Save（保存）］をクリックします。
［Rule 3（ルール3）］を作成します。

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

ルールの記述名を入力します。
［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じ［Location（ロケーション）］オプションを選択します。このオプションは、この例のすべてのルールで同じでなければなりません。
［CLIENT（クライアント）］で、次の設定を構成します。
- ［Web browser（Webブラウザー）］を選択します。
- ［Modern Auth client（Modern Authクライアント）］を選択します。
- ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］の選択を解除します。
- Mobile（モバイル）
- ［iOS］を選択します。
- ［Android］を選択します。
- ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
- デスクトップ
- ［Windows］を選択します。
- ［macOS］を選択します。
- ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します
［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（信頼できない）］の選択を解除します。
［Access（アクセス）］を構成します。
- ［Allowed（許可）］を選択します。
- ［Prompt for factor（要素をプロンプト）］を選択します。
［Save（保存）］をクリックします。
［Rule 4（ルール4）］を作成します。

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

ルールの記述名を入力します。
［PEOPLE（ユーザー）］で、［Rule 1（ルール1）］で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
［LOCATION（ロケーション）］で、［Rule 1（ルール1）］で選択したものと同じロケーションオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
［CLIENT（クライアント）］で、次の設定を構成します。
- ［Web browser（Webブラウザー）］を選択します。
- ［Modern Auth client（Modern Authクライアント）］を選択します。
- ［Exchange ActiveSync client（Exchange ActiveSyncクライアント）］を選択します。
- モバイル
- ［iOS］を選択します。
- ［Android］を選択します。
- ［Other mobile（他のモバイル）］（BlackBerryなど）を選択します。
- デスクトップ
- ［Windows］を選択します。
- ［macOS］を選択します。
- ［Other desktop（他のデスクトップ）］（Linuxなど）を選択します。
［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（信頼できない）］の選択を解除します。
［Access（アクセス）］を構成します。

［Denied（拒否）］を選択します。
［Save（保存）］をクリックします。

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

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

Device Trust証明書の失効と削除

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

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

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

Admin Consoleで、［Directory（ディレクトリ）］［People（ユーザー）］に移動します。
Device Trust証明書を失効させるエンドユーザーをクリックします。
［More Actions（その他のアクション）］メニューで、［Revoke Trust Certificate（信頼証明書を取り消す）］をクリックします。
表示されるメッセージを確認し、［Revoke Trust Certificate（信頼証明書を取り消す）］をクリックします。
任意。エンドユーザーのコンピューターを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設定を有効にしていることを確認します。

登録タスク

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

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

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

証明書

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

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

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

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

Admin Consoleで［Reports（レポート）］［System Log（システムログ）］に移動します。
関心のある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対応バージョン

IWAサーバー上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コマンドプロンプトを開いて次のコマンドを発行します。"C:\Program Files\Okta\DeviceTrust\OktaDeviceReg.exe" --user --forceRenewal

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

タスクの実行中にIWAサーバーにアクセスできることを確認します（インターネットで直接またはVPN経由で）。
コマンドプロンプトを開いて次のコマンドを発行します。

"C:\Program Files\Okta\DeviceTrust\OktaDeviceReg.exe" --user --debug
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 Technical Overview（Schannel SSP技術概要）」を参照してください。
［Device Registration Task（デバイス登録タスク）］は、管理対象のWindowsコンピューターで実行されている.NET Frameworkのバージョンを確認します。バージョンが4.5.2以降でない場合、［Device Registration Task（デバイス登録タスク）］によってバージョン4.5.2が自動的にインストールされ、インストール中はエンドユーザーページに進捗インジケーターやその他のインストールダイアログが表示されます。