はじめに

Intune を使うと、クラウド経由でデバイスにクライアント証明書（SCEP 証明書）を配布できます。

いくつかの方法があり、以下の記事で紹介しています。、

（上記の記事より抜粋）
① Intune と NDES を Intune 証明書コネクタで連携した環境
② Microsoft クラウド PKI を使用する
③ サードパーティの SCEP 提供サービスを利用する

本記事では、上記のうち ② Microsoft クラウド PKI を使用する を使った証明書の配布方法とともに、Wi-Fi の認証と組み合わせるところまでを紹介していきます。

注意点（あらかじめ、ご承知おきください）

この記事で紹介する内容は、発展途上です。

既に検証済みの「① Intune と NDES を Intune 証明書コネクタで連携した環境」の方法と比べて、もっと簡単な手順で、構成がシンプルになることを期待して検証に臨んだのですが、NPS との組み合わせにおいての制約にも引っ掛かり、結果的にあまりシンプルではない構成になってしまいました。

さらに、NPS 側の研究を重ねて、シンプルな構成に出来ないかを模索したいと考えていますが、ひとまず現時点で Cloud PKI を使って配布した証明書を NPS と連携させることができた結果を報告したいと思います。

当初に目指していた構成（課題発生）

既存のオンプレミス Wi-Fi 環境（オレンジ色）に、テナント側（水色）を追加で構成します。テナントへ Entra Join した Windows PC を Wi-Fi にクライアント証明書の認証で接続できるようにする事が目標です。

オレンジ色の環境は、以下の記事の手順で構築できます。

オンプレミスのドメイン環境の場合は、エンタープライズ CA や GPO の仕組みを使って、証明書や Wi-Fi 接続プロファイルが自動的に配布されます。

しかし、Entra Join の Windows PC は、ドメインに参加していないため、それらの配布を受ける事ができないため、この仕組み「テナント側の構成（水色）」を追加構築して、Intune + Cloud PKI の仕組みを使って補う構想です。

しかし、この方法では、動作させられませんでした。

OK だった点
この構成で、証明書のチェーンのチェックは、意図通りに動作しました。

証明書チェーンのチェックとは
NPS サーバーは、PC から提示されたクライアント証明書が正しいもののかどうかを評価するために、サーバー内の NT Auth ストア上の ルート証明書 および 中間証明書 と クライアント証明書 の整合性を評価します。

PC は、サーバーから提示されたサーバー証明書が正しいものかどうかを評価するために、PC 内の ルート証明書 と サーバー証明書 の整合性を評価します。

このとき、各証明書間が鎖のようにつながっているかを確認するので、証明書チェーンのチェックと呼ばれます。

NG だった点
NPS サーバーは、証明書チェーンのチェック以外に、以下のようにドメイン内にオブジェクトが存在しているかどうかをチェックしています。

マシン認証の場合は、コンピューターオブジェクトがドメインに存在するか？
ユーザー認証の場合は、ユーザーオブジェクトがドメインに存在するか？

この場合、Entra Join の PC は、オンプレミス側のドメイン内に存在しないため、このチェックに合格することができず、Wi-Fi の認証に失敗してしまいます。

課題解決のためにトライしたこと ①（結果 NG）

オンプレミスドメインとテナント間を Entra Connect で同期します。

Entra Connect のデバイスライトバックの仕組みを使って、Entra ID 上のデバイスをドメイン内のオブジェクトとして書き戻してみました。

しかし、これを行っても NPS では、オブジェクトとして認識してくれませんでした。

ライトバックされたオブジェクトを ADUC で確認してみたのですが、オブジェクト名が固有の ID のようなもので生成されていて、コンピューター名とは違っていました。これだと、NPS サーバーでは認証に使ってくれない様子です。

まだ、研究の余地があるような気もしますが、ここで挫折して ② の方法を試すことにしました。

課題解決のためにトライしたこと ②（結果 OK）

同じく、オンプレミスドメインとテナント間を Entra Connect で同期された環境を使います。

条件１
Entra Join した PC にサインインする時には、オンプレから同期されたハイブリッドユーザーを使います。

条件２
SCEP 証明書を発行する際の設定を、「マシン」から「ユーザー」に変更します。

こうすることで、Cloud PKI から発行されたクライアント証明書（SCEP 証明書）を使って、Wi-Fi 認証を行えることを実証できました。

動作させることに成功した構成のイメージ

この構成での問題点（動作はするけど、美しくない）
ひとまず、最低限 Cloud PKI で発行した証明書を使っての Wi-Fi に認証は実現できたのですが、この構成を運用で使えるのかと考えると、イマイチ微妙です。

従来から、オレンジ色の構成を運用していた環境があり、Entra Connect も導入済みの会社が、追加で Entra Join された PC にも Wi-Fi を提供したい場合には使えなくもないですが、ハイブリッドユーザーにしか対応していない点が弱点です。

やはり、Entra ID 側で新規発行したユーザー（クラウドユーザー）でサインインした PC で使えるようにしなきゃダメなんじゃないかと思います。
※ハイブリッドユーザーでしか使えない場合は、Cloud PKI のライセンスを買ってまで採用すべきソリューションとは言えない気がします。

