こんにちは！ たつみんです。
Okta Identity Engine（以下OIE）で利用可能になったOkta Device Trustを検証しましたのでご紹介いたします。
2021年11月18日現在、OIEは新規発行されるテナントに限り適用されます。これまでのOkta Classic EngineからOIEへ移行する時期や方法については別途Okta社からのアナウンスをお待ちください。
それでは早速設定方法についてみてみましょう。
参照ドキュメント
検証にあたり参照したドキュメントは以下の通りです。
- 前提条件について
- Jamf Proを利用した動的SCEPチャレンジの設定について
前提条件
macOSでのデバイストラストを実現するには下記の3点が前提条件となります。
- macOS 10.15.x (Catalina), and 11 (Big Sur)
- Safari (Credential SSO Extensionが必要), Chrome
- macOS版Okta Verifyアプリを利用しアカウントを紐づけている
Okta Verifyへのアカウント設定についてはこちらの記事をご参照ください。
なお、ドキュメントには記載がありませんでしたが、macOS 12 Montereyでも動作することを確認しております。
設定方法
OktaでSCEP URLを生成
- OktaのSecurity>Device integrations>Endpoint Management>Add Platformをクリックします。
- Desktop (Windows and macOS only)を選択し、Nextをクリックします。
- SCEP URL challenge typeをDynamic SCEP URLのGenericを選択し、Generateをクリックします。
- SCEP URLとChallenge URLとUsernameおよびPasswordを控えた後、Saveを押し保存します。
Jamf Pro SCEP設定
- コンピュータ>構成プロファイル>新規をクリックします。
- 一般タブでプロファイルの名称を入力（今回はOIE_DynamicSCEPとしました）
- レベルはComputer Levelを選択します。
- SCEPタブ内の構成をクリックします。
- URLにOktaで発行したSCEP URLを入力します。
- 名称はわかりやすいものを入力します。（今回はOIEとしました）
- プロファイル再配布は30daysとし、証明書が切れる30日前に自動的に再配布されるように設定をしました。
- 件名は
O=UUID,CN=$UDIDを入力します。- 7.のプロファイルの再配布設定により、自動的に件名に$PROFILE_IDENTIFIERが追加されてしまいます。これにより件名のパラメータの長さが64文字をオーバーし、プロファイル再配布ができない事象を観測しています。
- そのため64文字以内となるよう件名を調整してください。
- 例1：CN=$SERIALNUMBER $PROFILE_IDENTIFIER
- 例2：CN=$EMAIL $PROFILE_IDENTIFIER
- チャレンジタイプはDynamic-Microsoft CAを選択します。
- SCEP管理者のURLにOktaで発行したChallenge URLを入力します。
- ユーザー名およびパスワードもそれぞれOktaで発行した値を入力します。
- キーサイズを2048とし、デジタル署名として使用にチェックを入れます。
- キーチェーンからのexportを許可のチェックを外します。
- すべての App にアクセスを許可にチェックを入れます。
- 保存をクリックします。
Jamf Pro SSO拡張機能設定
- コンピュータ>構成プロファイル>新規をクリックします。
- 一般タブでプロファイルの名称を入力（今回はOIE_Extensible SSOとしました。）
- レベルはComputer Levelを選択します。
- シングルサインオン拡張機能タブで追加をクリックします。
- 拡張識別子にcom.okta.mobile.auth-service-extensionを入力します。
- チーム識別子にB7F62B65BNを入力します。
- サインオンタイプはCredentialを選択します。
- レルムにOkta Deviceを入力します。
- ホストにOktaのURLを入力します。この時https://は不要です。
- 保存をクリックします。
最後に、忘れずに作成した2つの構成プロファイルを対象端末に配布します。
Okta Authentication policiesの設定
Device Trust用のAuthentication policyを作成していない場合は以下の手順で作成するか、DefaultのラベルがついているAny two factorsなどのポリシーに以下のようなルールを組み込みます。
今回は検証結果をわかりやすく確認するために新規でポリシーおよびルールを作成しています。
- Okta管理画面のSecurity>Authentication policiesからAdd a policyをクリックします。
- 名前をDevice Trust Policyなどわかりやすいものを設定します。
- Add Ruleをクリックします。
- Rule nameをDevice Trust Ruleなどわかりやすいものを設定し、Device state isをRegisteredにしDevice management isをManagedにし、Saveをクリックします。
- 最初からあるCath-all Ruleを編集し、Access isをDeniedとしSaveをクリックします。最終的に以下のような2つのルールから構成されるポリシーとなっているかを確認します。
- Applicationsタブ内のAdd appをクリックします。
- 作成したポリシーを割り当てるアプリケーションのAddボタンをクリックし、最後にCloseをクリックします。
作成したポリシーは上から順番に判定され、ルールに該当しない場合に次のルールに一致するかどうかを確認します。今回の例ではDevice Trust Ruleに合致しない場合はCatch-all Ruleにて合致し、結果としてアクセスを拒否する設定としています。
動作確認
Oktaアプリケーション制御の確認
- 端末側でJamf Proで配布した構成プロファイルが適用されているかを確認します。
- Oktaにログインしている場合は一度、ログアウトしてから再度ログインをします。
- 対象アプリケーションにアクセス可能かを確認します。
なお、正常にアクセスできなかった場合は以下のような表示となります。
Devices上の確認
Okta管理画面のDirectory内のDevicesに該当端末のStatusがManagedとなっていることを確認します。
最後に
簡単にではありますがmacOSにおけるOkta Device Trustの設定方法をご案内いたしました。これまでのOkta Classic Engineの時よりも設定が容易になったように思います。
次回はWindowsにおけるデバイストラストの設定方法をご紹介いたします。それではまた〜?
