こんにちは！ たつみんです。
前回はOkta Identity Engine（以下OIE）環境におけるmacOSのOkta Device Trustの設定ご紹介しましたが、今回はWindowsでの設定方法についてご紹介します。
2021年11月18日現在、OIEは新規発行されるテナントに限り適用されます。これまでのOkta Classic EngineからOIEへ移行する時期や方法については別途Okta社からのアナウンスをお待ちください。
- 2022.09.20 クライアントシークレットの入れ替えについてを追加しました。
- 2023.08.20 設定方法をドキュメントに準拠するように再構成しました。
参照ドキュメント
検証にあたり参照したドキュメントは以下の通りです。
- 前提条件について
- Microsoft Intuneを利用した動的SCEPチャレンジの設定について
前提条件
Windowsでのデバイストラストを実現するには下記の3点が前提条件となります。
- Windows 10, 32-bit and 64-bit
- Chrome
- Windows版Okta Verifyアプリを利用しアカウントを紐づけている
Okta Verifyへのアカウント設定についてはこちらの記事をご参照ください。
なお、ドキュメントには記載がありませんでしたが、Windows 11 64-bitでも動作することを確認しております。
設定方法
Azureでアプリの登録
- Azure Active Directoryのアプリの登録から新規登録をクリックします。
- 名前をわかりやすいものを設定します。（今回はOkta Verifyとしました）
- サポートされるアカウントの種類でこの組織ディレクトリのみに含まれるアカウントを選択し、登録をクリックします。
- 登録情報のアプリケーション（クライアント）IDを控えておきます。
- 左側のメニューから証明書とシークレットをクリックします。
- 新しいクライアントシークレットをクリックします。
- 有効期限を設定し、追加をクリックします。（今回はデフォルト値の推奨：6ヶ月のままとしました）
- 生成された値を控えておきます。（シークレットIDでなく値を利用します）
- 左側メニューのAPIのアクセス許可へ移動し、アクセス許可の追加をクリックし、Intuneをクリックします。
- APIアクセス許可の要求でアプリケーションの許可をクリックします。
- scep_challenge_providerを選択し、アクセス許可の追加をクリックします。
- 再度、アクセス許可の追加をクリックし、Microsoft Graphをクリックします。
- アプリケーションの許可をクリックします。
- 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でない場合は手動で変更を行います。
Intuneで証明書の構成
- デバイス>構成プロファイル>プロファイルの作成をクリックします。
- プラットフォームをWindows10以降を選択します。
- プロファイルの種類はテンプレートを選択します。
- テンプレート名で信頼済み証明書を選択し、作成をクリックします。
- 名前を入力し、次へをクリックします。（今回はOIE_Windowsとしました）
- Okta証明書取得でダウンロードした証明書ファイルをアップロードします。
- 保存先ストアをコンピューター証明書ストア – 中間を選択し、次へをクリックします。
- 組み込まれたグループに検証用セキュリティグループを選択し、次へをクリックします。
- 適用性ルールを指定する場合は設定し、次へをクリックします。（今回は何も設定せずに進めました）
- 設定内容を確認し、作成をクリックします。
IntuneでSCEPの構成
- デバイス>構成プロファイル>プロファイルの作成をクリックします。
- プラットフォームをWindows10以降を選択します。
- プロファイルの種類はテンプレートを選択します。
- SCEP証明書を選択し、作成をクリックします。
- 名前を入力し次へをクリックします。（今回はOIE_Windows_SCEPとしました）
- 証明書の種類をユーザーを選択します。
- サブジェクト名の形式は以下を入力します。
CN={{UserPrincipalName}} ManagementAttestation {{AAD_Device_ID}} - キー記憶域プロバイダーはトラステッドプラットフォームモジュール（TPM） KSPが存在する場合はTPM KSPに登録する（それ以外はソフトウェアKSPに登録する）を選択します。
- キー使用法はデジタル署名を選択します。
- キーサイズは2048を選択します。
- ハッシュアルゴリズムはSHA-2を選択します。
- ルート証明書をクリックし、先の工程でIntuneに登録した信頼済み証明書を選択し、OKをクリックします。
- 拡張キー使用法の定義済みの値でクライアント認証を選択します。（名前とオブジェクト識別子は自動的に反映されます）
- SCEPサーバーのURLにOktaで生成したSCEP URLを入力し、次へをクリックします。
- 組み込まれたグループに検証用セキュリティグループを設定し、次へをクリックします。
- 適用性ルールを指定する場合は設定し、次へをクリックします。（今回は何も設定せずに進めました）
- 設定内容を確認し、作成をクリックします。
Windows端末上での設定反映確認
証明書のインストール状況の確認
- スタートボタンをクリックし、certを入力しEnterキーを押下します。
- 証明書マネージャー>個人>証明書へ移動します。
- 発行者がOrganization Intermediate Authorityの証明書があることを確認します。
- 中間証明機関>証明書へ移動します。
- 発行者がOrganization Root Authorityの証明書があることを確認します。
イベントログの確認
- スタートボタンをクリックし、Eventを入力しEnterキーを押下します。
- イベントビューワー>アプリケーションとサービス>Microsoft>Windows>DeviceManagement-Enterprise>Adminへ移動します。
- 下記のログがあるか検索します。
- SCEP: Certificate installed successfully
- SCEP: Certificate request generated successfully
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アプリケーション制御の確認
- 端末側でIntuneで配布した構成プロファイルが適用されているかを確認します。
- Oktaにログインしている場合は一度、ログアウトしてから再度ログインをします。
- 対象アプリケーションにアクセス可能かを確認します。
なお、正常にアクセスできなかった場合は以下のような表示となります。
Devices上の確認
Okta管理画面のDirectory内のDevicesに該当端末のStatusがManagedとなっていることを確認します。
クライアントシークレットの入れ替えについて
Azureでアプリの登録の手順7.で有効期限を6ヶ月としたため、有効期限を迎える前に新しいクライアントシークレットを追加し、Okta側の設定を更新する必要があります。有効期限の1ヶ月前を目安にリマインドを行うような仕組みを取るとよさそうです。
弊社の場合はAsanaを利用し、有効期間から-1つまり5ヶ月ごとの繰り返しタスクとしてリマインドを行なっています。このようにすることで有効期限の最低でも1ヶ月前にリマインドされるようになります。
クライアントシークレットの入れ替えについて具体的な手順は以下の通りです。
- Azure Active Directoryのアプリの登録を開き、すべてのアプリケーションからOkta Device Trust用に作成したアプリケーションを選択します。
- 証明書とシークレットをクリックします。
下図のように証明書の有効期限が近い場合や既に期限を迎えている場合はアラートが表示されます。
- 新しいクライアントシークレットをクリックします。
- 有効期限を設定し、追加をクリックします。
- 新しく生成された値を控えておきます。（シークレットIDでなく値を利用します）
- OktaのSecurity>Device integrations>Endpoint Managementを開き、Windows用の設定済みの項目のActionsからEditをクリックします。
- AAD secretに控えておいた新しく生成された値を入力し、Saveをクリックします。
Windows端末からDevice Trust用のAuthentication policiesが適用されたアプリケーションにアクセスできることを確認しましょう。
確認が完了し、有効期限が切れた古いクライアントシークレットは削除しておきましょう。
以上がクライアントシークレットの入れ替えの流れです。
誤解をしやすいのですが、今回ご紹介したクライアントシークレットの更新は各Windows端末に対して新しい構成プロファイルを配布するということではなく、Azureから見たクライアントであるOktaテナントに対するシークレットの更新を行います。そのため、各Windows端末に対して構成プロファイルを再配布するといったような工程は必要はありません。
今回のスクリーンショットでは2022/09/18に有効期限を迎えており、その2日後の2022/09/20に新しいクライアントシークレットを発行していますが、本来は有効期限を迎える前に作業を実施しましょう。
有効期限を迎える前にクライアントシークレットの更新を行えばダウンタイムを発生させることなくDevice Trustでのアプリケーションへのアクセスを維持することができます。
最後に
macOSの手順と比べると少し複雑ではありますが、Windows端末についてもOIE環境でデバイストラストを行うことができました。
次回はiOSやAndroidのOIEデバイストラストを行う方法について記事を公開予定となります。
OIEでできることが広がっていくのは楽しいですね。ではまた〜?♂️
