Intune Cloud PKI + NPS を使って、Wi-Fi 認証 できた！しかし・・・

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

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

https://qiita.com/carol0226/items/6c707d70fe7251346cf4

（上記の記事より抜粋）
① 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 に クライアント証明書 の認証で接続できるようにする事が目標です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/9e857f4c-6194-5ed5-67aa-c0662cabfc16.png)

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

https://qiita.com/carol0226/items/564a21455cd3e5f58906

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

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

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

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

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

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

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

:::note alert
**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 認証を行えることを実証できました。

**動作させることに成功した構成のイメージ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a3bd6add-d5d3-30d3-0512-aa42f366774f.png)

**この構成での問題点**（動作はするけど、美しくない）
ひとまず、最低限 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 のライセンス費用は掛かりません。

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

https://qiita.com/carol0226/items/472747e7308762ca0ce1

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

**目指すべき構成のイメージ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a6dde828-407a-edab-5e30-dfd7e15ebf4d.png)

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

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

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

（再掲）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/44b4bf26-de1e-b75b-1a2d-e7c64daa1be9.png)

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

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

https://qiita.com/carol0226/items/564a21455cd3e5f58906

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

https://qiita.com/carol0226/items/487874f07d2fe90f8e0c

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

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

https://qiita.com/carol0226/items/dab8390fb8f4420559da

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

https://qiita.com/carol0226/items/efbeb78c93d903403676

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

https://qiita.com/carol0226/items/6529a423573ed246305f

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

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

https://learn.microsoft.com/ja-jp/mem/intune/protect/microsoft-cloud-pki-configure-ca?wt.mc_id=mvp_407731

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

https://learn.microsoft.com/ja-jp/mem/intune/protect/microsoft-cloud-pki-configure-byoca?wt.mc_id=mvp_407731

## 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 を開き、以下の場所からダウンロードした ルート証明書 をダウンロードしておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/302f424f-c199-a04e-2825-c5b16018370b.png)

以下の手順で、**信頼済み証明書** の配布用の 構成プロファイルを作成します。
Cloud PKI の CA の場合は、ルート証明書が２種類あるため、構成プロファイルを２つ作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/92903c48-41dd-46d1-63c6-66441efa0035.png)

**コンピューター証明書ストア - ルート** を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/0f95a053-b602-4796-fe0c-123eee7c9721.png)

ここで、ダウンロードしておいた Cloud PKI または オンプレミス のルート証明書 を指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/86c5a65a-173c-945f-4d54-e9ee6a29564f.png)

以下のように 一覧に表示された状態になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e24c1c0f-326b-a2e9-39f4-c2a6888595cf.png)

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

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

Intune 管理センターの CA 管理 から、作成した「Cloud PKI の 中間 CA」または 「BYOCA」を開き、以下の場所から 中間証明書 をダウンロードしておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/302f424f-c199-a04e-2825-c5b16018370b.png)

構成プロファイルで **信頼済み証明書** を作成する際に、**コンピューター証明書ストア - 中間** を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/10fe4444-2fa2-eaaf-d8e3-e069ffd863cf.png)

ダウンロードしておいた 中間証明書 を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/44f2fb53-6f52-e7b2-5712-eb5c26be2669.png)

以下のように 一覧に表示された状態になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/718957f0-f8ef-9a76-14b0-6873e4183b25.png)

## 8. SCEP 証明書
作成した Cloud PKI CA の中間証明書 または BYOCA を開き、以下の場所から SCEP の URL をコピーします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/9326681b-2f7d-3b69-c6d9-8256f690155e.png)

**証明書の種類** は、ユーザー で作成するのがポイントです。
SCEP サーバーの URL 欄に、コピーしておいた URL を貼り付けます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/b31ec87d-3ea4-8d7a-1d67-2d8eac959a48.png)

以下のように 一覧に表示された状態になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/25f25287-86f6-ca89-2fc3-9b2ad47a5f94.png)

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

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

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

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

https://learn.microsoft.com/ja-jp/mem/intune/protect/certificates-profile-scep?wt.mc_id=mvp_407731

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

https://qiita.com/carol0226/items/3b17a2c02c5791727e93

**上記の記事からの変更点**
- 認証モード を ユーザー に変更する
- EAP の種類は、サーバー側と合わせてください（上記の Qiita 記事とズレがあるので注意）
以下のキャプチャは、サーバー側が EAP-TLS の場合です。
サーバー側が PEAP (EAP-TLS) の場合は、クライアント側も それに合わせます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/73dc911c-1ebc-7090-9984-30880b65989b.png)

以下のように 一覧に表示された状態になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e397b51e-414a-fc62-94ad-423099755f20.png)

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

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

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

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

https://qiita.com/carol0226/items/5dde4fe77220f4388945

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

https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/import-third-party-ca-to-enterprise-ntauth-store?wt.mc_id=mvp_407731

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c7141283-77be-97da-fba8-f3ff2bdda8fe.png)

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

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

https://qiita.com/carol0226/items/e75b04f2a6a99fa6bcf7

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

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

ルート証明書と、中間証明書 の配布状態は、Certlm.msc のコマンドで確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/b80aa373-a217-0781-83de-5000abf68180.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/de1b8643-3f96-7545-f93f-9250151d812c.png)

クライアント証明書（SCEP 証明書）の配布状態は、CertMgr.msc のコマンドで確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c6f90eb4-a8da-0ac7-e50c-b85e09fb123d.png)

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

**Check 1**
- サブジェクトの代替名に サインインした ユーザー名が表示され、このユーザーアカウントが ドメイン に存在している。
- 拡張キー使用法が、クライアント認証 で構成されている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/0b5bee1f-7208-4027-1247-798886ab831f.png)

**Check 2**
証明書のパスが、ルート証明書、中間証明書、クライアント証明書 の 3 階層で構成されていて、「この証明書は問題ありません。」と表示されている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/5126dbce-fc89-3107-c3d9-8e9293174be5.png)

Wi-Fi プロファイルは、netsh wlan show profile で確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/53a3971c-2957-759f-4b86-66060400573e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/20f39177-6a6b-91c1-75eb-114a0bcf19d5.png)

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

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

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

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

https://oliverkieselbach.com/2024/03/04/how-to-configure-cloud-pki-certificate-based-wifi-with-intune/

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

https://sccm.jp/2024/05/01/post-6220/