Jamf ProマネージドのmacOSデバイスにOkta デバイスの信頼を強制適用する

Okta デバイス登録タスク v1.3.1は、Python 3に対応するためにリリースされました。Python 2.xのスクリプトが必要な場合は、デバイス登録タスク v1.2.1を参照してください。

Jamf ProマネージドmacOSデバイス用Okta デバイスの信頼を使用すると、管理外のmacOSデバイスから企業のSAMLやWS-Fedクラウドアプリにアクセスできないようにすることが可能です。Okta デバイスの信頼は、既知の安全なデバイスのみがOktaマネージドアプリにアクセスできることを保証します。

Jamf ProマネージドmacOSデバイスに対してOkta デバイスの信頼を強制適用する方法を示す図。

前提条件

このソリューションは、以下と連携します。

  • サポートされるmacOSのプラットフォーム、ブラウザー、およびオペレーティングシステムを実行しているAppleコンピューター。
  • Jamf Pro MDMソリューション
  • Oktaへの連携認証フローを実行する際に、管理対象コンピューター上のOktaキーチェーンにアクセス可能なブラウザーおよびネイティブアプリとして以下が挙げられます。
    • ブラウザー:Chromeブラウザー、Safariブラウザー
    • 先進認証対応のネイティブアプリ:
      • Box
      • Googleドライブ
      • Microsoft Office
      • Skype for Business
      • Slack
  • Okta デバイス登録タスクは、様々なタスク(会員登録、登録など)を完了させるPythonスクリプトです。このスクリプトの適切なバージョンを使用するにあたり、お使いのOSに応じて、次のいずれかを完了してください。
    • macOS 10.15.xx(Catalina)、11.xx(Big Sur)、または12.xx(Monterey)をお使いの場合は、Python 3をベースとした登録バージョン1.3.3以降をお使いください。
    • macOS 10.14.xx(Mojave)をお持ちで、現在登録スクリプト1.2.1以前をお使いの方は、そのまま使い続けるか、Python 3を使う前にCatalina、Big Sur、またはMontereyにアップグレードしてください。

