こんにちは！たつみんです。
以前IntuneとmacOSを組み合わせてDevice Trustを実現するブログを執筆した時に、Okta CAが利用できなかったのでSCEPmanを利用する方法をご紹介しました。
Okta CA（認証局：Certificate Authority）はデバイスを認証するための証明書を発行するのに利用できるのですが、検証当初はmacOSとJamfの組み合わせでは利用できたものの、Intuneとの組み合わせでは利用できませんでした。
しかし現時点では以下のドキュメントのようにSCEPmanを利用せずともIntuneとmacOSの組み合わせでもOkta CAを利用できるようになっていました。今日はこのドキュメントに沿って検証した結果をご紹介します
設定方法
Azureでアプリの登録
- Azure Active Directoryのアプリの登録から新規登録をクリックします。
- 名前をわかりやすいものを設定します。（今回はOkta Device Trustとしました）
- サポートされるアカウントの種類でこの組織ディレクトリのみに含まれるアカウントを選択し、登録をクリックします。
- 登録情報のアプリケーション（クライアント）IDを控えておきます。
- 左側のメニューから証明書とシークレットへ移動しします。新しいクライアントシークレットをクリックし、追加をクリックします。（今回は有効期限についてはデフォルト値の推奨：6ヶ月のままとしました）
- 生成された値を控えておきます。
- 左側メニューのAPIのアクセス許可へ移動し、アクセス許可の追加をクリックし、Intuneをクリックします。
- APIアクセス許可の要求でアプリケーションの許可をクリックします。
- scep_challenge_providerを選択し、アクセス許可の追加をクリックします。
- 再度、アクセス許可の追加をクリックし、Microsoft Graphをクリックします。
- APIアクセス許可の要求でアプリケーションの許可をクリックします。
- Application.Read.Allを選択し、アクセス許可の追加をクリックします。
- xxxxxに管理者の同意を与えますをクリックします。（xxxxxの部分はそれぞれの環境により異なります）
- 正常に完了すると以下のようになります。
OktaでSCEP URLを生成
- OktaのSecurity>Device integrations>Endpoint Management>Add Platformをクリックします。
- Desktop (Windows and macOS only)を選択し、Nextをクリックします。
- SCEP URL challenge typeをDynamic SCEP URLのMicrosoft Intuneを選択します。
- AAD client IDにAzureでアプリの登録で控えておいたアプリケーション（クライアント）IDを入力します。
- AAD tenantはAADテナント名.onMicrosoft.comを入力します。
- AAD secretにアプリの登録で控えておいた生成された値を入力します。
- Generateをクリックします。
- 生成されたSCEP URLを控えて、Saveをクリックします。
Okta証明書取得
- OktaのSecurity>Device integrations>Device Management>Certificate Authority>ActionsからOkta CAをダウンロードします。
- ダウンロードした証明書の拡張子が.cerでない場合は手動で変更を行います。
今回はOkta.cerとしました。
Intuneで証明書の構成
- デバイス>構成プロファイル>プロファイルの作成をクリックします。
- プラットフォームをmacOSを選択します。
- プロファイルの種類はテンプレートを選択します。
- テンプレート名で信頼済み証明書を選択し、作成をクリックします。
- 名前を入力し、次へをクリックします。（今回はOkta Device Trust macOSとしました）
- Okta証明書取得でダウンロードした証明書ファイルをアップロードします。
- 組み込まれたグループに検証用セキュリティグループを選択し、次へをクリックします。
- 設定内容を確認し、作成をクリックします。
IntuneでSCEPの構成
- デバイス>構成プロファイル>プロファイルの作成をクリックします。
- プラットフォームをmacOSを選択します。
- プロファイルの種類はテンプレートを選択します。
- SCEP証明書を選択し、作成をクリックします。
- 名前を入力し次へをクリックします。（今回はOkta Device Trust macOS SCEPとしました）
- 証明書の種類をユーザーを選択します。
- サブジェクト名の形式は以下を入力します。この内容はOktaのドキュメントの内容ではうまく動作しなかったため変更をしています。
CN={{UserName}},E={{EmailAddress}} - キー使用法はデジタル署名を選択します。
- キーサイズは2048を選択します。
- ルート証明書をクリックし、先の工程でIntuneに登録した信頼済み証明書を選択し、OKをクリックします。
- 拡張キー使用法の定義済みの値でクライアント認証を選択します。（名前とオブジェクト識別子は自動的に反映されます）
- SCEPサーバーのURLにOktaで生成したSCEP URLを入力します。
- Allow all apps access to private key（すべてのアプリが秘密鍵にアクセスできるようにする）］：［Enable（有効化）］を選択し、次へをクリックします。
- 組み込まれたグループに検証用セキュリティグループを設定し、次へをクリックします。
- 設定内容を確認し、作成をクリックします。
Mac端末上での設定反映確認
証明書のインストール状況の確認
- システム設定よりプロファイルを開きます。
- SCEP Profileをクリックし、証明書の項目を確認します。
- キーチェーンアクセスで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アプリケーション制御の確認
- Oktaにログインしている場合は一度、ログアウトしてから再度ログインをします。
- 対象アプリケーションにアクセス可能かを確認します。
なお、正常にアクセスできなかった場合は以下のような表示となります。
Devices上の確認
Okta管理画面のDirectory内のDevicesに該当端末のStatusがManagedとなっていることを確認します。
クライアントシークレットの入れ替えについて
Azureでアプリの登録の手順5.で有効期限を6ヶ月としたため、有効期限を迎える前に新しいクライアントシークレットを追加し、Okta側の設定を更新する必要があります。有効期限の1ヶ月前を目安にリマインドを行うような仕組みを取るとよさそうです。
弊社の場合はAsanaを利用し、有効期間から-1つまり5ヶ月ごとの繰り返しタスクとしてリマインドを行なっています。このようにすることで有効期限の最低でも1ヶ月前にリマインドされるようになります。
クライアントシークレットの入れ替えについて具体的な手順は以下の通りです。
- Azure Active Directoryのアプリの登録を開き、すべてのアプリケーションからOkta Device Trust用に作成したアプリケーションを選択します。
- 証明書とシークレットをクリックします。
下図のように証明書の有効期限が近い場合や既に期限を迎えている場合はアラートが表示されます。
- 新しいクライアントシークレットをクリックします。
- 有効期限を設定し、追加をクリックします。
- 新しく生成された値を控えておきます。（シークレットIDでなく値を利用します）
- OktaのSecurity>Device integrations>Endpoint Managementを開き、macOS用の設定済みの項目のActionsからEditをクリックします。
- AAD secretに控えておいた新しく生成された値を入力し、Saveをクリックします。
macOS端末からDevice Trust用のAuthentication policiesが適用されたアプリケーションにアクセスできることを確認しましょう。
確認が完了し、有効期限が切れた古いクライアントシークレットは削除しておきましょう。
以上がクライアントシークレットの入れ替えの流れです。
誤解をしやすいのですが、今回ご紹介したクライアントシークレットの更新は各Mac端末に対して新しい構成プロファイルを配布するということではなく、Azureから見たクライアントであるOktaテナントに対するシークレットの更新を行います。そのため、各Mac端末に対して構成プロファイルを再配布するといったような工程は必要はありません。
今回のスクリーンショットでは2022/09/18に有効期限を迎えており、その2日後の2022/09/20に新しいクライアントシークレットを発行していますが、本来は有効期限を迎える前に作業を実施しましょう。
有効期限を迎える前にクライアントシークレットの更新を行えばダウンタイムを発生させることなくDevice Trustでのアプリケーションへのアクセスを維持することができます。
最後に
2年ほど前に検証した時はできないと思っていましたが、いつの間にかSCEPmanを使わずにDevice Trustを実現できるようになっていたのでいい進化ですね。macOS端末をIntuneで管理している場合のDevice Trustを構成するハードルがずいぶんと下がりましたね。
それではまた別の記事でお会いしましょー?
