Jamf ProマネージドのmacOSデバイスにOkta Device Trustを強制適用する
Okta デバイス登録タスク v1.3.1は、Python 3に対応するためにリリースされました。Python 2.xのスクリプトが必要な場合は、デバイス登録タスク v1.2.1を参照してください。
Jamf ProマネージドmacOSデバイス用Okta Device Trustを使用すると、管理外のmacOSデバイスから企業のSAMLやWS-Fedクラウドアプリにアクセスできないようにすることが可能です。Okta Device Trustは、既知の安全なデバイスのみが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にアップグレードしてください。
はじめに
-
安全なアプリケーションへのアクセスに使用されていないデバイスでは、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 デバイス登録タスクを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件に達しました)」というエラーメッセージが表示されます。
- Orgごとの登録制限:所定のmacOSデバイスは、1つのOkta orgのDevice Trust設定によってのみセキュリティ保護することができます。別の言い方をすれば、macOSデバイスを、複数のOkta orgのDevice Trust設定によって同時に保護することはできません。これは、デバイスに対して発行されるクライアント証明書が、特定のOrgのCAによって署名されているためです。この制限は、Oktaプレビューと本番環境のOrgに適用されます。
- 端末共有のシナリオはサポートされていない:このDevice Trustソリューションは、複数のOktaエンドユーザーが同じmacOSワークステーションから同じアカウントにログインする共有端末のシナリオをサポートしていません。
- Oktaが読み取り専用モードのときはDevice Trust登録はサポートされない:Okta orgが属するセルが読み取り専用モード
- エンドユーザーは、ブラウザーのキャッシュをクリアする必要があるかもしれない:一部のブラウザー(例:Chrome)では、Device Trust証明書がキャッシュされます。証明書が自動的に更新された後(1年に1回)、これらのブラウザーは新しい証明書ではなく、期限切れの証明書をOktaに提示し続ける場合があります。その場合、エンドユーザーにはセキュリティ要件のメッセージが表示され、Device Trustで保護されたアプリへのアクセスは拒否されます。Oktaでは、影響を受けるエンドユーザーに対して、ブラウザーを終了して再起動することにより、ブラウザーのキャッシュをクリアするようアドバイスすることを推奨しています (ブラウザーのウィンドウを閉じるだけでは不十分です)。
-
Device Trustによって保護されたアプリは、Okta End-User Dashboard(Oktaエンドユーザーダッシュボード)にロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。
- エンドユーザーがデスクトップまたはモバイルのブラウザー(Okta Mobile以外)でダッシュボードにアクセスした。
- Orgで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 - OrgのグローバルDevice Trust設定を有効にする」を参照してください)。
-
macOSDevice Trust設定を無効にする場合は注意が必要:信頼済みのmacOSデバイスを許可するアプリサインオンポリシーも構成している場合は、[Security(セキュリティ)][Device Trust]ページでmacOSのDevice Trust設定を無効にしないでください。無効にすると、Device Trustの設定に矛盾が生じた状態になります。OrgのDevice Trustを無効にするには、まず、Device Trustの設定を含むアプリのサインオンポリシーをすべて削除し、 でmacOSのDevice Trustを無効にします。
- OktaサポートにDevice Trustの無効化を依頼する前に:OktaサポートにOrgのDevice Trust機能の無効化を依頼する場合は、事前にアプリサインオンポリシールールでDevice Trustの設定を[Any(任意)]に変更してください( )。この変更を行わずに後でOktaサポートにOrgのDevice Trust機能の再有効化を依頼した場合、アプリサインオンポリシールールのDevice Trust設定がすぐに有効になるという予期しない動作が発生します。
- クライアントがMTLSハンドシェイクを完了できることを確認する:このDevice Trustフローの相互TLS証明書の交換(ハンドシェイク)は、Okta orgのURLとは別のOktaのURLで行われます(以下の例ではワイルドカード文字(*)で示されています)。エンドポイント保護ソフトウェアを導入する場合は、クライアントがOktaとの証明書交換を完了する際に妨げにならないように設定してください。たとえば、許可リストを使用して送信トラフィックを制限している場合、ワイルドカード文字(*)を含めたこれらの正確なURLを許可リストに追加します。
*.okta.com
*.okta-emea.com
*.okta-gov.com
手順
ステップ1. OrgのグローバルDevice Trust設定を有効にする
- Admin Consoleで、 に移動します。
- macOS Device Trustセクションで、[Edit(編集)]をクリックします。
- 起動したウィザードで、[Enable macOS Device Trust(macOS Device Trustを有効にする)]を選択します。
- 任意。[Learn more(詳細)]フィールドには、非信頼デバイスを使用するエンドユーザーが詳細情報を参照できる、外部からアクセス可能なリダイレクトURLを入力できます。これらのエンドユーザーに表示されるセキュリティメッセージには、指定したURLにリダイレクトされる[Learn more(詳細)]リンクが含まれます。
この任意選択フィールドにURLを指定しないオプションを選択した場合、これらのエンドユーザーには同じメッセージが表示されますが、[Learn more(詳細)]リンクは表示されません。
- [Trust is established by(信頼の確立元)]で、[Jamf Pro]を選択します。
- 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(ユーザー)]:参照
- [Test API credentials(API資格情報をテスト)]をクリックします。MDMプロバイダーのAPIと接続できた場合、接続が完了したことを知らせるメッセージが表示されます。
- [Next(次へ)]をクリックします。
- [Configure MDM Provider(MDMプロバイダーの設定)]画面で、[Download(ダウンロード)]をクリックし、Pythonスクリプトを入手します。このスクリプトは、「ステップ2. Okta デバイス登録タスクを変更する」で修正します。
- 提供された[Secret Key Value(秘密鍵の値)]と[Org URL]をクリップボードにコピーするには、フィールドに隣接するコピーアイコンをクリックします。
- [Done(完了)] をクリックします。
- ダウンロードしたOkta デバイス登録タスクをステップ2の説明に従って修正します。
Oktaデバイス登録タスクの最新版は、Okta Admin Consoleの ページで入手できます。
Oktaでは、APIアクセス用に、OrganizationがJamf Pro管理インターフェイスにアクセスするために使用するユーザーとは別のユーザーを作成することを強く推奨します。
表示されている[Secret Key Value(秘密鍵の値)]と[Org URL]を書き留めておきます。これはその後Oktaには表示されません。また、後で構成を編集する場合、[Reset macOS Secret Key(macOSの秘密鍵をリセット)]ボタンを使用して新しい秘密鍵を生成するときは、この手順をもう一度実行する必要があります。
ステップ2. Okta デバイス登録タスクを変更する
このDevice Trustフローの相互TLS証明書の交換(ハンドシェイク)は、Okta orgのURLとは別のOktaのURLで行われます(以下の例ではワイルドカード文字(*)で示されています)。エンドポイント保護ソフトウェアを導入する場合は、クライアントがOktaとの証明書交換を完了する際に妨げにならないように設定してください。たとえば、許可リストを使用して送信トラフィックを制限している場合、ワイルドカード文字(*)を含めたこれらの正確なURLを許可リストに追加します。
*.okta.com
*.okta-emea.com
*.okta-gov.com
- 管理者のコンピューターで、[Downloads(ダウンロード)]フォルダに移動し、Oktaからダウンロードしたスクリプトを開きます。
- 「ステップ1. OrgのグローバルのDevice Trustの設定を有効化する」で作成したSecret Key Value(秘密鍵の値)とOrg URLを貼り付けて、スクリプトを修正します。
- 任意。デフォルトのアプリの許可リストを変更します。
- スクリプトを保存します。
- 「ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」に進みます。
キーとURLを入力する際、単一引用符( ' )はそのままにして、次の例のように、括弧とプレースホルダーのテキストを実際のSecret Key Value(秘密鍵の値)とOrg URLに置き換えてください。
変更されていないスクリプトの例
変更されたスクリプトの例。単一引用符はそのままで、括弧は削除します。
Okta デバイス登録タスクは、エンドユーザーがアクセスしようとするときにキーチェーンパスワードの入力を求められないように、いくつかの人気アプリをデフォルトで許可します。デフォルトの許可リストを変更するには、「アプリの許可リストを変更する」を参照してください。
ステップ3. Python 3とDevice Trustの依存関係をインストールする
-
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 -
Device Trustの依存関係をインストールします。アップデートされたmacOS デバイス登録タスクでは、デバイス上の"python3"と"pip3"エイリアスが正しいPython 3インストールを指定するようにする必要があります。
以下のスクリプトを実行し、必要なDevice Trustの依存関係をインストールします。
-
Device Trustの依存関係をインストールします。アップデートされたmacOS デバイス登録タスクでは、デバイス上の"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 デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する
Okta デバイス登録タスクは、このDevice TrustソリューションのターゲットとなるmacOSデバイスにJamf Proから配布されるスクリプトです。デバイスにデプロイすると、Okta デバイス登録タスクは次のように動作します。
-
Oktaに登録して、Device Trust証明書を取得します。Oktaは、Jamf Proを調べて、デバイスが管理されていることを確認します。
-
デバイスのChromeおよびSafariブラウザーとテスト済みのネイティブアプリについて、安全なアプリ・アクセスの際に証明書を自動的に提示するように構成します。
-
1日1回、ユーザーがコンピューターにログインするたびに実行される軽量なタスクをスケジュール設定します。Device Trust証明書の有効期限を確認し、有効期限の30日前に更新を試みるタスクです。証明書の有効期限は1年間です。
- 更新時に、Oktaは新しい証明書を発行する前にデバイスが管理されているかを確認するなど、登録時と同様のチェックを行います。
- スクリプトが一度デバイス上で実行されると、Jamf Proはデバイスから自動的にスクリプトを削除します。
- デバイスにインストールされている登録タスクのバージョンを確認するには、以下のクエリを使用します:python3 ~/Library/Okta/okta_device_trust.py version
Organizationにとって有意義なワークフローを作成します。スクリプトが少なくとも1回は正常に実行され、Okta証明書が登録されることを確認します。
- Jamf Proで歯車アイコンをクリックし、[All Settings(すべての設定)]に移動します。
- に移動します。
- 新しいスクリプトを作成し、「ステップ1. OrgのグローバルのDevice Trustの設定を有効化する」でOktaからダウンロードして「ステップ2. Okta デバイス登録タスクを変更する」で変更したOktaデバイス登録タスクを貼り付けます。
- [Save(保存)]をクリックします。
- 1つまたは複数のターゲット コンピューターおよび/またはターゲットユーザーにスクリプトをデプロイするポリシーを作成します。
- に移動します。
- [+ New(+新規作成)]をクリックします。
- 左ペインの[General(一般)]をクリックします。
- [Display Name(表示名)]フィールドにポリシーの名前を入力します。
- ポリシーを開始するトリガーイベントを次のように選択します。
- [Enrollment Complete(登録完了)]:デバイスが登録プロセスを完了した直後にスクリプトが実行されます。
- [Recurring Check-in(定期的なチェックイン)]:Jamf Proで設定された定期的なチェックインの頻度に従ってスクリプトが実行されます。
- [Execution Frequency(実行頻度)]を[Once per computer per user(コンピューター1台につき1ユーザー)]に設定します。
注:Jamf Proでスクリプトのデプロイをトリガーするために実装できるアプローチは他にもあります(たとえば、証明書がデバイス上にあるかどうかを検証し、証明書がない場合はデプロイが可能な拡張属性など)。
- [Save(保存)]をクリックします。
- 左ペインの[Scripts(スクリプト)]をクリックし、[Configure(設定)]をクリックします。
- ステップ3でこのポリシー用に作成したスクリプトを見つけ、[Add(追加)]をクリックします。
- [Scope(スコープ)]をクリックします。
- [Target Computers(ターゲットコンピューター)]および/または[Target Users(ターゲットユーザー)]で、ポリシーの適用先となるコンピューターとユーザーを指定します。
- [Save(保存)]をクリックします。
- 推奨。Device Trustでセキュリティ保護されているmacOSデバイスから他のAppleデバイスにiCloudでOktaキーチェーンが転送されないようにするには、Jamf Proで[Allo iCloud Keychain syncing(iCloudキーチェーン同期を許可)]を無効にする設定プロファイルを作成する必要があります。
- Jamf Proのログを確認し、Okta デバイス登録タスクが正常に実行されたことを確認します。
- [Policies(ポリシー)]に移動して、自分のポリシーをクリックします。
- 画面下部の[Logs(ログ)]をクリックします。
- 「ステップ5. Oktaでアプリサインオンポリシールールを構成する」に進みます。
ステップ5: Oktaでアプリサインオンポリシールールを構成する
アプリサインオンポリシールールについて
[App Sign On Rule(アプリサインオンルール)]ダイアログボックス内のすべてのクライアントオプションはデフォルトで事前選択されています。アプリへのアクセスを詳細設定するには、以下を反映させるルールを作成します。
- 対象となるユーザー、または対象者が属するグループ
- 対象者がネットワークに接続しているか、接続していないか、定義されたネットワークゾーンに属しているか
- 対象者のデバイスで実行されているクライアントのタイプ(Office 365アプリのみ)
- 対象者のモバイルまたはデスクトップデバイスのプラットフォーム
- 対象者のデバイスが信頼されているかどうか
サインオンポリシールールへの許可リストによるアプローチ
- アプリへのアクセスを許可するシナリオをサポートする1つまたは複数の許可ルールを作成し、これらのルールに最高優先度を割り当てます。
- ステップ1で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストのアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。
アプリサインオンポリシールールの作成に関する重要なセキュリティ情報については、「アプリのサインオンポリシー」を参照してください。
手順
- Admin Consoleで、 に移動します。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(ユーザーのクライアントが次のいずれかに該当する場合)]セクションは表示されません。
許可リストの例
例:Rule 1 – Exchange ActiveSync; All platforms; Any trust; Allow access
- ルールにわかりやすい名前を付けて入力します。
[Conditions(条件)]
- [PEOPLE(ユーザー)]で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Device Trust]で以下を構成します。
-
[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など))]
[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(他のデスクトップ)]を選択します。
[Any(すべて)]を選択します。
[Trusted(信頼)]を選択解除します。
[Not trusted(非信頼)]を選択解除します。
[ACTIONS(アクション)]
- [Access(アクセス)]を構成します。
- [Save(保存)]をクリックします。
- [Rule 2(ルール2)]を作成します。
[Allowed(許可)]を選択します。
[Prompt for factor(要素をプロンプト)]を選択解除します。
例:Rule 2 – Web browser or Modern Auth; macOS; Trusted; Allow access
- ルールにわかりやすい名前を付けて入力します。
条件
- [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Device Trust(Device Trust)]で以下を構成します。
-
[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など))]
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択解除します。
モバイル
[iOS]を選択解除します。
[Android]を選択解除します。
[Other mobile(他のモバイル)]を選択解除します。
デスクトップ
[Windows]を選択解除します。
[macOS]を選択します。
[Other desktop(他のデスクトップ)]を選択解除します。
[Any(すべて)]を選択解除します。
[Trusted(信頼)] を選択します。
[Not trusted(非信頼)]を選択解除します。
アクション
- [Access(アクセス)]を構成します。
- [Save(保存)]をクリックします。
- [Rule 3(ルール3)]を作成します。
[Allowed(許可)]を選択します。
[Prompt for factor(要素をプロンプト)]を選択解除します。
例:Rule 3 – Web browser or Modern Auth; All platforms except macOS; Any Trust; Allow access + MFA
- ルールにわかりやすい名前を付けて入力します。
[Conditions(条件)]
- [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Device Trust]で以下を構成します。
-
[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など))]
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択解除します。
モバイル
[iOS]を選択解除します。
[Android]を選択します。
[Other mobile(他のモバイル)]を選択します。
デスクトップ
[Windows]を選択します。
[macOS]を選択します。
[Other desktop(他のデスクトップ)]を選択します。
[Any(すべて)]を選択します。
[Trusted(信頼)]を選択解除します。
[Not trusted(非信頼)]を選択解除します。
アクション
- [Access(アクセス)]を構成します。
- [Save(保存)]をクリックします。
- [Rule 4(ルール4)]を作成します。
[Allowed(許可)]を選択します。
[Prompt for factor(要素をプロンプト)]を選択します。
例:Rule 4 – Any client type; All platforms; Any Trust; Deny access
- ルールにわかりやすい名前を付けて入力します。
条件
- [PEOPLE(ユーザー)]で、[Rule 1(ルール1)]で選択したものと同じ[People(ユーザー)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [LOCATION(ロケーション)]で、[Rule 1(ルール1)]で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じでなければなりません。
- [CLIENT(クライアント)]で、次の設定を構成します。
- [Device Trust]で以下を構成します。
-
[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など))]
[Web browser(Webブラウザー)]を選択します。
[Modern Auth client(Modern Authクライアント)]を選択します。
[Exchange ActiveSync client(Exchange ActiveSyncクライアント)]を選択します。
モバイル
[iOS]を選択します。
[Android]を選択します。
[Other mobile(他のモバイル)]を選択します。
デスクトップ
[Windows]を選択します。
[macOS]を選択します。
[Other desktop(他のデスクトップ)]を選択します。
[Any(すべて)]を選択します。
[Trusted(信頼)]を選択解除します。
[Not trusted(非信頼)]を選択解除します。
アクション
- [Access(アクセス)]を構成します。
- [Save(保存)]をクリックします。
[Denied(拒否)]を選択します。
例: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に従い新しい証明書を使用してコンピューターを再登録する必要があります。デバイス登録タスクでは、コンピューターに別の証明書が存在する場合(失効したかどうかにかかわらず)、新しい証明書は登録されません。
- エンドユーザーがディアクティベートされると、Okta認証局からのDevice Trust証明書も自動的に失効します(ただし、コンピューターから証明書が削除されるわけではありません)。証明書をコンピューターから削除する場合は、手順5のいずれかの方法で削除してください。
-
Admin Consoleで、 に進みます。
-
Device Trust証明書を失効させるエンドユーザーをクリックします。
- [More Actions(その他のアクション)]メニューで、[Revoke Trust Certificate(信頼証明書を取り消す)]をクリックします。
-
表示されるメッセージを確認し、[Revoke Trust Certificate(信頼証明書を取り消す)]をクリックします。
- 何らかの理由でDevice Trust証明書を削除する場合は(コンピューターをDevice Trustで再び保護する前など)、まず既存のDevice Trust証明書をコンピューターから削除します。Jamf Proでは、コマンドラインを使用するか、アンインストール・スクリプトを作成することができます。どちらのアンインストール方法でも、macOSデバイスからDevice Trustに関連するすべてのアーチファクトが削除されます。
- コマンドラインを使用して削除:ターゲットコンピューターでターミナルを開き、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」の手順を参照してください。
「ステップ2:Okta デバイス登録タスクを変更する」でダウンロードして変更したスクリプトを再利用する場合は、使用する前にOrgのトークンを削除してください。また、アンインストール操作にはトークンは必要ありません。
証明書登録のログを表示する
Jamf Proでログを表示する
デプロイ中、Okta デバイス登録タスクは、3つのログレベル(INFO、WARN、ERROR)でJamfにログを公開します。Jamfの管理者はデプロイに関する問題を診断する手段として、ポリシー単位またはコンピューター単位でデプロイ・ログを確認することができます。より詳細なログを生成するには、Jamf Proの[Parameter Value(パラメーター値)]として[verbose(詳細)]オプションを使用します。
また、エンドユーザーは、自分のコンピューターでスクリプトを実行中にコンソール・アプリを開くことで、ローカルのmacOSコンピューターでログ・メッセージを表示することができます。
macOSコンピューターでログを表示する
証明書の登録中にOkta関連のログ・メッセージを監視・モニタリングすることができます。その方法は、デバイスで動作しているオペレーティングシステムによって異なります。
バージョン10.11.6(OS X El Capitan)を実行している場合:
- を開きます。
- [All Messages(すべてのメッセージ)]をクリックします。
- [Search(検索)]フィールドにOktaと入力し、Enterキーを押すと、Okta関連のメッセージがすべてフィルタリングされます。
以下のオペレーティングシステムのいずれかを実行している場合:
- macOS 10.12.6 (Sierra)
- macOS 10.13.4 (High Sierra)
- を開きます。
- 左ペインの[Devices(デバイス)]の下で、自分のデバイスをクリックします。
- [Search(検索)]フィールドにOktaと入力し、Enterキーを押すと、Okta関連のメッセージがすべてフィルタリングされます。
サポートされているすべてのオペレーティングシステムの過去ログを表示するには、次のようにします。
- を開きます。
- 左ペインの/var/log > aslに移動します。
- 検索したい日付を選択します。
- [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
- 許可するアプリのTeamIdentifierを見つけます。
- 許可したいアプリがあるmacOSデバイスで、コマンドラインを開き、[Applications(アプリケーション)]フォルダ内のアプリをリストアップします。
- アプリのTeamIdentifier「codesign -dv --verbose=4 /Applications/exampleapp.app」を見つけます。
- 出力されたTeamIdentifierの値を特定し、メモしておいてください。
- Okta デバイス登録タスクの許可リストを修正します。
- 変更を保存します。
- 必要に応じて、Okta デバイス登録タスクをプッシュします。「ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」を参照してください。
ls /Applications
exampleappは調査対象のアプリとなります。
たとえば、RingCentralのチームのTeamIdentifierを見つける方法は以下のとおりです。
codesign -dv --verbose=4/App /Applications/RingCentral\ Meetings.app
修正前の例
許可リストには、Oktaが定義したオリジナルの許可リストが含まれます。
修正後の例
RingCentralを追加した許可リスト:
優先する許可リストのコピーを取っておいてください。変更した許可リストは、ターゲットのmacOSコンピューターに新しいOkta デバイス登録タスクをプッシュするたびに上書きされるため、作成し直す必要があります。
トラブルシューティング
Oktaデバイス登録タスクは、Oktaから入手したPythonスクリプトであり、これを修正してJamf Proにアップロードし、このDevice TrustソリューションのターゲットとなるmacOSデバイスに配布します。
Okta デバイス登録タスクについて
デバイスにデプロイすると、Okta デバイス登録タスクは次のように動作します。
-
Oktaに登録して、Device Trust証明書を取得します。Oktaは、Jamf Proを調べて、デバイスが管理されていることを確認します。
-
デバイスのChromeおよびSafariブラウザーとテスト済みのネイティブアプリについて、安全なアプリ・アクセスの際に証明書を自動的に提示するように構成します。
-
1日1回、ユーザーがコンピューターにログインするたびに実行される軽量なタスクをスケジュール設定します。Device Trust証明書の有効期限を確認し、有効期限の30日前に更新を試みるタスクです。証明書の有効期限は1年間です。
- 更新時に、Oktaは新しい証明書を発行する前にデバイスが管理されているかを確認するなど、登録時と同様のチェックを行います。
- スクリプトが一度デバイス上で実行されると、Jamf Proはデバイスから自動的にスクリプトを削除します。
- デバイスにインストールされている登録タスクのバージョンを確認するには、以下のクエリを使用します:python3 ~/Library/Okta/okta_device_trust.py version
基本的なトラブルシューティングと高度なトラブルシューティング
次の2つが最も遭遇しやすい問題です。
- 信頼済みのデバイスが、Device Trustでセキュリティ保護されたアプリにアクセスできない。
- 非信頼デバイスが、Device Trustでセキュリティ保護されたアプリにアクセスできてしまう。
いずれかの問題が発生した場合は、「基本的なトラブルシューティング」を実行して修正を試みてください。問題が解決しない場合は、「高度なトラブルシューティング」を実行してください。
基本的なトラブルシューティング
基本的なトラブルシューティングを行うには、次の領域を確認します。
有効化
以下を確認します:
- このデバイス信頼機能が、OrgのOktaのバージョン(SKU)に含まれている。
- グローバルなDevice Trust設定を有効にしている。 で
Registration Task
-
パートCで説明したように、Jamf ProがターゲットとなるmacOSデバイスにデバイス登録タスクを配布するよう正しく設定されていることを確認します。
Python 3スクリプトをデプロイする前に、アプリのTeamIDを追加したことを確認してください。
以下のクエリを使用して、デバイス上で実行されているRegistration Taskのバージョンを確認することができます。
python ~/Library/Okta/okta_device_trust.py version
アプリのTeamIDがスクリプトから欠落している場合、お使いの環境で以前にDevice Trustと連携していたサードパーティ・アプリからサインオンしようとすると、アクセス・プロンプトが表示されます。
Python 3スクリプトにアプリのTeamIDを追加し、ポリシーを再デプロイします。この画像は、許可リストに登録するアプリを指定するにあたってクリプトを編集するセクションを示しています。
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 - Orgのグローバル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でインストールを確認する場合は、以下のようにします。
- macOSデバイスで、「キーチェーンアクセス」を検索します。
- ダブルクリックすると、キーチェーンアクセスアプリが起動します。
- Oktaキーチェーンが存在し、Okta MTLS認証が含まれていることを確認します。
- [login(ログイン)]キーチェーンに、device_trustパスワードとID環境設定が表示されることを確認します。
Oktaキーチェーン、証明書、または秘密鍵がない場合、登録タスクは正常に完了しませんでした。Jamf Proでログを表示します。
device_trustパスワードが存在しない場合、Device Trustをセキュリティ保護したアプリはOktaキーチェーンにアクセスすることができません。これを解決するには、証明書をアンインストールします。「Device Trust証明書の取り消しと削除」を参照してください。デバイスを再登録します。「ステップ4. 変更したOkta デバイス登録タスクを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で行われます(以下の例ではワイルドカード文字(*)で示されています)。エンドポイント保護ソフトウェアをOrgで実装している場合は、この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オブジェクト」を参照してください。
- Admin Consoleで に移動します。
- 関心のあるDevice Trustイベント(日付)を検索し、 に移動します。
Jamf Proの設定の確認
- Okta Admin Consoleで、Okta デバイス登録タスクに秘密鍵の値とOrg URLが正しく入力されていますか(「ステップ2. Okta デバイス登録タスクを変更する」を参照)?
- Jamf Proに修正・追加したOkta デバイス登録タスクは、最新版ですか?(「バージョン履歴」を参照。)
- Jamf Proポリシーのトリガーイベントには、[Enrollment Complete(登録完了)]と[Recurring Check-in(定期的なチェックイン)]が含まれていますか?(「ステップ4. 変更したOkta デバイス登録タスクをJamf Proに追加してmacOSデバイスに配布する」を参照してください。)
- デプロイメント・ログは確認しましたか?(「証明書登録のログを表示する」を参照。)
- Jamf Proのポリシー・ログには、スクリプトの実行状態が[Completed(完了)]と表示されていますか?
高度なトラブルシューティング
基本的なトラブルシューティングで問題が解決されず、証明書がmacOSデバイスにインストールされていない場合は、以下を確認してください。
Okta管理者アプリで次を確認します。
macOSデバイスのエンドユーザーが
に存在し、アクティベートされていることを確認します。macOSデバイスで次を確認します。
Chromeで自動証明書の設定がされていることを確認します。
- Chromeのアドレスバーに「chrome://policy」と入力し、Enterキーを押します。
- [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”}}}
[cell]は、Okta Admin Consoleのフッターに表示されておりOkta orgが存在するセルです。
キーチェーンでネイティブアプリが許可されていることを確認する
次のコマンドを実行して、許可されたアプリが証明書にアクセスできることを確認します。「デフォルトのアプリの許可リストを変更する」を参照してください。
security dump-keychain -a okta.keychain
改善策の検証
ブラウザーやシッククライアントから、Device Trustでセキュリティ保護されたアプリにアクセスしてみてください。アプリにアクセスしようとしてエラーが表示された場合は、ブラウザー(ChromeまたはSafari)を[Quit(終了)]して[Close(閉じ)]、ブラウザーを再起動してから、再度アプリにアクセスしてみてください。
既知の問題
- O365ネイティブアプリへのアクセス時にセキュリティ要件ページが表示されない:管理されていないmacOSデバイスを持つエンドユーザーが、このDevice Trustソリューションによって保護されたOffice O365ネイティブアプリにアクセスしようとすると、[Security requirements(セキュリティ要件)]ページが表示されません。(この問題はOfficeのネイティブアプリでのみ発生し、ChromeやSafariなどのデスクトップブラウザーからO365アプリにアクセスしようとする場合には発生しません)。
- Googleのバックアップと同期アプリへのアクセスに問題がある:バックアップと同期アプリ(Googleドライブの一部)にサインインすると、認証フローがアプリに進まず、Googleアカウントのページで停止します。Googleはこの問題を認識しています。サインインを完了するには、ページ下部の[Sign in with your browser instead(代わりにブラウザーでログイン)]リンクをクリックします。