はじめに

  • 安全なアプリケーションへのアクセスに使用されていないデバイスでは、デバイスの信頼のデプロイは更新されません。このため、安全なリソースへのアクセスを必要とするデバイスにのみ証明書を発行することをお勧めします。

  • Microsoft Officeアプリの保護には先進認証が必要:このデバイスの信頼ソリューションでMicrosoft Officeアプリを保護するには、先進認証のサポートが有効になっている必要があります。詳しくは、Microsoftのこちらの記事をご覧ください。レガシープロトコルを使用するOffice 365クライアントのセキュリティ保護については、「Office 365クライアントアクセスポリシー」を参照してください。
  • デバイスの信頼は、Microsoft Officeシック クライアントのすべてのバージョンでサポートされているわけではない:このデバイスの信頼ソリューションは、Microsoft Officeシッククライアントバージョン16.13.1および16.15で動作することがテストで確認されています。ただし、Microsoft Officeシッククライアントバージョン16.14(ビルド180610)では動作しません。

  • iCloudから他のAppleデバイスにOktaキーチェーンが転送されないようにする:DTでセキュリティ保護されたmacOSデバイスから他のAppleデバイスにiCloudでOktaキーチェーンが転送されないようにするには、Jamf Proで[Allow iCloud Keychain syncing(iCloudキーチェーンの同期を許可)]を無効にする設定プロファイルを作成することを強く推奨します。(注:同期を無効にすると、すべてのキーチェーンの転送がブロックされますのでご注意ください) 。「変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」を参照してください。
  • Webビューは、デバイス・キーチェーンにアクセスできる必要がある:マネージドmacOSコンピューターのデバイスの信頼は、Webビューを介した認証をサポートするSAML/WS-Fed対応の任意のアプリで動作します。認証を行うWebビューは、デバイス上のOktaキーチェーンにアクセス可能でなければなりません。認証フローで証明書を使用する際にエンドユーザーが同意を求められるのを防ぐため、Oktaでは次のアプリを許可しています。「デフォルトの許可リストを変更する」を参照してください。

    • Box
    • Chrome
    • Safari
    • Microsoft Office
    • Skype for Business
    • Googleドライブ
    • Slack
  • デバイスごとのバインドされていない証明書の制限:デバイスの信頼で保護されたmacOSデバイスから、デバイスの信頼で保護されたアプリケーションにユーザーが初めてアクセスしたときに、証明書が特定のユーザーに対してバインドされます。未使用の証明書はバインドが解除されます。Oktaでは、登録手続きを行うたびに、1つずつ、アンバウンド証明書を最大5件までデバイスに対して発行することができます。セキュリティ対策として、Oktaでは特定のデバイスに対してアンバウンド証明書を6件以上発行しないようにしています。アンバウンド証明書の上限に達しないようにするには、登録によってさらに証明書を取得しようとする前に、ユーザーがデバイスに既存するアンバウンド証明書を使用していることを確認する必要があります。登録の上限に達すると、Syslogに登録エラーが表示され、JAMFログに「Maximum enrollment limit of 5 certificates for a device is reached(デバイスの証明書が登録上限の5件に達しました)」というエラー​メッセージが表示されます。
  • Orgごとの登録制限:所定のmacOSデバイスは、1つのOkta orgのデバイスの信頼設定によってのみセキュリティ保護することができます。別の言い方をすれば、macOSデバイスを、複数のOkta orgのデバイスの信頼設定によって同時に保護することはできません。これは、デバイスに対して発行されるクライアント証明書が、特定のOrgのCAによって署名されているためです。この制限は、Oktaプレビューと本番環境のOrgに適用されます。
  • 端末共有のシナリオはサポートされていない:このデバイスの信頼ソリューションは、複数のOktaエンドユーザーが同じmacOSワークステーションから同じアカウントにログインする共有端末のシナリオをサポートしていません。
  • Oktaが読み取り専用モードのときはデバイスの信頼登録はサポートされない:Okta orgが属するセルが読み取り専用モード
  • エンドユーザーは、ブラウザーのキャッシュをクリアする必要があるかもしれない:一部のブラウザー(例:Chrome)では、デバイスの信頼証明書がキャッシュされます。証明書が自動的に更新された後(1年に1回)、これらのブラウザーは新しい証明書ではなく、期限切れの証明書をOktaに提示し続ける場合があります。その場合、エンドユーザーにはセキュリティ要件のメッセージが表示され、デバイスの信頼で保護されたアプリへのアクセスは拒否されます。Oktaでは、影響を受けるエンドユーザーに対して、ブラウザーを終了して再起動することにより、ブラウザーのキャッシュをクリアするようアドバイスすることを推奨しています (ブラウザーのウィンドウを閉じるだけでは不十分です)。
  • デバイスの信頼によって保護されたアプリは、Okta End-User Dashboard(Oktaエンドユーザーダッシュボード)にロック済みとして表示されます。次の条件下でデバイスの信頼によって保護されたアプリの横に、ロックアイコンが表示されます。

    • エンドユーザーがデスクトップまたはモバイルのブラウザー(Okta Mobile以外)でダッシュボードにアクセスした。
    • Orgでデバイスの信頼が有効になっている。
    • デバイスが信頼されていない。
    • エンドユーザーがダッシュボードからデバイスの信頼で保護されたアプリにアクセスしようとした。
  • アプリは先進認証に対応している必要がある:このデバイスの信頼ソリューションでMicrosoft Officeアプリを保護するには、先進認証のサポートを有効にする必要があります。詳しくは、Microsoftの記事「How modern authentication works for Office 2013 and Office 2016 client apps(Office 2013、Office 2016クライアントアプリでの先進認証の仕組み)」を参照してください。「Office 365クライアントアクセスポリシー」も参照してください。

  • このデバイスの信頼ソリューションの対象となるデバイスのキーチェーンに証明書がインストールされていることを確認します。証明書がインストールされておらず、アプリサインオンポリシーで[Trusted(信頼)]設定が有効な場合、ユーザーはアプリへのアクセスが拒否され、管理者に連絡するように促すセキュリティメッセージにリダイレクトされます(詳細情報への[Learn more(詳細)]リンクを含めるようにメッセージを設定できます。「ステップ1 - Orgのグローバルデバイスの信頼設定を有効にする」を参照してください)。

  • macOSデバイスの信頼設定を無効にする場合は注意が必要:信頼済みのmacOSデバイスを許可するアプリサインオンポリシーも構成している場合は、[Security(セキュリティ)][デバイスの信頼]ページでmacOSのデバイスの信頼設定を無効にしないでください。無効にすると、デバイスの信頼の設定に矛盾が生じた状態になります。Orgのデバイスの信頼を無効にするには、まず、デバイスの信頼の設定を含むアプリのサインオンポリシーをすべて削除し、[Security(セキュリティ)][デバイスの信頼]でmacOSのデバイスの信頼を無効にします。

  • Oktaサポートにデバイスの信頼の無効化を依頼する前に:OktaサポートにOrgのデバイスの信頼機能の無効化を依頼する場合は、事前にアプリサインオンポリシールールでデバイスの信頼の設定を[Any(任意)]に変更してください([Applications(アプリケーション)][app(アプリ)][Sign On(サインオン)])。この変更を行わずに後でOktaサポートにOrgのデバイスの信頼機能の再有効化を依頼した場合、アプリサインオンポリシールールのデバイスの信頼設定がすぐに有効になるという予期しない動作が発生します。
  • クライアントがMTLSハンドシェイクを完了できることを確認する:このデバイスの信頼フローの相互TLS証明書の交換(ハンドシェイク)は、Okta orgのURLとは別のOktaのURLで行われます(以下の例ではワイルドカード文字(*)で示されています)。エンドポイント保護ソフトウェアを導入する場合は、クライアントがOktaとの証明書交換を完了する際に妨げにならないように設定してください。たとえば、許可リストを使用して送信トラフィックを制限している場合、ワイルドカード文字(*)を含めたこれらの正確なURLを許可リストに追加します。

    *.okta.com

    *.okta-emea.com

    *.okta-gov.com

