Jamf Proの管理対象macOSデバイスへのOkta Device Trustの適用

注

注

Okta Device Registration Task v1.3.1は、Python 3をサポートするためにリリースされたものです。Python 2.xのスクリプトが必要な場合は、Device Registration Task v1.2.1を参照してください。
この変更による展開への影響については、「 前提条件 」および「 ステップ3：Python 3とDevice Trustの依存関係をインストールする 」を参照してください。

Jamf Proの管理対象macOSデバイスに対するOkta Device Trustでは、管理対象外のmacOSデバイスが企業のSAMLおよびWS-Fedクラウド・アプリにアクセスするのを防ぐことができます。Okta Device Trustにより、既知の保護されたデバイスしかOkta管理対象アプリケーションにアクセスできなくなります。


  • このソリューションは以下で動作します。
    • OktaでサポートされるバージョンのmacOSを実行しているAppleコンピューター。
    • Jamf Pro MDMソリューション
    • Oktaへのフェデレーション認証フローを実行する際に管理対象コンピューターのOktaキーチェーンにアクセスできる以下のブラウザーとネイティブ・アプリ：
      • ブラウザー：ChromeおよびSafariブラウザー
      • モダン認証対応ネイティブ・アプリ：
        • Box
        • Googleドライブ
        • Microsoft Office
        • Skype for Business
        • Slack
    • Okta Device Registration Taskは、さまざまなタスク（登録など）を実行するPythonスクリプトです。このスクリプトの適切なバージョンを使用するために、OSに応じて次のいずれかに従ってください。
      • macOS 10.15.xx（Catalina）または11.xx（Big Sur）の場合は、Python 3ベースのバージョン1.3.1以降の登録スクリプトを使用してください。
      • macOS 10.14.xx（Mojave）で1.2.1以前の登録スクリプトを現在使用している場合は、そのまま使用するか、Python 3を使用する前にCatalinaまたはBig Surにアップグレードしてください。

      • 詳細については、「 ステップ3：Python 3とDevice Trustの依存関係をインストールする 」を参照してください。


  • Microsoft Officeアプリの保護にはモダン認証が必要：このDevice TrustソリューションでMicrosoft Officeアプリを保護するには、モダン認証のサポートを有効にする必要があります。詳細については、Microsoftのこちらの記事を参照してください。レガシー・プロトコルを使用するOffice 365クライアントの保護については、「Office 365クライアント・アクセス・ポリシー」を参照してください。

  • Microsoft Officeシック・クライアントの一部のバージョンではDevice Trustがサポートされない：このDevice Trustソリューションは、Microsoft Officeシック・クライアント・バージョン16.13.1および16.15で動作することがテストされています。ただし、Microsoft Officeシック・クライアント・バージョン16.14（ビルド180610）では動作しません。

  • iCloudによる他のAppleデバイスへのOktaキーチェーンの転送を防止：iCloudによってDevice Trustで保護されたmacOSデバイスから他のAppleデバイスにOktaキーチェーンが転送されないように、[iCloudキーチェーンの同期を許可]を無効にする構成プロファイルをJamf Proで作成することを強く推奨します（注：同期を無効にするとすべてのキーチェーンの転送がブロックされることに注意してください）。「変更したOkta Device Registration TaskをJamf Proに追加してmacOSデバイスに配布する」を参照してください。

  • Webビューはデバイス・キーチェーンへのアクセス権が必要：管理対象macOSコンピューター用のDevice Trustは、Webビューによる認証をサポートするSAML/WS-Fed対応アプリで動作します。認証が実行されるWebビューは、Oktaキーチェーンにアクセスできる必要があります。認証フローで証明書を使用する際にエンド・ユーザーに同意を求めないように、Oktaでは次のアプリを許可しています。 「デフォルトの許可リストの変更」を参照してください。

    • Box
    • Chrome
    • Safari
    • Microsoft Office
    • Skype for Business
    • Googleドライブ
    • Slack
  • デバイスごとのバインドされていない証明書の制限： 証明書は、ユーザーがDevice Trustで保護されたmacOSデバイスからDevice Trustで保護されたアプリケーションに初めてアクセスしたときに、そのユーザーにバインドされます。証明書は使用するまではバインドされません。Oktaでは、登録手順を実行するたびに1つずつ、バインドされていない証明書を最大5つまでデバイスに発行できます。セキュリティー上の理由から、Oktaでは、バインドされていない証明書を各デバイスに5つまでしか発行しません。バインドされていない証明書の制限に達しないようにするには、登録を通じて追加の証明書の取得を試みる前に、ユーザーがデバイス上のバインドされていない証明書をすでに使用していることを確認してください。登録の上限に達すると、Syslogに登録エラーが表示され、JAMFログに「デバイスの証明書が登録上限の5件に達しました」というエラー・メッセージが表示されます。
  • 組織ごとの登録の制限：macOSデバイスは、それぞれ単一のOkta組織のDevice Trust構成でのみ保護できます。言い換えると、macOSデバイスを複数のOkta組織のDevice Trust構成で同時に保護することはできません。これは、デバイスに発行されたクライアント証明書が特定の組織のCAによって署名されているためです。この制限はOktaのプレビュー組織と本番組織に適用されます。
  • 共有端末のシナリオはサポート対象外：このDevice Trustソリューションは、Oktaの複数のエンド・ユーザーが同じmacOSワークステーションから同じアカウントにログインする共有端末のシナリオをサポートしていません。
  • Oktaが読み取り専用モードの場合、デバイストラストの登録はサポートされません：Okta組織が存在するセルが存在する場合、デバイスをデバイストラストに登録することはできません。 読み取り専用モード.
  • エンド・ユーザーの環境でブラウザーのキャッシュの消去が必要な場合がある：一部のブラウザー（Chromeなど）では、Device Trust証明書がキャッシュされます。それらのブラウザーでは、証明書が自動的に更新された後（1年に1回）、新しい証明書ではなく期限切れの証明書をOktaに提示し続ける場合があります。この場合、エンド・ユーザーにセキュリティー要件のメッセージが表示され、Device Trustで保護されたアプリへのアクセスが拒否されます。Oktaでは、ブラウザー・ウィンドウを閉じるだけでなく、いったんブラウザーを終了してから再起動することでブラウザーのキャッシュを消去するように該当するエンド・ユーザーに勧めることを推奨します。

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

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

  • アプリでモダン認証のサポートが必要：このDevice TrustソリューションでMicrosoft Officeアプリを保護するには、モダン認証のサポートを有効にする必要があります。詳細については、Microsoftの記事「How modern authentication works for Office 2013 and Office 2016 client apps」を参照してください。「Office 365クライアント・アクセス・ポリシー」も参照してください。

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

  • macOS Device Trustの設定を無効にする場合の注意事項：信頼されたmacOSデバイスを許可するアプリ・サインオン・ポリシーも構成している場合は、[セキュリティー] > [Device Trust]ページでmacOS Device Trustの設定を無効にしないでください。無効にした場合、Device Trustの構成が一貫性のない状態になります。組織のDevice Trustを無効にするには、まずDevice Trustの設定を含むアプリ・サインオン・ポリシーを削除してから、[セキュリティー] > [Device Trust]でmacOS Device Trustを無効にします。

  • OktaサポートにDevice Trustの無効化を依頼する前に：Oktaサポートに組織のDevice Trust機能の無効化を依頼する場合は、その前にアプリのサインオン・ポリシー・ルールでDevice Trustの設定を[任意]に変更してください（[アプリケーション] > アプリ > [サインオン]）。この変更を行わず、後でOktaサポートに組織のDevice Trust機能の再有効化を依頼した場合、アプリのサインオン・ポリシー・ルールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。
  • クライアントがMTLSハンドシェイクを完了できることを確認：このDevice Trustフローにおける相互TLS証明書交換（ハンドシェイク）は、Okta組織のURLとは別のOktaのURLで行われます（次の例ではワイルドカード文字（*）で示されています）。エンドポイント保護ソフトウェアを実装している場合、Oktaとの証明書の交換をブロックしないように構成してください。たとえば、組織で送信トラフィックの制限に許可リストを使用している場合、次のURLをワイルドカード文字（*）も含めて正確に許可リストに追加してください。

    *.okta.com

    *.okta-emea.com



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

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

  5. [信頼の確立元]で、[Jamf Pro]を選択します。
  6. Jamf ProのテナントのURL（例：https://example.jamfcloud.com、APIのURLではない）、認証情報、キーなど、Jamf ProのAPIに関する情報を入力します。

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

    • コンピューター：読み取り
    • Jamf Proユーザー・アカウント & グループ ：読み取り
    • ユーザー：読み取り

    7. 重要な注意事項

    重要

    Oktaでは、Jamf Proの管理インターフェイスへのアクセスに組織で使用するユーザーとは別に、APIアクセス用に別個のユーザーを作成することを強くお勧めします。

  7. [API認証情報をテスト]をクリックします。 MDMプロバイダーのAPIとの接続が確立されると、成功メッセージが表示されます。
  8. [次へ]をクリックします。
  9. [MDMプロバイダーを構成]画面で、[ダウンロード]をクリックしてPythonスクリプトを入手します。 このスクリプトを「ステップ2：Okta Device Registration Taskを変更する」で変更します。
  10. [秘密鍵の値]と[企業/組織のURL]に表示された値をクリップボードにコピーするには、フィールドの横にあるコピー・アイコンをクリックします。

    11. 重要な注意事項

    重要

    [秘密鍵の値]と[企業/組織のURL]の値がOktaに表示されるのは今回だけなので、メモしておいてください。また、後で構成を編集する場合、[macOSの 秘密鍵をリセット]ボタンを使用して新しい秘密鍵を生成するときは、この手順をもう一度実行する必要があります。

  11. [完了]をクリックします。
  12. ステップ2の説明に従って、ダウンロードしたOkta Device Registration Taskを変更します。

    Okta Device Registration Taskの最新バージョンは、Okta管理コンソールの[設定] > [ダウンロード]ページから入手できます。




