1. はじめに
本ブログ記事では、MDM (Mobile Device Management) の一つである「Microsoft Intune (以降、Intune)」を使って、SCEP (Simple Certificate Enrollment Protocol) でOktaからクライアント証明書 (Okta Device Trust用) を発行する手順について解説します。
前回の記事 (第13回) では、OpenSSLから発行したクライアント証明書を使って、Okta Device Trustを設定する方法を解説しました。この方法は自由度が高いので動作検証には使いやすいのですが、以下の課題があります。
◼︎ 秘密鍵のハードウェア保護 (TPM / Secure Enclaveへの格納) が容易ではない
◼︎ 配布プロセスの安全性に課題がある (秘密鍵の生データ (PKCS#12またはPFXファイル) がネットワークを流れたり、管理者のPCに一時保存されたりする)
◼︎ 運用ライフサイクルの自動化が難しい (100台、1,000台といった大規模環境への一斉配布や期限切れ前更新が面倒)
MDMを使ったSCEPによるクライアント証明書の配布であれば、これらの課題を克服します。
ということで、以降はMDMとして有名なIntuneを使った、SCEPによるクライアント証明書発行の設定ステップを解説します。
2. SCEPによるクライアント証明書発行のイメージ
事前の設定が一通り完了した後の、SCEPによるクライアント証明書発行のフローイメージを示します。
(IntuneだけでなくEntra IDも登場しますが、Entra IDはGraph APIアクセスに対するOAuthの認可サーバとして動作します。)
(1) Intuneは、事前に設定しておいた「信頼済み証明書プロファイル」を、クライアントに仕込みます。(このプロファイルは、Oktaから事前にダウンロードしたOkta CAの証明書を含んでいます。)
(2) Intuneは、事前に設定しておいた「SCEP証明書プロファイル」を、クライアントに仕込みます。
(3) クライアントは、Intuneにチェックイン (同期) して「SCEPチャレンジ (一時的な文字列) 」を受け取ります。
(4) クライアントは、秘密鍵と公開鍵のペアを生成し、その公開鍵を持つ署名リクエスト (CSR) を生成します。
(TPM対応のWindowsクライアントであれば、秘密鍵はTPMで生成されます。)
(5) クライアントは、「SCEPチャレンジ」と「署名リクエスト (CSR)」をOktaに送ります。
(6) Oktaは、IntuneへのAPIアクセスを行うために、OAuthでEntra IDから「アクセストークン」を受け取ります。
(7) Oktaは、その「アクセストークン」でGraph APIにアクセスし、「SCEPチャレンジ」を検証するIntuneのAPIを呼び出します。
(8) Intuneは、そのSCEPチャレンジの検証が成功したら、その旨をOktaに通知します。
(9) Okta CAが、(5)で受け取ったCSRに対して必要な処理 (情報付与や署名) を行って、クライアント証明書を生成し、クライアントに送ります。
(10) クライアントは、受け取ったクライアント証明書の署名を、(1) の中にあるOkta CAの証明書で署名検証し、それが成功したら、クライアントの証明書ストアに保存します。
3. 設定前の下準備
以降、設定を進めていきますが、その前に以下の条件を整えておく必要があります。
◼︎ OktaとEntra IDへのユーザー登録が必要です。
本記事では「asaku.akawa@doooob.xyz」というユーザーがどちらにも登録されています。
◼︎ 対象ユーザーは、何らかのEntra ID上のグループに所属している必要があります。
本記事では「asaku.akawa@doooob.xyz」は「Microsoft_apps」というセキュリティグループに属しています。
◼︎ 対象ユーザーには、Intune利用が可能なライセンス (M365 E3、F1等) が割り当てられている必要があります。
◼︎ 対象ユーザーは、Entra Joinしておく必要があります (Intuneの管理対象デバイスになるために) 。
◼︎ Entra Joinしたその対象ユーザー(本記事では「asaku.akawa@doooob.xyz」)で、Windowsログオンしておいてください。
4. Intuneを使ったSCEPの設定
では、実際に設定していきましょう。
基本的に、このLinkのマニュアルに記載の内容に沿って設定していきます。
4.1. Entra IDの設定
まずは、Entra IDの、OAuth認可サーバとしての設定が必要です。
「Microsoft Entra管理センター」で、「アプリの登録」を選択します。
「新規登録」をクリックします。
任意の名前 (ここでは「NewApp001」としました) を設定し、「この組織ディレクトリのみに含まれるアカウント」を選択し、「登録」をクリックします。
「アプリケーション (クライアント) ID」をコピーして、一時的にメモしておいてください。(後ほどOktaの設定で使います。)
「証明書とシークレット」→「クライアントシークレット」タブ→「新しいクライアントシークレット」をクリックして表示された画面で、任意の説明 (ここでは「ClientSecret001」としました) を設定し、「追加」をクリックします。
生成されたクライアントシークレットの「値」をコピーして、一時的にメモしておいてください。(後ほどOktaの設定で使います。)
(※「シークレットID」ではなく「値」が必要であることにご注意ください。)
「APIのアクセス許可」→「アクセス許可の追加」で表示された右画面で「Intune」をクリックします。
「アプリケーションの許可」をクリックして表示された画面の「アクセス許可を選択する」の下のフォームに「SCEP」と入力して表示された「scep_challenge_provider」にチェックを入れて、「アクセス許可の追加」をクリックします。
同様の方法で、今度は「Microsoft Graph」をクリックします。
「アプリケーションの許可」をクリックして表示された画面の「アクセス許可を選択する」の下のフォームに「application」と入力して表示された「Application.Read.All」にチェックを入れて、「アクセス許可の追加」をクリックします。
「XXXXXに管理者の同意を与えます」をクリックして表示された画面で「はい」をクリックします。
(XXXXXは、ご自身のEntra IDテナント名です。)
4.2. Oktaの設定
次に、Oktaの設定を行います。
「セキュリティ」→「デバイス統合」→「エンドポイント管理」タブで、「プラットフォームを追加」をクリックします。
「デスクトップ (WindowsおよびmacOSのみ) 」を選択して、「次へ」をクリックします。
認証局では「認証局としてOktaを使用」を選択し、SCEP URLチャレンジタイプでは「Microsoft Intune (委任SCEP)」を選択します。
Entra IDの設定の章でコピーしておいた「アプリケーション (クライアント) ID」を「AADクライアントID」へ、「クライアントシークレットの値」を「AADシークレット」へペーストします。
AADテナントには、ご自身のEntra IDテナント名に「.onMicrosoft.com」を付与して設定してください。
そして「生成」をクリックします。
「SCEP URL」が生成されるので、「クリップボードにコピー」して、一時的にメモしておいてください。(後のIntuneの設定で使います。)
そして「保存」をクリックします。
デバイス統合のまま、「認証局」タブをクリックします。
「Okta CA」と書かれた行の一番右のダウンロードボタンをクリックして、CA証明書をダウンロードします。
ダウンロードしたファイルの「cert」というファイル名を「cert.cer」に変更してください。
4.3. Intuneの設定
次に、Intuneの設定を行います。
「Microsoft Intune管理センター」で、「デバイス」→「プラットフォーム別」の下の「Windows」をクリックします。
まず、「信頼済み証明書プロファイル」の設定を行います。
「構成」→「作成」をクリックして表示された右画面で、プラットフォームは「Windows 10以降」、プロファイルの種類は「テンプレート」、その下の検索フォームに「証明書」と入力して表示されたテンプレート名中から「信頼された証明書」を選択して、「作成」をクリックします。
任意の名前 (ここでは「OktaCert001」としました) を入力して、「次へ」をクリックします。
Oktaからダウンロードして、ファイル名を変更しておいた「cert.cer」をアップロードしてください。
保存先ストアでは、「コンピューター証明書ストア - 中間」を選択して、「次へ」をクリックしてください。
(Oktaからダウンロードした証明書「cert.cer」は、中間証明書だからです。)
「グループを追加」をクリックして表示された右画面でグループを選択して「選択」をクリックしてください。
(本記事で利用する「asaku.akawa@doooob.xyz」は「Microsoft_apps」グループに属していますので、それを選択しています。)
この「適用性ルール」の設定は必須ではないので「次へ」をクリックします。
「作成」をクリックします。
次に「SCEP証明書プロファイル」の設定を行います。
これは、Intune管理下のユーザーやデバイスに対して、Oktaを認証局としてクライアント証明書を発行させるための設定です。
「構成」をクリックして表示された右画面で、プラットフォームは「Windows 10以降」、プロファイルの種類は「テンプレート」、その下の検索フォームに「SCEP」と入力して表示されたテンプレート名の「SCEP証明書」を選択して、「作成」をクリックします。
任意の名前 (ここでは「Okta_SCEP_Cert001」としました) を入力して、「次へ」をクリックします。
「構成設定」の画面では、以下のように設定します。
◼︎ 証明書の種類: 「ユーザー」
◼︎ サブジェクト名の形式: 「CN={{UserPrincipalName}},G={{GivenName}},SN={{SurName}}」 (←デフォルトのままでも問題なさそうでしたが、一応マニュアルの例に記載に従って設定しておきましょう。)
◼︎ キー記憶域プロバイダー (KSP): 「トラステッド プラットフォーム モジュール (TPM) KSP が存在する場合は TPM KSP に登録する (それ以外はソフトウェア KSP に登録する)」
◼︎ キー使用法: 「デジタル署名」
◼︎ キー サイズ (ビット): 「2048」
◼︎ ハッシュ アルゴリズム: 「SHA-2」
◼︎ ルート証明書: 先ほど設定した信頼済み証明書プロファイル (本記事では「OktaCert001」)
◼︎ 拡張キー使用法 > 定義済みの値: 「クライアント認証」
◼︎ SCEP サーバーの URL: 「Oktaの設定」の際にコピーしておいたSCEP URL
「次へ」をクリックします。
「グループを追加」をクリックして表示された右画面でグループを選択して「選択」をクリックしてください。
(「信頼済み証明書プロファイル」で選択したグループと同じにする必要があるので、本記事では「Microsoft_apps」グループを選択しています。)
そして「次へ」をクリックします。
この「適用性ルール」の設定は必須ではないので「次へ」をクリックします。
「作成」をクリックします。
設定は以上です。
(少々設定ステップが多いですね。お疲れ様でした。)
5. 動作確認
設定が完了したので、動作を確認してみましょう。
対象ユーザー (本記事では「asaku.akawa@doooob.xyz」) でWindowsクライアントにログインした状態で、「設定」→「アカウント」→「職場または学校にアクセスする」で表示された画面で、「asaku.akawa@doooob.xyzによって接続済み」のプルダウンで表示された、管理者: doooob の「情報」をクリックします。
「デバイスの同期状態」の下の「同期」をクリックします。
Windows標準の「ユーザー証明書の管理」＝「certmgr」を開いてください。
「個人」→「証明書」フォルダに対象ユーザー (本記事では「asaku.akawa@doooob.xyz」) のクライアント証明書が生成されていれば成功です。
ちなみにOkta CAの証明書は、「中間証明機関」→「証明書」フォルダに、「Organization Intermediate Authority」として存在しているものが該当します。
以降は、前回の記事 (第13回) と同様に、例えばOkta Dashboardの認証ポリシールールを以下のように設定して、Okta Device Trustが動作することをご確認ください。
6. まとめ
本ブログ記事では、MDMによるSCEPを使ったクライアント証明書の発行について解説しました。
この記事に記載した方法を使うことで、以下のようなメリットを享受できます。
◼︎ 秘密鍵のハードウェア保護 (TPM / Secure Enclave):
この機能を利用すると、秘密鍵はデバイスのセキュリティチップ (TPM や Secure Enclave) 内で直接生成され、その外に出ることなく格納されます。これにより、OSの管理者権限であっても物理的に抽出 (エクスポート) 不可能な状態を実現し、私物PCへの流用や盗難リスクを封じ込めます。
◼︎ 配布プロセスの安全性:
(OpenSSLで発行する場合と違って、) 秘密鍵の生データ (PFXファイル) がネットワークを流れたり、管理者のPCに一時保存されたりすることがありません。「デバイスが自ら鍵を生成し、証明書を要求する」 仕組みのため、配布過程での紛失や漏洩リスクをゼロにできます。
◼︎ 運用ライフサイクルの自動化:
100台、1,000台といった大規模環境への一斉配布に加え、有効期限に伴う更新作業もユーザーや管理者の手を介さず全自動化が可能です。
本ブログ記事ではIntuneをベースに解説しましたが、SCEP証明書プロファイルに対応したMDMであれば同様のことができると思います。
Okta Device Trustを行う場合、SCEPはかなり有効な手段ですので、本方式のご採用をご検討頂ければと思います。
==========
Okta Workforce Identityでは、認証の強化だけに留まらず、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しています。(日本語でのトレーニングもご用意しています。)
このトレーニングは全体像を体系的にご理解頂ける内容となっていますので、是非ともご活用ください。