手順

ステップ1. Orgのグローバルデバイスの信頼設定を有効にする

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

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

  5. [Trust is established by(信頼の確立元)]で、[Jamf Pro]を選択します。
  6. Jamf ProのテナントURL(例:API URLではなく、https://example.jamfcloud.com)、資格情報、キーなど、Jamf Pro APIの情報を入力します。

    この情報により、Oktaは証明書の登録時にエンドユーザーのデバイスがJamf Proで管理されていることを確認できます。Jamf Proの場合、デバイスが管理状態にあることをOktaが確認するため、Jamf APIにアクセスするには、少なくともこれらの参照権限が必要です。

    • [Computers(コンピューター):参照
    • [Jamf Pro User Accounts & Groups(Jamf Proユーザーアカウントとグループ)]:参照
    • [Users(ユーザー)]:参照
  7. Oktaでは、APIアクセス用に、OrganizationがJamf Pro管理インターフェイスにアクセスするために使用するユーザーとは別のユーザーを作成することを強く推奨します。

  8. [Test API credentials(API資格情報をテスト)]をクリックします。MDMプロバイダーのAPIと接続できた場合、接続が完了したことを知らせるメッセージが表示されます。
  9. [Next(次へ)]をクリックします。
  10. [Configure MDM Provider(MDMプロバイダーの設定)]画面で、[Download(ダウンロード)]をクリックし、Pythonスクリプトを入手します。このスクリプトは、「ステップ2. Okta デバイス登録タスクを変更する」で修正します。
  11. 提供された秘密鍵の値とOrg URLをクリップボードにコピーするには、フィールドに隣接するコピーアイコンをクリックします。
  12. 表示されている秘密鍵の値Org URLを書き留めておきます。これはその後Oktaには表示されません。また、後で構成を編集する場合、[Reset macOS Secret Key(macOSの秘密鍵をリセット)]ボタンを使用して新しい秘密鍵を生成するときは、この手順をもう一度実行する必要があります。

  13. [Done(完了)] をクリックします。
  14. ダウンロードしたOkta デバイス登録タスクをステップ2の説明に従って修正します。

    Oktaデバイス登録タスクの最新版は、Okta Admin Consoleの[Settings(設定)][Downloads(ダウンロード)]ページで入手できます。

ステップ2. Okta デバイス登録タスクを変更する

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

*.okta.com

*.okta-emea.com

*.okta-gov.com

  1. 管理者のコンピューターで、[Downloads(ダウンロード)]フォルダに移動し、Oktaからダウンロードしたスクリプトを開きます。
  2. ステップ1. Orgのグローバルのデバイスの信頼の設定を有効化する」で作成したSecret Key Value(秘密鍵の値)Org URLを貼り付けて、スクリプトを修正します。
  3. キーとURLを入力する際、単一引用符( ' )はそのままにして、次の例のように、括弧とプレースホルダーのテキストを実際のSecret Key Value(秘密鍵の値)Org URLに置き換えてください。

    変更されていないスクリプトの例

    変更されたスクリプトの例。単一引用符はそのままで、括弧は削除します。

  4. 任意。デフォルトのアプリの許可リストを変更します。
  5. Okta デバイス登録タスクは、エンドユーザーがアクセスしようとするときにキーチェーンパスワードの入力を求められないように、いくつかの人気アプリをデフォルトで許可します。デフォルトの許可リストを変更するには、「アプリの許可リストを変更する」を参照してください。

  6. スクリプトを保存します。
  7. ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」に進みます。

ステップ3. Python 3とデバイスの信頼の依存関係をインストールする

  1. Python 3がすでにインストールされている場合は、ステップ2に進みます。

    Python 3はさまざまな方法でインストールできます。このステップでは、macOSのXcodeコマンドラインツールを使用したインストール手順に従います。Oktaでは、お好みの方法を使用することを推奨しています。

    任意。macOSマシンで以下のスクリプトを実行し、macOS環境をPython 3にアップデートしてください。

    コピー
    #!/bin/sh
    echo "Checking for the existence of the Apple Command Line Developer Tools"
    /usr/bin/xcode-select -r
    xcodepath='which xcode-select'
    echo "xcode path is $xcodepath"
    $xcodepath -r &> /dev/null
    $xcodepath -p &> /dev/null
    if [[ $? -ne 0 ]]; then
    echo "Apple Command Line Developer Tools not found."
    touch /tmp/.com.apple.dt.CommandLineTools.installondemand.in-progress;
    installationPKG=$(/usr/sbin/softwareupdate --list | /usr/bin/grep -B 1 -E 'Command Line Tools' | /usr/bin/tail -2 | /usr/bin/awk -F'*' '/^ \\/ {print $2}' | /usr/bin/sed -e 's/^ *Label: //' -e 's/^ *//' | /usr/bin/tr -d '\n')
    echo "Installing ${installationPKG}"
    /usr/sbin/softwareupdate --install "${installationPKG}" --verbose
    else
    echo "Apple Command Line Developer Tools are already installed."/usr/bin/xcode-select -s /Library/Developer/CommandLineTools
    fi
    exit
  2. デバイスの信頼の依存関係をインストールします。アップデートされたmacOS デバイス登録タスクでは、デバイス上の"python3"と"pip3"エイリアスが正しいPython 3インストールを指定するようにする必要があります。

    以下のスクリプトを実行し、必要なデバイスの信頼の依存関係をインストールします。

  3. デバイスの信頼の依存関係をインストールします。アップデートされたmacOS デバイス登録タスクでは、デバイス上の"python3"と"pip3"エイリアスが正しいPython 3インストールを指定するようにする必要があります。

    以下のスクリプトを実行し、必要なデバイスの信頼の依存関係をインストールします。

    コピー
    #!/bin/sh
    echo "Running pip3 install --upgrade pip"
    sudo pip3 install --upgrade pip
    echo "Running pip3 install pyobjc-framework-SystemConfiguration"
    sudo pip3 install pyobjc-framework-SystemConfiguration
    exit

ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する

Okta デバイス登録タスクは、このデバイスの信頼ソリューションのターゲットとなるmacOSデバイスにJamf Proから配布されるスクリプトです。デバイスにデプロイすると、Okta デバイス登録タスクは次のように動作します。

  • Oktaに登録して、デバイスの信頼証明書を取得します。Oktaは、Jamf Proを調べて、デバイスが管理されていることを確認します。

  • デバイスのChromeおよびSafariブラウザーとテスト済みのネイティブアプリについて、安全なアプリ・アクセスの際に証明書を自動的に提示するように構成します。

  • 1日1回、ユーザーがコンピューターにログインするたびに実行される軽量なタスクをスケジュール設定します。デバイスの信頼証明書の有効期限を確認し、有効期限の30日前に更新を試みるタスクです。証明書の有効期限は1年間です。

  • 更新時に、Oktaは新しい証明書を発行する前にデバイスが管理されているかを確認するなど、登録時と同様のチェックを行います。
  • スクリプトが一度デバイス上で実行されると、Jamf Proはデバイスから自動的にスクリプトを削除します。
  • デバイスにインストールされている登録タスクのバージョンを確認するには、以下のクエリを使用します:python3 ~/Library/Okta/okta_device_trust.py version

Organizationにとって有意義なワークフローを作成します。スクリプトが少なくとも1回は正常に実行され、Okta証明書が登録されることを確認します。

  1. Jamf Proで歯車アイコンをクリックし、[All Settings(すべての設定)]に移動します。
  2. [Computer Management(コンピューター管理)][Scripts(スクリプト)]に移動します。
  3. 新しいスクリプトを作成し、「ステップ1. Orgのグローバルのデバイスの信頼の設定を有効化する」でOktaからダウンロードして「ステップ2. Okta デバイス登録タスクを変更する」で変更したOktaデバイス登録タスクを貼り付けます。
  4. [Save(保存)]をクリックします。
  5. 1つまたは複数のターゲット コンピューターおよび/またはターゲットユーザーにスクリプトをデプロイするポリシーを作成します。
    1. [Computers(コンピューター)][Policies(ポリシー)]に移動します。
    2. [+ New(+新規作成)]をクリックします。
    3. 左ペインの[General(一般)]をクリックします。
    4. [Display Name(表示名)]フィールドにポリシーの名前を入力します。
    5. ポリシーを開始するトリガーイベントを次のように選択します。
      • [Enrollment Complete(登録完了)]:デバイスが登録プロセスを完了した直後にスクリプトが実行されます。
      • [Recurring Check-in(定期的なチェックイン)]:Jamf Proで設定された定期的なチェックインの頻度に従ってスクリプトが実行されます。
    6. [Execution Frequency(実行頻度)][Once per computer per user(コンピューター1台につき1ユーザー)]に設定します。

      注:Jamf Proでスクリプトのデプロイをトリガーするために実装できるアプローチは他にもあります(たとえば、証明書がデバイス上にあるかどうかを検証し、証明書がない場合はデプロイが可能な拡張属性など)。

    7. [Save(保存)]をクリックします。
    8. 左ペインの[Scripts(スクリプト)]をクリックし、[Configure(設定)]をクリックします。
    9. ステップ3でこのポリシー用に作成したスクリプトを見つけ、[Add(追加)]をクリックします。
    10. [Scope(スコープ)]をクリックします。
    11. [Target Computers(ターゲットコンピューター)]および/または[Target Users(ターゲットユーザー)]で、ポリシーの適用先となるコンピューターとユーザーを指定します。
    12. [Save(保存)]をクリックします。
  6. 推奨。デバイスの信頼でセキュリティ保護されているmacOSデバイスから他のAppleデバイスにiCloudでOktaキーチェーンが転送されないようにするには、Jamf Proで[Allo iCloud Keychain syncing(iCloudキーチェーン同期を許可)]を無効にする設定プロファイルを作成する必要があります。

  7. Jamf Proのログを確認し、Okta デバイス登録タスクが正常に実行されたことを確認します。
    1. [Policies(ポリシー)]に移動して、自分のポリシーをクリックします。
    2. 画面下部の[Logs(ログ)]をクリックします。
  8. 「ステップ5. Oktaでアプリサインオンポリシールールを構成する」に進みます。

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

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

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

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

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

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

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

手順

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

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

許可リストの例

例:Rule 1 – Exchange ActiveSync; All platforms; Any trust; Allow access

  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(他のモバイル)]を選択します。

    デスクトップ

    [Windows]を選択します。

    [macOS]を選択します。

    [Other desktop(他のデスクトップ)]を選択します。

  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など))]
  7. [Any(すべて)]を選択します。

    [Trusted(信頼)]を選択解除します。

    [Not trusted(非信頼)]を選択解除します。