重要な注意事項

重要

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

*.okta.com

*.okta-emea.com


  1. 管理者のコンピューターで、ダウンロード・フォルダーに移動し、Oktaからダウンロードしたスクリプトを開きます。
  2. 「ステップ1：組織のグローバルなDevice Trust設定を有効にする」で生成した[秘密鍵の値]と[企業/組織のURL]の値を貼り付けてスクリプトを変更します。

    3. キーとURLを入力する際は、以下の例に示すように、単一引用符（'）は残し、括弧とプレースホルダー・テキストを[秘密鍵の値]と[企業/組織のURL]の実際の値に置き換えます。


    たとえば、変更前のスクリプトは次のとおりです。

    変更後のスクリプトは次のようになります。単一引用符は残しますが、括弧は残しません。

  3. 任意：デフォルトのアプリ許可リストを変更します。

    4. Okta Device Registration Taskでは、エンド・ユーザーがアクセスする際にキーチェーンのパスワードの入力を求められないように、よく利用される一部のアプリをデフォルトで許可しています。デフォルトの許可リストを変更する場合は、「アプリの許可リストの変更」を参照してください。

  4. スクリプトを保存します。
  5. 「ステップ4：変更したOkta Device Registration TaskをJamf Proに追加してmacOSデバイスに配布する」に進みます。

