Cloud PKIを使ってEntra IDの証明書認証を試してみた
みなさんこんにちは。
2024年2月末に、IntuneのCloud PKI機能がリリースされました。
Intune単体でクライアント証明書が発行できるということで、非常に気になっていた機能です。
今回はCloud PKIの証明書の発行と、あわせてEntra IDのCBA（証明書ベース認証）を試してみました。
ゴールデンウィーク特別企画です。（暇だっただけ）
とりあえずやってみたという結果ですので、本番利用される際は十分に検証を行ってから適用されることをおすすめいたします。
Cloud PKIからクライアント証明書を配布する
現状、公開情報は概要程度の記載しかありません。
これではちょっと厳しいかなと思います。
しかしながら、既に有志の方々が発行プロセスについて解説してくれていますので、そちらを参考にしながら設定を進めることができました。
ありがたいことです。
玉井さんのBlog
https://sccm.jp/2024/05/01/post-6220
詳しい手順は上記御二方の記事をご覧いただければと思いますが、証明書配布までの大まかな流れは以下となります。
Cloud PKIのルートCAを作成する。
Cloud PKIの発行元CAを作成する。
構成プロファイルでルート証明書を配布する。
構成プロファイルで中間（発行元）証明書を配布する。
構成プロファイルでクライアント証明書（SCEP証明書）を配布する。
まずテナント管理＞CA管理から、ルートおよび発行元CAを作成しました。
設定値は検証なので割と適当に決めてしまいましたが、参考までに貼っておきます。
発行元CAが必要な理由は、SCEP証明書の設定でSCEP URIが必要になるためです。
なお、画面のとおり現時点では作成後のCAを編集・削除する機能がありません。
削除するにはサポートに問い合わせが必要だそうです。
CNをスペルミスしていることに後で気づきましたが、どうしようもありません。
また、CA管理に登録できる最大数は6とのこと。
下手に不要なCAを作成しないよう注意が必要ですね。
この段階でよく一般提供したな、と思わないでもないですが、このあたりはいずれ改善されることでしょう。
CAを作成したら、必要な構成プロファイルを作成します。
今回試すのはWindowsです。
余談ですが、証明書の構成プロファイルって何でWin8.1以降の表示なんでしょうね。
信頼済み証明書にはそれぞれCA管理からダウンロードした証明書をアップします。
SCEP 証明書の値はこんな感じです。
何となくCAの値に合わせて作成しました。
まだ公開情報がないので雰囲気でやるしかありません。
ちなみに、メールアドレスを持たないユーザーでサブジェクトに{{EmailAddress}}を指定していると証明書発行に失敗するそうなので、ここは注意が必要です。
プロファイルの割り当てを行うと、端末の証明書ストアにそれぞれの証明書が格納されました。
なお今回は念の為、ルート→中間→クライアントの順にインストールの確認が出来てから後続のプロファイルを割り当てしました。
一気に全部割り当てしても上手く展開されるのかは検証した方がいいかもしれません。
証明書が発行されると、CA管理の方で詳細が確認できるようになっていました。
手動で失効させることも出来るようです。
CBAの設定を行う
証明書が配布できたので、Entra IDでCBAの設定をしていきます。
手順はこちらになります。
証明機関にCAを設定する
認証方法で証明書ベースの認証を有効化する
という2つの設定をしていきます。
まずSecurity Center>証明機関に、Cloud PKIの証明書をアップロードします。
ここで証明書失効リストのURLが必要になるので、Intune管理センターのCA管理からCRL 配布ポイントの値をコピーします。
ルートと発行元CAの2つを登録しておきます。
次に認証方法>ポリシーで、証明書ベースの認証の設定を開き、有効化します。
構成タブの方は必要に応じて設定にはなりますが、今回は殆ど初期値のままです。
ではサインインを試してみます。
認証時に”証明書またはスマートカードを使用する”を選択し、
表示される証明書を選択します。
無事サインインすることができました。
CBAでネックになる点が、ユーザー名バインドです。
証明書の所定の属性にUPNまたはCertificateUserIDsが設定されていないと、認証が通らない仕様になっています。
CBAのサインインログを見ると、以下のようになっていました。
”ユーザー証明書のバインド”の項をご覧ください。
RFC822NameがどうやらEmailアドレスのようなのですが、証明書のサブジェクトのメールアドレスとUPNが一致したからOK、ということなのではないかと思います。
気になったのでUPN自体を埋め込んでも通るかやってみました。
SCEP証明書の設定で、サブジェクトの別名にUPNを設定します。
証明書を再発行すると、属性にプリンシパル名が追加されました。
サインインすると、今度はPrincipalNameにバインドされている事が確認できました。
条件付きアクセスで証明書を要求する
CBAの設定だけでは認証時に利用できるだけで、要求することまではできません。
要求するには条件付きアクセスを使用する必要があります。
以前は証明書認証の要求のためにMDCAポリシーが必要でしたが、認証強度がリリースされたことでその必要がなくなりました。
事前準備として、条件付きアクセス>認証強度からカスタムの認証強度を作成します。
"証明書ベースの認証(多要素)"のみにチェックを入れれば、MFA要素でCBAのみが指定できます。
カスタム認証強度を作成したら条件付きアクセスポリシーを作成します。
アクセス制御の"認証強度が必要"にチェックを入れ、前段で作成した認証強度を設定します。
証明書をインストールしていない端末でサインインを試すと、PW入力後に証明書を要求されました。
インストール済み端末では、証明書を提示してサインインが可能です。
なお、気になる点もありました。
証明書インストール済み端末でこんな通知が。
Intuneとの同期が失敗しています。
手動で同期ボタンを押してみると、サインイン失敗画面に。
どうやら条件付きアクセスの対象をすべてのアプリにしていたことで、Intuneの同期処理に影響が出たようです。
とりあえずクラウドアプリからMicrosoft Intuneを除外することで、その後は同期できるようになりました。
もしかすると他にも影響があるかも知れません。
証明書認証にも課題はありそうです。
まとめ
今回はCloud PKIと、それを利用した認証について試しました。
アクセス制御にクライアント証明書を利用しているケースは多いと思いますが、これまでEntra IDで実現するのは割とハードルが高いものでした。
Cloud PKIと組み合わせることで、365サブスクリプション内で完結できるようになるのはメリットかと思います。
一方で、証明書認証に対するMicrosoftのスタンスははっきりしないところがあります。
前述のとおり以前まではアクセス制御に証明書を使わせることに消極的で、条件付きアクセスでも公には設定を用意していませんでした。
デバイス準拠を使わせたいのだろうと思っていましたが、では何故その後CBAをリリースしたのか。
セキュリティ観点で証明書認証を安全と考えているのか、どうなのか。
そのあたりはもう少し明確に示してほしいと思っています。
デバイス準拠とCBAそれぞれにメリデメはある気がしていますので、上手く使い分けができればいいのかなと思います。
皆様にとって参考になれば幸いです。
この記事が気に入ったらサポートをしてみませんか？