アクション

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

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

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

例:Rule 2 – Web browser or Modern Auth; macOS; Trusted; Allow access

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

条件

  1. [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[ユーザー]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  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(他のモバイル)]を選択解除します。

    デスクトップ

    [Windows]を選択解除します。

    [macOS]を選択します。

    [Other desktop(他のデスクトップ)]を選択解除します。

  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など))]
  7. [Any(すべて)]を選択解除します。

    [Trusted(信頼)] を選択します。

    [Not trusted(非信頼)]を選択解除します。

アクション

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

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

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

例:Rule 3 – Web browser or Modern Auth; All platforms except macOS; Any Trust; Allow access + MFA

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

条件

  1. [ユーザー]で、[Rule 1(ルール1)]で選択したものと同じ[ユーザー]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  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(他のモバイル)]を選択します。

    デスクトップ

    [Windows]を選択します。

    [macOS]を選択します。

    [Other desktop(他のデスクトップ)]を選択します。

  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など))]
  7. [Any(すべて)]を選択します。

    [Trusted(信頼)]を選択解除します。

    [Not trusted(非信頼)]を選択解除します。

アクション

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

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

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

例:Rule 4 – Any client type; All platforms; Any Trust; Deny access

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

条件

  1. [ユーザー]で、[Rule 1(ルール1)]で選択したものと同じ[ユーザー]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
  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(他のモバイル)]を選択します。

    デスクトップ

    [Windows]を選択します。

    [macOS]を選択します。

    [Other desktop(他のデスクトップ)]を選択します。

  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など))]
  7. [Any(すべて)]を選択します。

    [Trusted(信頼)]を選択解除します。

    [Not trusted(非信頼)]を選択解除します。