Python 3がすでにインストールされている場合は、手順2に進みます。

  1. Python 3をインストールする方法は複数あります。ここでは、macOSのXcodeコマンド・ライン・ツールを使用したインストール手順を示します。各自でやりやすい方法を使用してください。

    任意：macOSマシンで次のスクリプトを実行して、macOS環境をPython 3に更新します。

    #!/bin/sh

    echo "Checking for the existence of the Apple Command Line Developer Tools"

    /usr/bin/xcode-select -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."

    fi

    exit

  1. Device Trustの依存関係をインストールします。更新されたmacOSのDevice Registration Taskでは、デバイスの「python3」と「pip3」のエイリアスでPython 3の正しいインストールをポイントする必要があります。

    次のスクリプトを実行して、必要なDevice Trustの依存関係をインストールします。

    #!/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


Okta Device Registration Taskは、このDevice Trustソリューションの対象となるmacOSデバイスにJamf Proを通じて配布されるスクリプトです。デバイスに展開されると、Okta Device Registration Taskは以下を実行します。

  • Oktaに登録してDevice Trust証明書を取得します。OktaはJamf Proを使用してデバイスが管理されていることを確認します。

  • ChromeおよびSafariブラウザを構成し、 テスト済みのネイティブアプリ 安全なアプリアクセス中に証明書を自動的に提示するためにデバイス上で。

  • 1日1回、ユーザーがコンピューターにログインするたびに実行される簡単なタスクをスケジュールします。このタスクでDeviceTrust証明書の有効期限が切れていないかどうかを確認し、期限切れの30日前に証明書の更新を試みます。証明書の有効期限は1年間です。

  • 更新時は、登録時と同様のチェックがOktaで実行されます。たとえば、新しい証明書を発行する前にデバイスが管理されているかどうかが確認されます。
  • スクリプトは、デバイスで1回実行されると、Jamf Proによってデバイスから自動的に削除されます。
  • 以下のクエリを使用して、デバイスにインストールされているレジストレーションタスクのバージョンを確認することができます。

    python3 ~/Library/Okta/okta_device_trust.py version

