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

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

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

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

前提条件

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

  • サポートされる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)、または12.xx(Monterey)をお使いの場合は、Python 3をベースとした登録バージョン1.3.3以降をお使いください。
    • macOS 10.14.xx(Mojave)をお持ちで、現在登録スクリプト1.2.1以前をお使いの方は、そのまま使い続けるか、Python 3を使う前にCatalina、Big Sur、またはMontereyにアップグレードしてください。

開始する前に

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

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

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

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

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

    *.okta.com

    *.okta-emea.com

    *.okta-gov.com

手順

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

  1. Okta Admin Consoleで、[Security(セキュリティ)]>[Device Trust]に移動します。
  2. macOS Device Trustセクションで、[Edit(編集)]をクリックします。
  3. 起動したウィザードで、[Enable macOS Device Trust(macOS Device Trustを有効にする)]を選択します。
  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アクセス用に、組織がJamf Pro管理インターフェイスにアクセスするために使用するユーザーとは別のユーザーを作成することを強く推奨します。

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

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

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

ステップ2. Okta Device Registration Taskを変更する

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

*.okta.com

*.okta-emea.com

*.okta-gov.com

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

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

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

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

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

ステップ3. Python 3とDevice Trustの依存関係をインストールする

  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. Device Trustの依存関係をインストールします。アップデートされたmacOS Device Registration Taskでは、デバイス上の"python3"と"pip3"エイリアスが正しいPython 3インストールを指定するようにする必要があります。

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

  3. 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

ステップ4. 変更したOkta Device Registration TaskをJamf Proに追加してmacOSデバイスに配布する

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

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

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

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

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

    python3 ~/Library/Okta/okta_device_trust.py version

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

  1. Jamf Proで歯車アイコンをクリックし、[All Settings(すべての設定)]に移動します。
  2. [Computer Management(コンピューター管理)]>[Scripts(スクリプト)]に移動します。
  3. 新しいスクリプトを作成して「ステップ1. 組織のグローバルのデバイスの信頼の設定を有効化する」でOktaからダウンロードし、「ステップ2. Okta Device Registration Taskを変更する」で変更したOkta Device Registration Taskに貼り付けます。
  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. 推奨。Device Trustでセキュリティ保護されているmacOSデバイスから他のAppleデバイスにiCloudでOktaキーチェーンが転送されないようにするには、Jamf Proで[Allo iCloud Keychain syncing(iCloudキーチェーン同期を許可)]を無効にする設定プロファイルを作成する必要があります。

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

ステップ5: 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(ユーザーのクライアントが次のいずれかに該当する場合)]セクションは表示されません。

許可リストの例

例: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)]で選択したものと同じ[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(他のモバイル)]を選択解除します。

    デスクトップ

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

    デスクトップ

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

    デスクトップ

    [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により実質的に無効化されているため、デフォルト・ルールに到達することはありません。

Device Trust証明書の失効と削除

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

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

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

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

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

  5. 何らかの理由でDevice Trust証明書を削除する場合は(コンピューターをDevice Trustで再び保護する前など)、まず既存のDevice Trust証明書をコンピューターから削除します。Jamf Proでは、コマンド・ラインを使用するか、アンインストール・スクリプトを作成することができます。どちらのアンインストール方法でも、macOSデバイスからDevice Trustに関連するすべてのアーチファクトが削除されます。
  6. ステップ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の[Parameter Value(パラメーター値)]として[verbose(詳細)]オプションを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 優先する許可リストのコピーを取っておいてください。変更した許可リストは、ターゲットのmacOSコンピューターに新しいOkta Device Registration Taskをプッシュするたびに上書きされるため、作成し直す必要があります。
  • 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 Device Registration Taskの許可リストを修正します。
  3. 修正前の例

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

    修正後の例

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

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

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

トラブルシューティング

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

Okta Device Registration Taskについて

デバイスにデプロイすると、Okta Device Registration Taskは次のように動作します。

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

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

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

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

    python3 ~/Library/Okta/okta_device_trust.py version

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

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

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

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

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

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

有効化

以下を確認します:

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

Registration Task

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

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

    python ~/Library/Okta/okta_device_trust.py version

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

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

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

    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 "********************"

証明書

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

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

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

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

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

証明書の最大登録数

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

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

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

*.okta.com

*.okta-emea.com

*.okta-gov.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が適用されていることを確認するのに役立ちます。この確認は、大きなユーザーグループに機能を展開する前に有用となりえます。

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

  1. 管理コンソールで、[Reports(レポート)]>[System Log(システムログ)]に移動します。
  2. 関心のあるDevice Trustイベント(日付)を検索し、

    [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管理者コンソールのフッターに表示されておりOkta orgが存在するセルです。

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

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

security dump-keychain -a okta.keychain

改善策の検証

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

既知の問題

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

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