アクション

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

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

例:Rule 5, Default sign on rule – Any client, All platforms; Any Trust; Allow access

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

デバイスの信頼証明書の失効と削除

Okta認証局からエンドユーザーのデバイスの信頼証明書を撤回する必要がある場合があります。コンピューターを紛失・盗難した場合や、エンドユーザーがディアクティベートされた場合などに推奨されます。デバイスの信頼証明書を撤回した後で、エンドユーザーのコンピューターをデバイスの信頼で再度保護するには、新しい証明書を登録する前に、撤回した証明書をコンピューターから削除する必要があります。

  • この手順のステップ1~4では、Okta認証局からエンドユーザーに発行されたすべてのデバイスの信頼証明書が失効になります。証明書の失効は、macOSコンピューターから既存の証明書を削除するものではありません。証明書を取り消した後にmacOSコンピューターをデバイスの信頼で再び保護するには、まず既存のデバイスの信頼証明書をコンピューターから削除してから、ステップ5に従い新しい証明書を使用してコンピューターを再登録する必要があります。デバイス登録タスクでは、コンピューターに別の証明書が存在する場合(失効したかどうかにかかわらず)、新しい証明書は登録されません。
  • エンドユーザーがディアクティベートされると、Okta認証局からのデバイスの信頼証明書も自動的に失効します(ただし、コンピューターから証明書が削除されるわけではありません)。証明書をコンピューターから削除する場合は、手順5のいずれかの方法で削除してください。
  1. Admin Consoleで、[Directory(ディレクトリ)][PEOPLE(ユーザー)]に進みます。

  2. デバイスの信頼証明書を失効させるエンドユーザーをクリックします。

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

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

  5. 何らかの理由でデバイスの信頼証明書を削除する場合は(コンピューターをデバイスの信頼で再び保護する前など)、まず既存のデバイスの信頼証明書をコンピューターから削除します。Jamf Proでは、コマンドラインを使用するか、アンインストール・スクリプトを作成することができます。どちらのアンインストール方法でも、macOSデバイスからデバイスの信頼に関連するすべてのアーチファクトが削除されます。
  6. ステップ2:Okta デバイス登録タスクを変更する」でダウンロードして変更したスクリプトを再利用する場合は、使用する前にOrgのトークンを削除してください。また、アンインストール操作にはトークンは必要ありません。

    • コマンドラインを使用して削除:ターゲットコンピューターでターミナルを開き、python <fileName>.py uninstallコマンドを発行します。ここで<fileName>はOkta デバイス登録タスクの名前です。たとえば、Okta Registration Taskの名前がMacOktaDeviceRegistrationTaskSetup.1.0.2.pyの場合、以下のコマンドを発行します。

      python MacOktaDeviceRegistrationTaskSetup.1.0.2.py uninstall

    • アンインストールスクリプトで削除:uninstallパラメーターを渡すように構成したアンインストール・スクリプトをJamf Proで作成します。詳細については、Jamf Proのドキュメントの「Adding a Script to Jamf Pro」の手順を参照してください。