それぞれの組織に応じた適切なワークフローを作成してください。Okta証明書を登録するスクリプトが少なくとも1回は正常に実行されることを確認してください。

  1. Jamf Proで、歯車アイコンをクリックして[すべての設定]に移動します。
  2. [コンピューターの管理] > [スクリプト]に移動します。
  3. 新しいスクリプトを作成し、「ステップ1：組織のグローバルなDevice Trust設定を有効にする」でOktaからダウンロードして「ステップ2：Okta Device Registration Taskを変更する」で変更したOkta Device Registration Taskを貼り付けます。
  4. [保存]をクリックします。
  5. 1つ以上の対象コンピューター/対象ユーザーにスクリプトを展開するポリシーを作成します。
    1. [コンピューター] > [ポリシー]に移動します。
    2. [+ 新規]をクリックします。
    3. 左側のペインの[一般]をクリックします。
    4. [表示名]フィールドにポリシーの名前を入力します。
    5. ポリシーを開始する以下のトリガー・イベントを選択します。
      • 登録完了時：デバイスが登録プロセスを完了した直後にスクリプトが実行されます。
      • チェックイン時：Jamf Proで構成された間隔でチェックインが実行されたときにスクリプトが実行されます。
    6. [実行頻度]を[ユーザーごとに各コンピューターで1回]に設定します。

      注： スクリプトの展開をトリガーするためにJamf Proで実装できるアプローチはほかにもあります（たとえば、拡張属性を使用すると、デバイスに有効な証明書があるかどうかを検証して証明書がない場合に展開できます）。

    7. [保存]をクリックします。
    8. 左側のペインの[スクリプト]をクリックし、[構成]をクリックします。
    9. 手順3でこのポリシー用に作成したスクリプトを探し、[追加]をクリックします。
    10. [スコープ]をクリックします。
    11. [対象コンピューター]/[対象ユーザー]で、ポリシーを適用するコンピューターおよびユーザーを指定します。
    12. [保存]をクリックします。
  6. 推奨：iCloudによってDevice Trustで保護されたmacOSデバイスから他のAppleデバイスにOktaキーチェーンが転送されないように、[iCloudキーチェーンの同期を許可]を無効にする構成プロファイルをJamf Proで作成することをお勧めします。

  7. Jamf Proのログを確認して、Okta Device Registration Taskが正常に実行されたことを確認します。
    1. [ポリシー]に移動し、ポリシーをクリックします。
    2. 画面下部の[ログ]をクリックします。
  8. 「ステップ5：Oktaでアプリのサインオン・ポリシー・ルールを構成する」に進みます。

挙動とアプリのサインオン・ポリシー

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

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

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

手順

  1. 管理コンソールで、[アプリケーション] > に移動します。[アプリケーション]、Device Trustで保護するSAMLまたはWS対応アプリをクリックします。
  2. [サインオン]タブをクリックし、[サインオン・ポリシー]まで下にスクロールして、[ルールを追加]をクリックします。
  3. 次の例をガイドとして使用して、1つ以上のルールを構成します。

情報

注

この例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。その他のアプリの場合、セクション[ユーザーのクライアントが次のいずれかに該当する場合]が存在しないことに注意してください。

許可リストの例

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

条件

  1. [ユーザー]の下で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。選択する[ユーザー]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  2. [場所]の下で、ルールを適用するユーザーのロケーションを指定します。選択する[場所]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  3. クライアント設定を構成します。

    4. タイプ：

    ¨ [Webブラウザーまたはモダン認証クライアント]：選択します。

    þ [Exchange ActiveSyncクライアント]：選択しません。

    モバイル：

    þ [iOS]：選択します。

    þ [Android]：選択します。

    þ [その他のモバイル]：選択します。

    デスクトップ：

    þ [Windows]：選択します。

    þ [macOS]：選択します。

    þ [その他のデスクトップ]：選択します。

  4. [Device Trust]を構成します。

    5. [Device Trust]セクションの[信頼できる]および[信頼できない]オプションは、[クライアント]セクションで以下のすべてのオプションが選択されていない場合のみ選択できます。

    • Exchange ActiveSyncまたはレガシー認証クライアント
    • その他のモバイル（BlackBerryなど）
    • その他のデスクトップ（Linuxなど）

    þ [任意]：選択します。

    ¨ [信頼済み]：選択しません。

    ¨ [信頼できない]：選択しません。

アクション

  1. [アクセス]を構成します。

    2. [許可]を選択します。

    ¨ [要素を求める]：選択しません。

  2. [保存]をクリックします。
  3. ルール2を作成します。

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