何故かと言うと、既に以下の記事で紹介済みの ① Intune と NDES を Intune 証明書コネクタで連携した環境 を使えば、Entra Join PC にクラウドユーザーでサインインした際の Wi-Fi 認証が可能だからです。この方法だと、Cloud PKI のライセンス費用は掛かりません。

この構成の方が、ちょっと複雑ではありますが、私が運用者だったらこちらを選択します。

目指すべき構成とは
やはり、目指すべきは選択肢として選ばれるような構成でないとダメだと思います。
以下を実現すべきです。
・クラウドユーザーがサインインしても利用できる
・ドメインのオブジェクトチェックが不要（証明書チェーンのチェックのみで認証）
・構成がシンプルである
・上記のメリットがあれば Cloud PKI のライセンスを払う価値がある

目指すべき構成のイメージ

Standalone CA は、NPS のサーバー証明書を発行するためだけに必要。
あとは、NPS が Wi-Fi AP の RADIUS 認証を受け持つだけで OK となり、かなりシンプルな構成です。

この構成を目指して、引き続き調査＆検証は継続していきます。

検証済みの環境について

前章までで、だいぶ言い訳のような説明が続いてしまいましたが、現時点で検証できている構成についてのポイントを紹介しておきます。

（再掲）

普段の私の記事は、なるべく Step by Step でキャプチャを用意することを心掛けていますが、この記事は実現できた要点を紹介することが主旨ですので、ポイントの紹介に留めている点をご承知おきください。

1. 前提となる環境

オレンジ色で記載された オンプレミス環境 が構築済みである想定です。
以下の記事を参考に構築可能です。

2. Entra Connect を構成する

オンプレミス環境と Entra テナント間を Entra Connect で同期します。
Connect する際には、ドメイン名をしっかりと検討する必要があります。

上記の記事でも説明していますが、オンプレもテナントも新規で構築する場合には、ドメイン名を一致させます。既存の環境と組み合わせて構築する場合は、カスタムドメインをうまく活用する必要がある点に注意してください。

私が検証した環境では、カスタムドメインで "carol226.com" という名称を取得したテナントと、オンプレミスドメイン "avd.server-on.net" を代替 UPN サフィックスの方法を使って同期させました。

3. Intune ライセンスの契約

以下の記事を参考に Intune またはそれを含む上位ライセンス（Microsoft 365 E3/E5 or EMS E3/E5）を契約してください（無料試用あり）

4. Cloud PKI アドオンライセンスの契約

さらに以下の記事を参考に Cloud PKI または Intune Suite のライセンスを契約してください（無料試用あり）

5. Cloud PKI を使った CA の作成

Cloud PKI では、２通りの方法で CA を作成できます。
どちらの方式でも利用できると思いますが、私が NPS との連携で検証済みなのは独自の CA を使用する方法です（独自のCA = BYOCA とも言います）

公開情報：Microsoft Cloud PKI のルートと発行元 CA を構成する

公開情報：Microsoft Cloud PKI の構成 - 独自の CA を使用する

6. ルート証明書の配布

前章で Cloud PKI の CA を構成した場合と、BYOCA を構成した場合で、ダウンロードしておくルート証明書が違います。

どちらの方法の場合でも、オンプレミスのルート証明書をダウンロードしておきます。
このルート証明書は、PC がサーバー証明書のチェックを行うために必要です。
さらに、BYOCA の場合に、SCEP 証明書を発行する際に必要です。
　
オンプレミスのルート証明書は、以下の手順で入手します。
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/export-root-certification-authority-certificate?wt.mc_id=mvp_407731
　
Cloud PKI の CA の場合は、さらに以下のルート証明書をダウンロードしておく必要があります。SCEP 証明書を発行する際に必要です。
　
Intune 管理センターの CA 管理から、作成したルート CA を開き、以下の場所からダウンロードしたルート証明書をダウンロードしておきます。

以下の手順で、信頼済み証明書 の配布用の構成プロファイルを作成します。
Cloud PKI の CA の場合は、ルート証明書が２種類あるため、構成プロファイルを２つ作成します。

コンピューター証明書ストア - ルート を選択します。

ここで、ダウンロードしておいた Cloud PKI またはオンプレミスのルート証明書を指定します。

以下のように一覧に表示された状態になります。

Cloud PKI ルート CA の場合は、２行
BYOCA の場合は、１行

7. 中間証明書の配布

前章で Cloud PKI の中間 CA を構成した場合と、BYOCA を構成した場合、どちらも中間証明書の配布が必要です。

Intune 管理センターの CA 管理から、作成した「Cloud PKI の中間 CA」または「BYOCA」を開き、以下の場所から中間証明書をダウンロードしておきます。

構成プロファイルで 信頼済み証明書 を作成する際に、コンピューター証明書ストア - 中間 を選択します。

ダウンロードしておいた中間証明書を選択します。

以下のように一覧に表示された状態になります。