証明書登録のログを表示する

Jamf Proでログを表示する

デプロイ中、Okta デバイス登録タスクは、3つのログレベル(INFO、WARN、ERROR)でJamfにログを公開します。Jamfの管理者はデプロイに関する問題を診断する手段として、ポリシー単位またはコンピューター単位でデプロイ・ログを確認することができます。より詳細なログを生成するには、Jamf Proの[Parameter Value(パラメーター値)]として[verbose(詳細)]オプションを使用します。

また、エンドユーザーは、自分のコンピューターでスクリプトを実行中にコンソール・アプリを開くことで、ローカルのmacOSコンピューターでログ・メッセージを表示することができます。

macOSコンピューターでログを表示する

証明書の登録中にOkta関連のログ・メッセージを監視・モニタリングすることができます。その方法は、デバイスで動作しているオペレーティングシステムによって異なります。

バージョン10.11.6(OS X El Capitan)を実行している場合:

  1. [Utilities(ユーティリティ)][Console(コンソール)]を開きます。
  2. [All Messages(すべてのメッセージ)]をクリックします。
  3. [Search(検索)]フィールドにOktaと入力し、Enterキーを押すと、Okta関連のメッセージがすべてフィルタリングされます。

以下のオペレーティングシステムのいずれかを実行している場合:

  • macOS 10.12.6 (Sierra)
  • macOS 10.13.4 (High Sierra)
  1. [Utilities(ユーティリティ)][Console(コンソール)]を開きます。
  2. 左ペインの[Devices(デバイス)]の下で、自分のデバイスをクリックします。
  3. [Search(検索)]フィールドにOktaと入力し、Enterキーを押すと、Okta関連のメッセージがすべてフィルタリングされます。

サポートされているすべてのオペレーティングシステムの過去ログを表示するには、次のようにします。

  1. [Utilities(ユーティリティ)][Console(コンソール)]を開きます。
  2. 左ペインの/var/log > aslに移動します。
  3. 検索したい日付を選択します。
  4. [Search(検索)]フィールドにOktaと入力し、Enterキーを押すと、Okta関連のメッセージがすべてフィルタリングされます。

デバイス上で実行されたシステム呼び出しを確認するには、以下のコマンドを実行した後、デバイス登録タスクを実行します。

log stream --predicate 'eventMessage contains "okta"'

デフォルトのアプリの許可リストを変更する

Okta デバイス登録タスクは、エンドユーザーがアクセスしようとするときにキーチェーンパスワードの入力を求められないように、いくつかの人気アプリをデフォルトで許可します。この手順で説明するように、デフォルトの許可リストをカスタマイズすることができます。

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

  • 優先する許可リストのコピーを取っておいてください。変更した許可リストは、ターゲットのmacOSコンピューターに新しいOkta デバイス登録タスクをプッシュするたびに上書きされるため、作成し直す必要があります。
  • Oktaが定義した元の許可リストにアプリを追加する場合、変更した許可リストをすべてのユーザーに展開する前に、サブセットのユーザーでテストすることを検討してください。
  • 他の許可されたアプリのTeamIdentifierとは異なり、SafariのTeamIdentifierは単純にapple:となります(コロンに注目)。teamid:のプレフィックスはありません。
  • SAML/WS-Fedに対応したアプリで、Webビューによる認証をサポートしているものであれば、許可することができます。認証を行うWebビューは、デバイス上のOktaキーチェーンにアクセス可能でなければなりません。現在、Oktaが提供するオリジナルの許可リストには、以下のアプリが含まれています。
    • Box
    • Chrome
    • Safari
    • Microsoft Office
    • Skype for Business
    • Googleドライブ
    • Slack
  1. 許可するアプリのTeamIdentifierを見つけます。
    1. 許可したいアプリがあるmacOSデバイスで、コマンドラインを開き、[Applications(アプリケーション)]フォルダ内のアプリをリストアップします。
    2. ls /Applications

    3. アプリのTeamIdentifier「codesign -dv --verbose=4 /Applications/exampleapp.app」を見つけます。
    4. exampleappは調査対象のアプリとなります。

    5. 出力されたTeamIdentifierの値を特定し、メモしておいてください。
    6. たとえば、RingCentralのチームのTeamIdentifierを見つける方法は以下のとおりです。

      codesign -dv --verbose=4/App /Applications/RingCentral\ Meetings.app

  2. Okta デバイス登録タスクの許可リストを修正します。
  3. 修正前の例

    許可リストには、Oktaが定義したオリジナルの許可リストが含まれます。

    修正後の例

    RingCentralを追加した許可リスト:

  4. 変更を保存します。
  5. 必要に応じて、Okta デバイス登録タスクをプッシュします。「ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」を参照してください。