条件

  1. [ユーザー]の下で、ルール1で選択したものと同じ[ユーザー]オプションを選択します。この例のすべてのルールで[ユーザー]オプションは同じにする必要があります。
  2. [場所]の下で、ルール1で選択したものと同じ[場所]オプションを選択します。この例のすべてのルールで[場所]オプションは同じにする必要があります。
  3. クライアント設定を構成します。

    4. タイプ：

    þ [Webブラウザーまたはモダン認証クライアント]：選択します。

    ¨ [Exchange ActiveSyncクライアント]：選択しません。

    モバイル：

    ¨ [iOS]：選択しません。

    ¨ [Android]：選択しません。

    ¨ [その他のモバイル]：選択しません。

    デスクトップ：

    ¨ [Windows]：選択しません。

    þ [macOS]：選択します。

    ¨ [その他のデスクトップ]：選択しません。

  4. [Device Trust]を構成します。

    5. [Device Trust]セクションの[信頼できる]および[信頼できない]オプションは、[クライアント]セクションで以下のすべてのオプションが選択されていない場合のみ選択できます。

    • Exchange ActiveSyncまたはレガシー認証クライアント
    • その他のモバイル（BlackBerryなど）
    • その他のデスクトップ（Linuxなど）

    ¨ [任意]：選択しません。

    þ [信頼済み]：選択します。

    ¨ [信頼できない]：選択しません。

アクション

  1. [アクセス]を構成します。

    2. [許可]を選択します。

    ¨ [要素を求める]：選択しません。

  2. [保存]をクリックします。
  3. ルール3を作成します。

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

条件

  1. [ユーザー]の下で、ルール1で選択したものと同じ[ユーザー]オプションを選択します。選択する[ユーザー]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  2. [場所]の下で、ルール1で選択したものと同じ[場所]オプションを選択します。選択する[場所]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  3. クライアント設定を構成します。

    4. タイプ：

    þ [Webブラウザーまたはモダン認証クライアント]：選択します。

    ¨ [Exchange ActiveSyncクライアント]：選択しません。

    モバイル：

    ¨ [iOS]：選択しません。

    þ [Android]：選択します。

    þ [その他のモバイル]：選択します。

    デスクトップ：

    þ [Windows]：選択します。

    þ [macOS]：選択します。

    þ [その他のデスクトップ]：選択します。

  4. [Device Trust]を構成します。

    5. [Device Trust]セクションの[信頼できる]および[信頼できない]オプションは、[クライアント]セクションで以下のすべてのオプションが選択されていない場合のみ選択できます。

    • Exchange ActiveSyncまたはレガシー認証クライアント
    • その他のモバイル（BlackBerryなど）
    • その他のデスクトップ（Linuxなど）

    þ [任意]：選択します。

    ¨ [信頼済み]：選択しません。

    ¨ [信頼できない]：選択しません。

アクション

  1. [アクセス]を構成します。

    2. [許可]を選択します。

    þ [要素を求める]：選択します。

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

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

条件

  1. [ユーザー]の下で、ルール1で選択したものと同じ[ユーザー]オプションを選択します。選択する[ユーザー]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  2. [場所]の下で、ルール1で選択したものと同じ[場所]オプションを選択します。選択する[場所]オプションは、この例で作成するすべてのルールで同じにする必要があります。
  3. クライアント設定を構成します。

    4. タイプ：

    þ [Webブラウザーまたはモダン認証クライアント]：選択します。

    þ [Exchange ActiveSyncクライアント]：選択します。

    モバイル：

    þ [iOS]：選択します。

    þ [Android]：選択します。

    þ [その他のモバイル]：選択します。

    デスクトップ：

    þ [Windows]：選択します。

    þ [macOS]：選択します。

    þ [その他のデスクトップ]：選択します。

  4. [Device Trust]を構成します。

    5. [Device Trust]セクションの[信頼できる]および[信頼できない]オプションは、[クライアント]セクションで以下のすべてのオプションが選択されていない場合のみ選択できます。

    • Exchange ActiveSyncまたはレガシー認証クライアント
    • その他のモバイル（BlackBerryなど）
    • その他のデスクトップ（Linuxなど）

    þ [任意]：選択します。

    ¨ [信頼済み]：選択しません。

    ¨ [信頼できない]：選択しません。

アクション

  1. [アクセス]を構成します。

    2. [拒否]を選択します。

  2. [保存]をクリックします。