8. SCEP 証明書

作成した Cloud PKI CA の中間証明書または BYOCA を開き、以下の場所から SCEP の URL をコピーします。

証明書の種類 は、ユーザーで作成するのがポイントです。
SCEP サーバーの URL 欄に、コピーしておいた URL を貼り付けます。

以下のように一覧に表示された状態になります。

ポイント
上記の設定で、サブジェクトの別名欄で UPN が指定されているため、クライアント証明書には、サブジェクトの別名 (SAN) として、PC にサインイン時のアカウント名が挿入されます。

NPS サーバーが認証を行う際に、証明書チェーンのチェック（ルート－中間－クライアント証明書間の整合性）に加えて、証明書内の SAN に記載された UPN とドメイン内に存在するユーザーオブジェクト名が一致していることが検証されると、Wi-Fi の認証が成功します。

それが理由で、ハイブリッドユーザー（オンプレから同期されたユーザー）の場合だけ Wi-Fi に認証することができます。

クラウドユーザー（オンプレに無いユーザー）で PC にサインインしていた場合は、SAN としてクラウドユーザーの名前が採用されます。NPS サーバーが認証する際に、証明書チェーンのチェックは成立しますが、SAN に記載された UPN がドメイン内に存在するかが検証されますが、オンプレ側にはアカウントが無い為、アカウント不一致のエラーが発生して、認証は不成立となります。

9. Wi-Fi プロファイルの配布

以下の記事を参考に PC に配布する Wi-Fi プロファイルを構成します。
なお、認証モードを ユーザー に変更する点だけ、読み替えてください。

上記の記事からの変更点

認証モードをユーザーに変更する
EAP の種類は、サーバー側と合わせてください（上記の Qiita 記事とズレがあるので注意）
以下のキャプチャは、サーバー側が EAP-TLS の場合です。
サーバー側が PEAP (EAP-TLS) の場合は、クライアント側もそれに合わせます。

以下のように一覧に表示された状態になります。

10. NT Auth ストアへ証明書のアップロード

NPS サーバーがクライアント証明書を認証するためには、NT Auth ストアに Cloud PKI のルート証明書と中間証明書をインポートしておく必要があります。

※BYOCA の場合は、中間証明書のみ NT Auth ストアにインポートします。
　ルート証明書は、既に　オンプレミスの証明書がインポート済みになっているため。

ポイント
私が検証していた時には、これが鬼門でした。
NT Auth ストアには、Cloud PKI のルート証明書のみをインポートした状態だと、NPS サーバーが、クライアント証明書のチェーンを検証できません。

中間証明書も NT Auth ストアにインポートすることで、証明書チェーンを正常に検証できるようになります。これに気が付くまで、かなりハマりました。

公開情報：Enterprise NTAuth ストアにサードパーティ証明機関 (CA) 証明書をインポートする方法

11. Intune に登録した Windows デバイス

Wi-Fi に接続予定の物理 PC を手配し、以下の手順を参考に Intune へデバイス登録されるように構成してください。

Microsoft Entra Join と連携して、Intune へ自動登録

ここまでの構成を行うと、Entra Join した PC へハイブリッドユーザーでサインインすると、適切な証明書と Wi-Fi プロファイルが配布されます。

完全に、すべての証明書と Wi-Fi プロファイルが配布されるまで、タイムラグがあるので注意してください。

ルート証明書と、中間証明書の配布状態は、Certlm.msc のコマンドで確認できます。

クライアント証明書（SCEP 証明書）の配布状態は、CertMgr.msc のコマンドで確認できます。

上記のクライアント証明書をダブルクリックして、以下の内容が確認できれば OK です。

Check 1

サブジェクトの代替名にサインインしたユーザー名が表示され、このユーザーアカウントがドメインに存在している。
拡張キー使用法が、クライアント認証で構成されている。

Check 2
証明書のパスが、ルート証明書、中間証明書、クライアント証明書の 3 階層で構成されていて、「この証明書は問題ありません。」と表示されている。

Wi-Fi プロファイルは、netsh wlan show profile で確認できます。

さいごに

ネットを探してみても、Cloud PKI と NPS を組み合わせた事例が無かったので、かなりハマったのですが、おかげで Cloud PKI の CA と BYOCA の違いをキチンと理解することがきましたし、SAN に指定する記述のカスタマイズも大事であることが判りました。

この記事が類似の構成にトライされている人の一助になれれば幸いです。

NPS を使った Wi-Fi 認証や、Intune の検証は、昨年 (2023 年 12 月) から初めて経験していったのですが、約 9 ヵ月でここまで構成できるようになったのは、感慨深いです。

参考にした記事
以下の海外の記事は、NPS の部分が RADIUSaaS というサービスに置き換わった構成ですが、こういった記事を熟読することで、NPS に適用する方法を考えるのに役立ちました。

以下は、MVP の Tamai さんの記事です。Tamai さんが開催する Intune 勉強会なども参加させていただき、学ばせていただいてます。
初めて Cloud PKI の証明書に着手する際に、足掛かりにさせていただきました。