優先する許可リストのコピーを取っておいてください。変更した許可リストは、ターゲットのmacOSコンピューターに新しいOkta デバイス登録タスクをプッシュするたびに上書きされるため、作成し直す必要があります。

トラブルシューティング

Oktaデバイス登録タスクは、Oktaから入手したPythonスクリプトであり、これを修正してJamf Proにアップロードし、このデバイスの信頼ソリューションのターゲットとなるmacOSデバイスに配布します。

Okta デバイス登録タスクについて

デバイスにデプロイすると、Okta デバイス登録タスクは次のように動作します。

  • Oktaに登録して、デバイスの信頼証明書を取得します。Oktaは、Jamf Proを調べて、デバイスが管理されていることを確認します。

  • デバイスのChromeおよびSafariブラウザーとテスト済みのネイティブアプリについて、安全なアプリ・アクセスの際に証明書を自動的に提示するように構成します。

  • 1日1回、ユーザーがコンピューターにログインするたびに実行される軽量なタスクをスケジュール設定します。デバイスの信頼証明書の有効期限を確認し、有効期限の30日前に更新を試みるタスクです。証明書の有効期限は1年間です。

  • 更新時に、Oktaは新しい証明書を発行する前にデバイスが管理されているかを確認するなど、登録時と同様のチェックを行います。
  • スクリプトが一度デバイス上で実行されると、Jamf Proはデバイスから自動的にスクリプトを削除します。
  • デバイスにインストールされている登録タスクのバージョンを確認するには、以下のクエリを使用します:python3 ~/Library/Okta/okta_device_trust.py version

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

次の2つが最も遭遇しやすい問題です。

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

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

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

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

有効化

以下を確認します:

  • このデバイス信頼機能が、OrgのOktaのバージョン(SKU)に含まれている。
  • [Security(セキュリティ)][Device Trust(デバイスの信頼)]Enable macOS Device Trust(macOSのデバイスの信頼を有効にする)]グローバルなデバイスの信頼設定を有効にしている。

Registration Task

  • パートCで説明したように、Jamf ProがターゲットとなるmacOSデバイスにデバイス登録タスクを配布するよう正しく設定されていることを確認します。

  • 以下のクエリを使用して、デバイス上で実行されているRegistration Taskのバージョンを確認することができます。

    python ~/Library/Okta/okta_device_trust.py version

  • Python 3スクリプトをデプロイする前に、アプリのTeamIDを追加したことを確認してください。

  • アプリのTeamIDがスクリプトから欠落している場合、お使いの環境で以前にデバイスの信頼と連携していたサードパーティ・アプリからサインオンしようとすると、アクセス・プロンプトが表示されます。

    アクセス・プロンプトの例

    Python 3スクリプトにアプリのTeamIDを追加し、ポリシーを再デプロイします。この画像は、許可リストに登録するアプリを指定するにあたってクリプトを編集するセクションを示しています。

    Python 3スクリプトのセクション

Python 3の依存関係パッケージ

Python 3の依存関係パッケージは正しくインストールされていますか?

「Module NotFoundError: No module named 'Systemconfiguration'」などのモジュールが見つからないエラーが発生した場合は、[link to 'install Device Trust dependencies']の依存関係が正しく設定されていることを確認してください。

コンピューターでJamfから以下のスクリプトを実行します。

コピー
#!/bin/sh
echo "Python location"
python3 -c "import sys; print(sys.executable)"
echo "Python version"
python3 --version
echo "Python3 Dependency version"
echo "********************"
python3 -m pip show pyobjc-framework-SystemConfiguration
echo "********************"

証明書

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

このデバイスの信頼ソリューションの対象となるデバイスのキーチェーンに証明書がインストールされていることを確認します。証明書がインストールされておらず、アプリサインオンポリシーで[Trusted(信頼)]設定が有効な場合、ユーザーはアプリへのアクセスが拒否され、管理者に連絡するように促すセキュリティメッセージにリダイレクトされます(詳細情報への[Learn more(詳細)]リンクを含めるようにメッセージを設定できます。「ステップ1 - Orgのグローバルデバイスの信頼設定を有効にする」を参照してください)。

ターミナルからインストールを確認するには、以下のようにします。

キーチェーン情報を表示する

security show-keychain-info okta.keychain

証明書を表示する

security find-certificate -a -c 'Okta MTLS' -Z -p okta.keychain

パスワードを表示する

security find-generic-password -l device_trust -w

ターゲットとなるデバイスのGUIでインストールを確認する場合は、以下のようにします。

  1. macOSデバイスで、「キーチェーンアクセス」を検索します。
  2. ダブルクリックすると、キーチェーンアクセスアプリが起動します。
  3. Oktaキーチェーンが存在し、Okta MTLS認証が含まれていることを確認します。
  4. Oktaキーチェーン、証明書、または秘密鍵がない場合、登録タスクは正常に完了しませんでした。Jamf Proでログを表示します。

  5. [login(ログイン)]キーチェーンに、device_trustパスワードとID環境設定が表示されることを確認します。
  6. device_trustパスワードが存在しない場合、デバイスの信頼をセキュリティ保護したアプリはOktaキーチェーンにアクセスすることができません。これを解決するには、証明書をアンインストールします。「デバイスの信頼証明書の取り消しと削除」を参照してください。デバイスを再登録します。「ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」を参照してください。