デフォルトのサインオン・ルールはすでに作成されており、編集できません。この例では、デフォルトのルールはルール4によって事実上無効になっているため、到達することはありません。


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

  • この手順の1～4では、エンド・ユーザーに対してOkta認証局から発行されたすべてのDevice Trust証明書を取り消します。証明書を取り消しても、既存の証明書がmacOSコンピューターから削除されることはありません。証明書を取り消した後にmacOSコンピューターをDevice Trustで再び保護するには、まず既存のDevice Trust証明書をコンピューターから削除してから、手順5に従って新しい証明書でコンピューターを再登録する必要があります。コンピューターに別の証明書が存在する場合（取り消されているかどうかにかかわらず）、Device Registration Taskで新しい証明書は登録されません。
  • エンド・ユーザーが非アクティブ化されると、そのユーザーのDevice Trust証明書もOkta認証局から自動的に取り消されます（ただし、コンピューターからは削除されません）。コンピューターから証明書を削除するには、手順5のいずれかの削除方法を使用します。

  1. 管理コンソールで、[ディレクトリー] > に移動します 人員

  2. Device Trust証明書を取り消すエンド・ユーザーをクリックします。

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

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

  5. 何らかの理由でDevice Trust証明書を削除する場合は（コンピューターをDevice Trustで再び保護する前など）、まず既存のDevice Trust証明書をコンピューターから削除します。コマンド・ラインを使用するか、Jamf Proでアンインストール・スクリプトを作成できます。どちらのアンインストール方法でも、macOSデバイスからDevice Trust関連のアーチファクトがすべて削除されます。

    6. Note

    注

    「ステップ2：Okta Device Registration Taskを変更する」でダウンロードして変更したスクリプトを再利用する場合は、使用する前に組織のトークンを削除してください。トークンはアンインストール操作には必要ありません。

    • コマンド・ラインで削除 — 対象のコンピューターのターミナルを開き、コマンド python <fileName>.py uninstallを発行します。<fileName>は、Okta Device Registration Taskの名前です。例えば、 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 Device Registration Taskは、展開中に3つのログ・レベル（INFO、WARN、ERROR）でJamfにログを発行します。展開の問題を診断するために、Jamf管理者はポリシーまたは個々のコンピューターごとに展開のログを確認できます。より詳細なログを生成するには、Jamf Proでパラメーター値としてverboseオプションを使用します。

さらに、エンド・ユーザーは、コンピューターでのスクリプトの実行中にコンソール・アプリを開いておくことで、ローカルのmacOSコンピューターでログ・メッセージを確認できます。

macOSコンピューターでのログの確認

証明書の登録中にOkta関連のログ・メッセージを監視できます。この方法は、デバイスで実行されているオペレーティング・システムによって異なります。

バージョン10.11.6（OS X El Capitan）を実行している場合：

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

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

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

過去のログを表示する場合（サポートされているすべてのオペレーティング・システムで共通）：

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

デバイスで実行されたシステム・コールを確認するには、次のコマンドを実行してからDevice Registration Taskを実行します。

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


Okta Device Registration Taskでは、エンド・ユーザーがアクセスしようとしたときにキーチェーンのパスワードの入力を求められないように、よく利用される一部のアプリをデフォルトで許可しています。デフォルトの許可リストは、この手順に従ってカスタマイズできます。

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

  • よく使用する許可リストのコピーを残しておいてください。変更した許可リストは、新しいOkta Device Registration Taskを対象のmacOSコンピューターにプッシュすると上書きされるため、そのたびに再作成する必要があります。
  • Oktaで定義された元の許可リストにアプリを追加する場合は、変更した許可リストをすべてのユーザーに展開する前に、ユーザーのサブセットでテストすることを検討してください。
  • 他の許可されているアプリのTeamIdentifierとは異なり、SafariのTeamIdentifierは単に「apple:」（コロンに注意）で、「teamid:」プレフィックスは付きません。
  • Webビューによる認証をサポートするSAML/WS-Fed対応アプリを許可できます。認証が実行されるWebビューは、Oktaキーチェーンにアクセスできる必要があります。Oktaが提供する元の許可リストには、現在は次のアプリが含まれています。
    • Box
    • Chrome
    • Safari
    • Microsoft Office
    • Skype for Business
    • Googleドライブ
    • Slack

  1. 許可するアプリのTeamIdentifierを探します。
    1. 許可するアプリがあるmacOSデバイスでコマンド・ラインを開き、Applicationsフォルダーのアプリを一覧表示します。

      2. ls /Applications

    2. アプリのTeamIdentifierを探します。

      3. codesign -dv --verbose=4 /Applications/exampleapp.app

      exampleappは調査するアプリです。

    3. 出力でTeamIdentifierの値を見つけてメモします。

      4. たとえば、RingCentralのチームのTeamIdentifierを探す場合は次のようになります。

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

      出力は次のとおりです。


  2. Okta Device Registration Taskで許可リストを変更します。

    3. 変更前の例

    Oktaで定義された元の許可リスト：



    変更後の例

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



  3. 変更を保存します。
  4. 必要に応じて、「ステップ4：変更したOkta Device Registration TaskをJamf Proに追加してmacOSデバイスに配布する」の説明に従ってOkta Device Registration Taskをプッシュします。