証明書の最大登録数

デバイスの信頼で保護されたmacOSデバイスから、信頼が保護されたアプリケーションにユーザーが初めてアクセスしたときに証明書は特定のユーザーにバインドされます。未使用の証明書はバインドが解除されます。Oktaでは、登録手続きを行うたびに、1つずつ、アンバウンド証明書を最大5件までデバイスに対して発行することができます。セキュリティ対策として、Oktaでは特定のデバイスに対してアンバウンド証明書を6件以上発行しないようにしています。アンバウンド証明書の上限に達しないようにするには、登録によってさらに証明書を取得しようとする前に、ユーザーがデバイスに既存するアンバウンド証明書を使用していることを確認する必要があります。登録の上限に達すると、Syslogに登録エラーが表示され、JAMFログに「Maximum enrollment limit of 5 certificates for a device is reached(デバイスの証明書が登録上限の5件に達しました)」というエラー​メッセージが表示されます。

相互のTLS証明書交換のブロックによる認証失敗の防止

このデバイスの信頼フローの相互TLS証明書の交換(ハンドシェイク)は、Okta orgのURLとは別のOktaのURLで行われます(以下の例ではワイルドカード文字(*)で示されています)。エンドポイント保護ソフトウェアをOrgで実装している場合は、このデバイスの信頼フローで行われる相互のTLS証明書交換(ハンドシェイク)をブロックしない方法で設定してください。たとえば、許可リストを使用して送信トラフィックを制限している場合、ワイルドカード文字(*)を含めたこれらの正確なURLを許可リストに追加します。

*.okta.com

*.okta-emea.com

*.okta-gov.com

サインオンポリシー

次のようなサインオンポリシーが設定されていることを確認します。

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

システムログ

デバイスの信頼イベントの検証

システムログを確認し、以下のデバイスの信頼システムログイベントを検証します。

認証

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

登録

  • DisplayMessage:デバイスの信頼証明書の登録
  • EventType: user.credential.enroll

発行

  • DisplayMessage:デバイスの信頼証明書の発行
  • EventType: pki.cert.issue

撤回

  • DisplayMessage:デバイスの信頼証明書の撤回
  • EventType: pki.cert.revoke

更新

  • DisplayMessage:デバイスの信頼証明書の更新
  • EventType: pki.cert.renew

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

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

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

  1. Admin Console[Reports(レポート)][System Log(システムログ)]に移動します。
  2. 関心のあるデバイスの信頼イベント(日付)を検索し、[Event(イベント)][AuthenticationContext][System(システム)][DebugContext][DebugData]に移動します。

Jamf Proの設定の確認

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

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

Okta管理者アプリで次を確認します。

macOSデバイスのエンドユーザーが[Directory(ディレクトリ)][People(ユーザー)]に存在し、アクティベートされていることを確認します。

macOSデバイスで次を確認します。

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

  1. Chromeのアドレスバーに「chrome://policy」と入力し、Enterキーを押します。
  2. [Show value(値を表示)]をクリックし、AutoSelectCertificateForUrlsというポリシーに次の値のいずれかが表示されていることを確認します。

    {"pattern":"https://[cell]-devicetrust.okta.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority”}}}

    {"pattern":"https://[cell]-devicetrust.okta-emea.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority”}}}

  3. [cell]は、Okta Admin Consoleのフッターに表示されておりOkta orgが存在するセルです。

キーチェーンでネイティブアプリが許可されていることを確認する

次のコマンドを実行して、許可されたアプリが証明書にアクセスできることを確認します。「デフォルトのアプリの許可リストを変更する」を参照してください。

security dump-keychain -a okta.keychain

改善策の検証

ブラウザーやシッククライアントから、デバイスの信頼でセキュリティ保護されたアプリにアクセスしてみてください。アプリにアクセスしようとしてエラーが表示された場合は、ブラウザー(ChromeまたはSafari)を終了して閉じ、ブラウザーを再起動してから、再度アプリにアクセスしてみてください。

既知の問題

  • O365ネイティブアプリへのアクセス時にセキュリティ要件ページが表示されない:管理されていないmacOSデバイスを持つエンドユーザーが、このデバイスの信頼ソリューションによって保護されたOffice O365ネイティブアプリにアクセスしようとすると、[Security requirements(セキュリティ要件)]ページが表示されません。(この問題はOfficeのネイティブアプリでのみ発生し、ChromeやSafariなどのデスクトップブラウザーからO365アプリにアクセスしようとする場合には発生しません)。

  • Googleのバックアップと同期アプリへのアクセスに問題がある:バックアップと同期アプリ(Googleドライブの一部)にサインインすると、認証フローがアプリに進まず、Googleアカウントのページで停止します。Googleはこの問題を認識しています。サインインを完了するには、ページ下部の[Sign in with your browser instead(代わりにブラウザーでログイン)]リンクをクリックします。