ヒント

ヒント

よく使用する許可リストのコピーを残しておいてください。変更した許可リストは、新しいOkta Device Registration Taskを対象のmacOSコンピューターにプッシュすると上書きされるため、そのたびに再作成する必要があります。


Okta Device Registration Taskは、Oktaから取得して変更した後、このDevice Trustソリューションの対象となるmacOSデバイスに配布するためにJamf ProにアップロードするPythonスクリプトです。

Okta Device Registration Taskについて

デバイスに展開されると、Okta Device Registration Taskは以下を実行します。

  • Oktaに登録してDevice Trust証明書を取得します。OktaはJamf Proを使用してデバイスが管理されていることを確認します。

  • ChromeおよびSafariブラウザを構成し、 テスト済みのネイティブアプリ 安全なアプリアクセス中に証明書を自動的に提示するためにデバイス上で。

  • 1日1回、ユーザーがコンピューターにログインするたびに実行される簡単なタスクをスケジュールします。このタスクでDeviceTrust証明書の有効期限が切れていないかどうかを確認し、期限切れの30日前に証明書の更新を試みます。証明書の有効期限は1年間です。

  • 更新時は、登録時と同様のチェックがOktaで実行されます。たとえば、新しい証明書を発行する前にデバイスが管理されているかどうかが確認されます。
  • スクリプトは、デバイスで1回実行されると、Jamf Proによってデバイスから自動的に削除されます。
  • 以下のクエリを使用して、デバイスにインストールされているレジストレーションタスクのバージョンを確認することができます。

    python3 ~/Library/Okta/okta_device_trust.py version

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

発生する可能性が高い2つの問題を以下に示します。

  • 信頼されたデバイスがDevice Trustで保護されたアプリにアクセスできない。
  • 信頼されていないデバイスがDevice Trustで保護されたアプリにアクセスできる。

いずれかの問題が発生した場合、基本トラブルシューティングを実施することで解決を試みてください。問題が解決しない場合、高度なトラブルシューティングを実施します。

基本トラブルシューティングを実施するには、以下のエリアを確認します。

以下を確認します。

  • パートCの説明に従って、Device Registration Taskを対象のmacOSデバイスに配布するようにJamf Proが正しく構成されていることを確認します。

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

    python ~/Library/Okta/okta_device_trust.py version

  • Python 3スクリプトを展開する前に、アプリのTeamIDをスクリプトに追加したことを確認します。

    • アプリのTeamIDがスクリプトに含まれていない場合、以前に環境でDevice Trustと連携していたサード・パーティー製アプリからサインオンしようとしたときにアクセス・プロンプトが表示されます。
    アクセス・プロンプトの例

    アプリのTeamIDをPython 3スクリプトに追加して、ポリシーを再度展開します。
    この画像は、ホワイトリストに登録するアプリを指定するために編集するスクリプトのセクションを示しています。
    Python 3スクリプトのセクション

Python 3の依存関係パッケージが正しくインストールされているかどうかを確認します。

モジュールが見つからないというエラー（例：「ModuleNotFoundError: No module named 'Systemconfiguration'」）が発生する場合は、[「Device Trustの依存関係のインストール」へのリンク]の依存関係が正しく設定されていることを確認してください。

コンピューターで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 "********************"

証明書のインストールを確認

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

キーチェーン情報を表示

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


  1. macOSデバイスで「キーチェーン・アクセス」を検索します。
  2. ダブルクリックしてキーチェーン・アクセス・アプリを開きます。
  3. Oktaキーチェーンが存在し、Okta MTLS証明書が含まれていることを確認します。

    4. Oktaキーチェーン、証明書、または秘密鍵が見つからない場合、登録タスクが正常に完了していません。この場合は、Jamf Proでログを確認してください。

  4. ログインのキーチェーンに、device_trustパスワードと識別プリファレンスが表示されていることを確認します。

    5. device_trustパスワードが存在しない場合、Device Trustで保護されたアプリからOktaキーチェーンにアクセスできません。これを解決するには、証明書をアンインストールし（「Device Trust証明書の取り消しと削除」を参照）、デバイスを再登録します（「ステップ4：変更したOkta Device Registration TaskをJamf Proに追加してmacOSデバイスに配布する」を参照）。

証明書の登録の上限

証明書は、ユーザーがDevice Trustで保護されたmacOSデバイスからDevice Trustで保護されたアプリケーションに初めてアクセスしたときに、そのユーザーにバインドされます。証明書は使用するまではバインドされません。Oktaでは、登録手順を実行するたびに1つずつ、バインドされていない証明書を最大5つまでデバイスに発行できます。セキュリティー上の理由から、Oktaでは、バインドされていない証明書を各デバイスに5つまでしか発行しません。バインドされていない証明書の制限に達しないようにするには、登録を通じて追加の証明書の取得を試みる前に、ユーザーがデバイス上のバインドされていない証明書をすでに使用していることを確認してください。登録の上限に達すると、Syslogに登録エラーが表示され、JAMFログに「デバイスの証明書が登録上限の5件に達しました」というエラー・メッセージが表示されます。

相互TLS証明書交換のブロックが原因で認証に失敗する問題の防止

このDevice Trustフローにおける相互TLS証明書交換（ハンドシェイク）は、Okta組織のURLとは別のOktaのURLで行われます（次の例ではワイルドカード文字（*）で示されています）。組織でエンドポイント保護ソフトウェアを実装している場合、このDevice Trustフロー中に発生する相互TLS証明書交換（ハンドシェイク）をブロックしないように構成してください。たとえば、組織で送信トラフィックの制限に許可リストを使用している場合、次のURLをワイルドカード文字（*）も含めて正確に許可リストに追加してください。

*.okta.com

*.okta-emea.com

以下のサインオン・ポリシーを構成していることを確認します。

  • Device Trustで保護するWS-FedまたはSAMLアプリに適用される
  • 適切なユーザー/グループに適用される
  • 信頼できないデバイスへのアクセスを拒否するアクティブなルールが最低でも含まれる

Device Trustイベントの確認

システム・ログを確認して、以下の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が適用されているかどうかも確認できるため、機能を大規模なユーザーのグループに展開する場合などに役立ちます。

Important Note

重要

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

  1. 管理コンソールで、[レポート] > に移動します システム・ログ。
  2. 目的のDevice Trustイベント（日付）を検索し、次の順に進みます。

    イベント> AuthenticationContext>システム> DebugContext> DebugData

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

Okta管理者用アプリで

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

macOSデバイス

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

  1. Chromeで、アドレス・バーにchrome://policyと入力してEnterを押します。
  2. [値を表示]をクリックして、ポリシー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管理コンソールのフッターに表示される、Okta組織が存在するセルです。

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

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

security dump-keychain -a okta.keychain


修復を検証

ブラウザーまたはシック・クライアントからDevice Trustで保護されたアプリにアクセスしてみます。アプリにアクセスする際にエラーが表示された場合は、[終了]や[閉じる]でブラウザー（ChromeまたはSafari）を終了してから再度起動し、アプリへのアクセスをもう一度試します。


  • O365ネイティブ・アプリにアクセスするときにセキュリティー要件のページが表示されない：このDevice Trustソリューションで保護されているOffice O365ネイティブ・アプリに管理対象外のmacOSデバイスを使用しているエンド・ユーザーがアクセスしようとしたときに、セキュリティー要件のページが表示されません（この問題はOfficeネイティブ・アプリでのみ発生します。ChromeやSafariなどのデスクトップのブラウザーからO365アプリにアクセスしようとしたときは発生しません）。

  • Google「バックアップと同期」アプリへのアクセスに関する問題：「バックアップと同期」アプリ（Googleドライブの一部）にサインインする際、認証フローがGoogleアカウントのページで停止してアプリに進みません。これはGoogleの既知の問題です。サインインを完了するには、ページの下部にある[代わりにブラウザでログイン]リンクをクリックします。

Oktaから

Device Trust

macOS向けDevice TrustのRegistration Taskのバージョン履歴

Office 365クライアント・アクセス・ポリシー

Microsoft Exchange ActiveSync（EAS）を構成する


外部リソース

Microsoft

How modern authentication works for Office 2013 and Office 2016 client apps

Office 365: Enable Modern Authentication

Updated Office 365 modern authentication

Office 2013 and Office 365 ProPlus modern authentication and client access filtering policies


Jamf Pro

Computer Extension Attributes

Introduction to Extension Attributes（ビデオ）

Managing Scripts

QuickStart Guide for Managing Computers 10.4.0

QuickStart Guide for Managing Mobile Devices 10.4.0

Jamf Pro Installation and Configuration Guide for Mac 10.4.0

Jamf Pro Administrator's Guide 10.4.0