Intune Cloud PKI と RADIUS 連携で証明書ベース Wi-Fi 認証をやってみた

こんにちは！tsuji です！

従来は AD CS といったオンプレ基盤中心の証明書管理基盤が多く使われてきましたが、最近ではクラウドのソリューションも増えてきています。Intune 管理のデバイスでは Intune Cloud PKI というクラウド型の証明書管理基盤が登場し、オンプレからクラウド中心の管理へ移行する手段の一つとして活用することもできます。

この記事では、Cloud PKI の基本的な機能や用途を整理したうえで、具体例として RADIUS (Wi-Fi 認証) 連携 を実際に構築する流れを紹介します。

Cloud PKI とは 🔑

Cloud PKI は、Intune に統合されたクラウドベースの PKI (公開鍵基盤) サービスです。Cloud PKI の CA 基盤自体は Microsoft がクラウド側で運用するため、AD CS のような自前の CA サーバーを構築・運用する必要はありません。

ただし本記事の例では Wi-Fi 認証 (EAP-TLS) のために RADIUS サーバーを利用しており、こちらは Cloud PKI とは別の役割としてオンプレ側で必要になります。

できること

• Root CA と Issuing CA (中間 CA) のクラウド上での発行・管理
• Intune 管理デバイスへの SCEP プロトコルでの証明書配布
• 証明書のライフサイクル管理 (発行・更新・失効)
• BYOCA (Bring Your Own CA)：既存のオンプレ Root CA (AD CS など) を残しつつ、発行元 CA だけを Cloud PKI に置く構成

主な用途

Cloud PKI が発行するクライアント証明書は、Microsoft 公式ドキュメントでは以下の用途が紹介されています。

• Wi-Fi 認証 (EAP-TLS)：RADIUS サーバーでの証明書ベース認証
• VPN 認証：証明書ベースの VPN クライアント認証
• S/MIME：メールの署名・暗号化

本記事で紹介するシナリオ 🎯

Cloud PKI の用途は多岐にわたりますが、本記事では具体例として RADIUS 連携による Wi-Fi 認証 (EAP-TLS) を例に構築手順を紹介します。

今回は、将来的に脱 AD を検討しており、Entra Join 端末を利用しつつもオンプレへのアクセスを継続することを想定したシナリオになります。

以下のような構成を想定しています。

• Entra Join + Intune 管理下の Windows 端末に、Cloud PKI からクライアント証明書を配布
• Entra Join 端末にて、オンプレミスの NPS サーバー経由で EAP-TLS の Wi-Fi 接続を可能とする

実際にラボ環境で動作確認しながら構築した内容をベースに紹介していきます。

認証方式の選択：ユーザー認証を採用

EAP-TLS の認証方式にはコンピューター認証とユーザー認証がありますが、本記事では ユーザー認証 を採用します。

理由は、今回の対象が Entra Join 端末で、Active Directory のコンピューターアカウントを持たないため、AD ベースでのコンピューター認証が使えないためです。

本ケースでは、Intune からの証明書配布もユーザー単位となるため、Wi-Fi を使わせたいユーザーだけに Intune プロファイルを割り当てることで、アクセス制御としても機能させます。

強いマッピング対応：SID を SAN に埋め込む

2022 年 5 月のセキュリティ更新 (KB5014754) 以降、証明書ベース認証では 証明書のサブジェクトとユーザーアカウントの強いマッピング が必要になりました。今回のような外部 CA (Cloud PKI) 発行の証明書でユーザー認証を成立させるには、証明書の SAN にユーザーの SID を埋め込む必要があります。

Intune の SCEP 証明書プロファイルでは {{OnPremisesSecurityIdentifier}} というプレースホルダーを使うことで、Entra Connect で同期された AD ユーザーの SID を自動的に証明書に埋め込めます。具体的な設定は Step 5 で扱います。

検証環境 🧪

簡易的な検証環境のため、込み入ったルーティング設定とかは行いませんが、以下のような構成になります。

構成図

各コンポーネントの役割

その他の前提条件 ⚠️

本検証では、以下の構成が前提となります。

インフラ側

• Active Directory ドメイン環境が構築済み
• Entra Connect によるユーザー同期が完了している
• Windows Server 2019 以降 (DC / AD CS / NPS)

Intune 側

• Microsoft Intune Suite または Cloud PKI アドオンライセンス
• 対象端末が Entra Join かつ Intune 管理下

構築のおおまかな流れ 🗺

ここから具体的な構築手順に入ります。全体の流れは以下のとおりです。

次章から、各ステップの手順を詳しく見ていきます。

Step 1. Cloud PKI の構築 🔑

Intune 管理センターから、Cloud PKI のルート CA と発行元 CA (Issuing CA) を作成します。CA 階層は 2 層構成となり、ルート CA の下に発行元 CA をぶら下げる形になります。

構築する CA は以下 2 つです。

1-1. Root CA の作成

Intune 管理センターで [テナント管理] > [クラウド PKI] を開き、[+ 作成] を選択します。

基本情報として 名前 (例：Lab-CloudPKI-Root-CA) を入力します。

[構成設定] で以下を指定します。

作成後、CA 一覧に Root CA が表示されたら完了です。

1-2. Issuing CA の作成

続けて発行元 CA を作成します。同じく [テナント管理] > [クラウド PKI] から [+ 作成] を選択します。

名前 (例：Lab-CloudPKI-Issuing-CA) を入力し、[構成設定] で以下を指定します。

作成後、CA 一覧に Issuing CA が表示されたら完了です。

1-3. CA 証明書のダウンロードと SCEP URI の控え

後のステップで使う情報を、このタイミングで取得しておきます。

ルート CA の証明書をダウンロード

1. CA 一覧から Lab-CloudPKI-Root-CA を選択
2. 画面を下にスクロールし、[ダウンロード] をクリックして .cer ファイルを保存 (例：Lab-CloudPKI-Root-CA.cer)

発行元 CA の証明書をダウンロード + SCEP URI を控える

1. CA 一覧から Lab-CloudPKI-Issuing-CA を選択
2. [プロパティ] タブを開き、画面を下にスクロール
3. [SCEP URI] に表示されている URL (例：https://{{CloudPKIFQDN}}/TrafficGateway/...) をコピーして控えておく
4. すぐ下にある [ダウンロード] をクリック → .cer ファイルを保存 (例：Lab-CloudPKI-Issuing-CA.cer)

ここで取得した 2 つの .cer ファイルと SCEP URI は、後続の Step 4 (NPS への証明書配置) および Step 5 (Intune プロファイル作成) で使用します。

Step 2. AD CS のセットアップ + NPS 用テンプレート作成 🏛

NPS サーバーは EAP-TLS 認証時に、自身を証明するための サーバー証明書 を必要とします。このサーバー証明書を発行するための AD CS をセットアップします。

本 Step で行う作業は以下 4 つです。

2-1. AD CS 役割のインストール

本検証では DC 上に AD CS を同居させます。DC サーバーに Enterprise Admins またはドメインの Domain Admins 権限でサインインし、サーバーマネージャーから以下を実施します。

1. サーバーマネージャーで [管理] → [役割と機能の追加] を選択
2. [インストールの種類] は既定値 ([役割ベースまたは機能ベースのインストール]) のまま進む
3. [サーバーの役割] で [Active Directory 証明書サービス] にチェック
4. [役割サービス] で [証明機関] を選択
5. インストールを実行

2-2. エンタープライズ ルート CA の構成

インストール完了後、サーバーマネージャーの旗マークから [対象サーバーに Active Directory 証明書サービスを構成する] を選択します。

構成ウィザードで以下を指定します。

構成完了後、サーバーマネージャーの [ツール] → [証明機関] で certsrv.msc が開き、CA が起動していれば成功です。

AD CS Root 証明書のエクスポート

後続の Step 5 (Intune プロファイル作成) で AD CS Root 証明書を使うため、このタイミングでエクスポートしておきます。

1. certsrv.msc で CA 名 (NV-ADDS01-CA) を右クリック → [プロパティ]
2. [全般] タブで [CA 証明書] 欄の証明書を選択し、[証明書の表示] をクリック
3. [詳細] タブに切り替え、[ファイルにコピー] をクリック
4. 証明書のエクスポートウィザードで以下を指定
   • 形式：Base 64 encoded X.509 (.CER)
   • ファイル名：C:\cert\ADCS-Root.cer

2-3. NPS サーバー証明書テンプレートの作成

NPS サーバーに配布するサーバー証明書用のテンプレートを、既存の [RAS および IAS サーバー] テンプレートを複製して作成します。

ファイル名を指定して実行から certtmpl.msc を起動し、証明書テンプレートコンソールを開きます。

1. 一覧で [RAS および IAS サーバー] を右クリック → [テンプレートの複製]
2. 複製されたテンプレートのプロパティで以下を設定

[全般] タブ

[セキュリティ] タブ

RAS and IAS Servers グループを選択し、アクセス許可として以下を付与します。

• 読み取り
• 登録
• 自動登録

設定後、[OK] を押してテンプレートを保存します。

2-4. CA にテンプレートを発行

作成したテンプレートは、CA に 発行する証明書テンプレート として登録しないと、実際の証明書発行には使えません。

1. certsrv.msc で [証明書テンプレート] を右クリック → [新規作成] → [発行する証明書テンプレート]
2. 表示される一覧から NPS-Server-Auth (2-3 で作成したテンプレート) を選択 → [OK]
3. [証明書テンプレート] 配下の一覧に NPS-Server-Auth が追加されていれば完了

これで NPS サーバー証明書を発行する準備が整いました。実際の証明書取得は、次の Step 3 で NPS サーバーから実施します。

Step 3. NPS の構築と基本設定 🛠

NPS サーバー (本検証では 192.168.10.25、ドメイン参加済み) で RADIUS サーバー機能を構築します。

本 Step で行う作業は以下 5 つです。

3-1. NPS 役割のインストール

NPS サーバーにサインインし、サーバーマネージャーから以下を実施します。

1. サーバーマネージャーで [管理] → [役割と機能の追加] を選択
2. [インストールの種類] は既定値 ([役割ベースまたは機能ベースのインストール]) のまま進む
3. [サーバーの役割] で [ネットワーク ポリシーとアクセス サービス] にチェック
4. [役割サービス] で [ネットワーク ポリシー サーバー] を選択 (既定で選択済み)
5. インストールを実行

3-2. Active Directory への NPS 登録

NPS が AD のユーザーアカウントのダイヤルインプロパティを読み取れるよう、NPS サーバーのコンピューターアカウントを RAS and IAS Servers グループに追加します。

1. サーバーマネージャーで [ツール] → [ネットワーク ポリシー サーバー] を選択
2. 左ペインの [NPS (ローカル)] を右クリック → [Active Directory にサーバーを登録]
3. 確認ダイアログで [OK]
4. 登録完了メッセージで [OK]

登録確認

DC 側で [Active Directory ユーザーとコンピューター] を開き、以下で確認します。

ドメイン名
  └ Users
      └ RAS and IAS Servers (ダブルクリック)
          └ [メンバー] タブに NPS サーバーのコンピューターアカウントが追加されている

3-3. NPS サーバー証明書の取得 (GPO 自動登録)

Step 2 で作成した NPS-Server-Auth テンプレートから、GPO の自動登録機能で NPS サーバー証明書を配布します。自動登録を使うと、初回発行だけでなく期限前の自動更新も行われるため、運用負荷が下がります。

GPO の作成・設定 (DC で実施)

1. DC で [グループポリシーの管理] を起動
2. NPS サーバーが所属する OU を右クリック → [このドメインに GPO を作成し、このコンテナーにリンクする]
3. GPO 名を入力 (例：Cert-AutoEnrollment-NPS)
4. 作成した GPO を右クリック → [編集]
5. [コンピューターの構成] → [ポリシー] → [Windows の設定] → [セキュリティの設定] → [公開キーのポリシー] を展開
6. [証明書サービスクライアント - 自動登録] をダブルクリック
7. 以下を設定

1. [OK] で保存

NPS サーバー側での GPO 適用と確認

NPS サーバーで以下を実行します。

gpupdate /force

certlm.msc を起動し、以下で証明書が配布されたことを確認します。

[個人] → [証明書]
  └ NPS-Server-Auth テンプレートから発行された証明書が追加されている

3-4. RADIUS クライアントの登録

Omada AP (本検証では 192.168.10.2) を NPS の RADIUS クライアントとして登録します。

1. ネットワーク ポリシー サーバーコンソールで [RADIUS クライアントとサーバー] を展開
2. [RADIUS クライアント] を右クリック → [新規]
3. 以下を入力

   設定項目	値
   このRADIUS クライアントを有効にする	チェック
   フレンドリ名	Omada-EAP225 (任意)
   アドレス (IP または DNS)	192.168.10.2
   共有シークレット	任意の強力なパスワード (AP 側で同じ値を設定)

   

4. [OK] を押して登録

Omada AP 側の設定

Omada AP で Wireless Settings の構成を設定します。

• SSID：CORP-CloudPKI
• Security Mode：WPA-Enterprise
• Version：WPA/WPA2 - Enterprise
• Encryption：AES
• RADIUS Server IP：192.168.10.25 (NPS サーバー)
• RADIUS Port：1812
• RADIUS Password：上で設定した値
• RADIUS Accounting：Enable ※ ログを送信したい場合
• Accounting Server IP：192.168.10.25 (NPS サーバー)
• Accounting Port：1813
• Accounting Password：上で設定した値

3-5. ネットワークポリシーの作成

RADIUS クライアントからの認証要求をどの条件で許可するかを定義します。

1. ネットワーク ポリシー サーバーコンソールで [ポリシー] → [ネットワーク ポリシー] を右クリック → [新規]
2. 以下の流れで設定

ポリシー名の入力

条件の指定

以下の条件を追加します。

アクセス許可の指定

• [アクセスを許可する] を選択

認証方法の構成

1. [追加] をクリック
2. [Microsoft スマートカードまたはその他の証明書] を選択 → [OK]
3. 追加された認証方法を選択 → [編集] をクリック
4. [証明書の発行先] で、3-3 で取得した NPS サーバー証明書を選択 → [OK]
5. セキュリティの低い認証方法 ([MS-CHAP v2]、[MS-CHAP]、[PAP] 等) のチェックをすべて外す

制約・設定の確認

残りの画面は既定値のまま進めて [完了] で作成します。

ポリシーの適用順序

ネットワークポリシーは上から順に評価され、条件に合致した最初のポリシーが適用されます。作成した Wi-Fi-EAP-TLS-UserAuth が一覧の上位にあることを確認してください。

これで NPS の基本設定が完了しました。次の Step 4 で、Cloud PKI のルート / 発行元 CA 証明書を NPS サーバーに配置し、Cloud PKI 発行のクライアント証明書を NPS が信頼できるようにします。

Step 4. Cloud PKI 証明書を NPS に配置 🔐

EAP-TLS 認証では、NPS サーバーが受け取るクライアント証明書 (Cloud PKI 発行) のチェーン検証が必要です。NPS サーバーに Cloud PKI の信頼チェーンを配置 し、さらに NTAuth ストアに発行元 CA を登録 することで、NPS が Cloud PKI 発行のクライアント証明書を認証に使えるようになります。

本 Step で行う作業は以下 3 つです。

事前準備として、Step 1-3 でダウンロードした以下 2 つの .cer ファイルを NPS サーバーの任意の場所 (例：C:\cert\) に配置しておきます。

• Lab-CloudPKI-Root-CA.cer
• Lab-CloudPKI-Issuing-CA.cer

4-1. Cloud PKI Root CA を [信頼されたルート証明機関] に配置

NPS サーバーがチェーンのルートとして Cloud PKI Root CA を信頼できるようにします。

1. NPS サーバーで [Windows] アイコンを右クリック → [ファイル名を指定して実行] → certlm.msc を入力して [OK]
2. [信頼されたルート証明機関] → [証明書] を右クリック → [すべてのタスク] → [インポート]
3. 証明書のインポートウィザードで Lab-CloudPKI-Root-CA.cer を選択
4. 証明書ストアは [信頼されたルート証明機関] のまま [次へ] → [完了]

確認

[信頼されたルート証明機関] → [証明書] の一覧に Lab-CloudPKI-Root-CA が表示されていれば OK です。

4-2. Cloud PKI Issuing CA を [中間証明機関] に配置

チェーンの中間として Cloud PKI Issuing CA を配置します。4-1 で開いた certlm.msc をそのまま使います。

1. [中間証明機関] → [証明書] を右クリック → [すべてのタスク] → [インポート]
2. Lab-CloudPKI-Issuing-CA.cer を選択
3. 証明書ストアは [中間証明機関] のまま [次へ] → [完了]

確認

[中間証明機関] → [証明書] の一覧に Lab-CloudPKI-Issuing-CA が表示されていれば OK です。

4-3. Cloud PKI Issuing CA を NTAuth ストアに登録

これが Cloud PKI + NPS 連携で最も重要なポイントです。

NPS の EAP-TLS 認証では、クライアント証明書を発行した CA が NTAuth ストア (AD 構成パーティション配下の NTAuthCertificates オブジェクト) に登録されていないと認証が失敗します。AD CS が発行した証明書は自動的に NTAuth に登録されますが、Cloud PKI は AD 外部の CA なので手動登録が必要です。

DC 側 (AD CS サーバー) での登録手順

DC (AD CS 同居サーバー) に Enterprise Admins 権限でサインインし、Lab-CloudPKI-Issuing-CA.cer を任意の場所 (例：C:\cert\) に配置します。

1. [Windows] アイコンを右クリック → [ファイル名を指定して実行] → pkiview.msc を入力して [OK]
2. 左ペインの [エンタープライズ PKI] を右クリック → [AD コンテナーの管理]
3. [NTAuthCertificates] タブを選択 → [追加] ボタンをクリック
4. Lab-CloudPKI-Issuing-CA.cer を選択 → [開く]
5. 確認ダイアログで [OK]

確認

[NTAuthCertificates] タブを開き直し、Lab-CloudPKI-Issuing-CA が一覧に表示されていれば登録成功です。

NPS サーバーへの即時反映

NTAuth ストアの情報を NPS サーバーに即時反映するため、NPS サーバーで以下を実行します。

gpupdate /force

これで NPS 側の Cloud PKI 信頼構成が完了しました。NPS サーバーは Cloud PKI 発行のクライアント証明書を正当な証明書として検証できるようになりました。次の Step 5 で Intune のプロファイルを作成し、端末に Cloud PKI の証明書を配布します。

Step 5. Intune プロファイル作成 📲

Intune 管理下の Windows 端末に、以下を配布するためのプロファイルを作成します。

なぜルート証明書を 2 つ配布するのか

EAP-TLS では 相互認証 (クライアント⇔サーバーの双方向検証) が行われるため、両方の信頼チェーンが必要です。

Entra Join 端末は AD ドメイン非参加のため、AD CS の Root 証明書は自動配布されません。Intune 経由で明示的に配布する必要があります。

割り当て先は「ユーザーグループ」

本記事では Step 5 の 4 プロファイルすべてを ユーザーグループ に割り当てます。5-3 の SCEP プロファイルでユーザー証明書 (CN={{UserPrincipalName}}) を発行する構成なので、配布対象もユーザー単位に揃えます。Wi-Fi を使わせたいユーザーだけを含むグループを作っておくと、アクセス制御として機能します。

5-1. 信頼された証明書プロファイル (Cloud PKI Root)

Intune 管理センターで [デバイス] → [構成] → [+ 作成] → [新しいポリシー] を開き、プラットフォーム：Windows 10 以降、プロファイルの種類：テンプレート → [信頼された証明書] を選択して [作成] を押します。

[基本] タブ

• 名前：TrustedRoot-CloudPKI

[構成設定] タブ

[割り当て] タブで検証用ユーザーグループを指定し、[確認+作成] で作成します。

5-2. 信頼された証明書プロファイル (AD CS Root)

5-1 と同じ手順で、プラットフォーム：Windows 10 以降、プロファイルの種類：テンプレート → [信頼された証明書] を選択します。

[基本] タブ

• 名前：TrustedRoot-ADCS

[構成設定] タブ

[割り当て] タブで 5-1 と同じユーザーグループを指定して [確認+作成] で作成します。

5-3. SCEP 証明書プロファイル

Cloud PKI の発行元 CA からユーザー証明書を配布します。

[デバイス] → [構成] → [+ 作成] → [新しいポリシー] を開き、プラットフォーム：Windows 10 以降、プロファイルの種類:テンプレート → [SCEP 証明書] を選択して [作成] を押します。

[基本] タブ

• 名前：SCEP-CloudPKI-UserAuth

[構成設定] タブ

[割り当て] タブで検証ユーザーを含むユーザーグループを指定し、[確認+作成] で作成します。

5-4. Wi-Fi プロファイル

配布したクライアント証明書を使って Wi-Fi に接続するためのプロファイルを作成します。

[デバイス] → [構成] → [+ 作成] → [新しいポリシー] を開き、プラットフォーム：Windows 10 以降、プロファイルの種類：テンプレート → [Wi-Fi] を選択して [作成] を押します。Wi-Fi の種類は [エンタープライズ] を選択します。

[基本] タブ

• 名前：WiFi-CORP-CloudPKI

[構成設定] タブ

[割り当て] タブで 5-1 と同じユーザーグループを指定して [確認+作成] で作成します。

ここまでで Intune 側の構成は完了です。プロファイルが適用された端末では、以下の順序で自動的に Wi-Fi 認証が成立するはずです。

1. TrustedRoot-CloudPKI / TrustedRoot-ADCS で 2 つのルート CA が配布される
2. SCEP-CloudPKI-UserAuth で Cloud PKI 発行のユーザー証明書が端末に配布される
3. WiFi-CORP-CloudPKI で SSID・認証方式が設定される
4. 端末が SSID に接続を試みると、Cloud PKI のクライアント証明書を NPS に提示
5. NPS は AD CS のサーバー証明書で自身を証明し、クライアント証明書を NTAuth 経由で検証
6. 認証成功、Wi-Fi 接続完了

次の Step 6 で実際にクライアント端末から動作確認を行います。

Step 6. 動作確認 ✅

ここまで構築した環境で実際に Wi-Fi 接続が成立するかを確認します。以下 3 つの観点で検証します。

6-1. クライアント端末での証明書配布確認

Intune 管理下の Windows 端末 (対象ユーザーでサインイン済み) で、3 種類の証明書が正しく配布されているかを確認します。

ルート証明書 (2 つ) の確認

[Windows] アイコンを右クリック → [ファイル名を指定して実行] → certlm.msc を入力して [OK] を押します。

[信頼されたルート証明機関] → [証明書] の一覧に以下 2 つが存在することを確認します。

ユーザー証明書 (Cloud PKI 発行) の確認

ユーザー証明書はローカルコンピューターではなく現在のユーザーのストアに配布されるため、別のコンソールで確認します。

[Windows] アイコンを右クリック → [ファイル名を指定して実行] → certmgr.msc を入力して [OK] を押します。

[個人] → [証明書] の一覧に、発行先 (発行対象) がサインインしているユーザーの UPN で表示されている証明書が存在することを確認します。

証明書をダブルクリックし、[証明のパス] タブで Lab-CloudPKI-Root-CA → Lab-CloudPKI-Issuing-CA → ユーザー証明書 のチェーンが成立し、「この証明書は問題ありません」と表示されていれば OK です。

配布されていない場合：Intune 管理センター側の確認

端末側で証明書が見当たらない場合は、Intune 管理センターの [デバイス] → 対象デバイスを選択 → [デバイスの構成] で、配布した各プロファイル (TrustedRoot-CloudPKI / TrustedRoot-ADCS / SCEP-CloudPKI-UserAuth / WiFi-CORP-CloudPKI) のステータスを確認します。エラー や 保留中 になっているプロファイルがあれば、そこが原因の可能性が高いです。

6-2. Wi-Fi 接続確認

クライアント端末のタスクトレイからネットワークアイコンをクリックし、SSID CORP-CloudPKI を選択して接続を試みます。

Intune から配布した Wi-Fi プロファイルが適用されていれば、ユーザー ID やパスワードを求められることなく、証明書ベースの認証が自動的に実行されて接続が成立します。

接続状態が「接続済み、セキュリティ保護あり」になっていれば成功です。

6-3. NPS サーバー側の認証成功ログ確認

NPS サーバーでイベントビューアーを開き、認証が成功していることをログから確認します。

1. NPS サーバーで [Windows] アイコンを右クリック → [ファイル名を指定して実行] → eventvwr.msc を入力して [OK]
2. [カスタムビュー] → [サーバーの役割] → [ネットワーク ポリシーとアクセス サービス] を選択
3. イベント ID 6272 (ネットワーク ポリシー サーバーがユーザーにフル アクセスを許可しました) を探す

成功ログで確認するポイント

ここまでで検証は完了です。クライアント端末 (Entra Join + Intune 管理下) が Cloud PKI 発行のクライアント証明書を使って、オンプレミスの NPS 経由の EAP-TLS 認証で Wi-Fi に接続できることが確認できました。

詰まりやすいポイント ⚠️

今回の検証で実際に遭遇した、または構成上ハマりやすいと感じたポイントをまとめます。

NTAuth ストアへの Issuing CA 登録忘れ

本記事で最もハマりやすいポイントです。Cloud PKI の Issuing CA を NTAuth ストアに登録し忘れると、NPS の EAP-TLS 認証でクライアント証明書の検証に失敗します。

症状

• Wi-Fi 接続時にサーバー証明書の検証エラーまたはユーザー認証エラー
• NPS のイベントログに イベント ID 6273 / 理由コード 295 (指定された証明書を検証することができませんでした) が記録される

対処

Step 4-3 の pkiview.msc から NTAuth への登録を確認します。登録後、NPS サーバーで gpupdate /force を実行して反映させます。

Wi-Fi プロファイルのサーバー名と NPS サーバー証明書 SAN の不一致

Wi-Fi プロファイル (Step 5-4) の [サーバー名] に指定した FQDN は、NPS サーバー証明書の Subject Alternative Name (SAN) と文字列として完全に一致する必要があります。不一致だと、クライアントがサーバー証明書を信頼せず接続失敗します。

症状

• Wi-Fi 接続時に「このネットワークに接続できません」などの一般的なエラー
• クライアント側イベントログで「サーバー名が一致しません」系の警告

対処

NPS サーバーで certlm.msc → [個人] → [証明書] から NPS サーバー証明書を開き、[詳細] タブの [サブジェクトの別名] に記載されている DNS 名を Wi-Fi プロファイル側と一致させます。

NPS が RAS and IAS Servers グループに未登録

Step 3-2 の AD 登録を実施していないと、NPS サーバーがテンプレートからサーバー証明書を取得できず、結果として EAP-TLS の Server Hello 送信に失敗します。

対処

NPS コンソールで [NPS (ローカル)] を右クリック → [Active Directory にサーバーを登録] を実行します。DC 側で RAS and IAS Servers グループのメンバーに NPS サーバーのコンピューターアカウントが追加されていることを確認します。

NPS 監査ログが無効でイベントが出ない

NPS の監査ログが無効になっていると、認証成功 / 失敗のイベント (6272 / 6273) がイベントログに記録されません。トラブルシュート時に情報源が無くなるため、検証環境でも有効にしておくことを推奨します。

対処

NPS サーバーで管理者権限の PowerShell から以下を実行します。

auditpol.exe /get /subcategory:"Network Policy Server"
auditpol.exe /set /subcategory:"Network Policy Server" /success:enable /failure:enable

まとめ ✅

本記事では、Intune Cloud PKI から発行したクライアント証明書と、オンプレミスの NPS / AD CS を組み合わせて、Entra Join + Intune 管理下の Windows 端末で EAP-TLS による Wi-Fi 認証を成立させる構成を紹介しました。

実現できたことを整理すると以下のとおりです。

• Cloud PKI によるクラウド完結のクライアント証明書発行
• オンプレ NPS での RADIUS 認証との連携 (NTAuth ストア登録含む)
• Entra Join 端末に対するユーザー認証 (強いマッピング対応)
• Intune プロファイルでの証明書・Wi-Fi 設定の一括配布

既存の NPS / AD CS 資産をそのまま活かしつつ、クライアント証明書の発行基盤だけを Cloud PKI に置き換えるこの構成は、脱 AD に向けた段階的な移行アプローチ として有効です。

興味があればぜひ Cloud KPI をお試しください。最後までお読みいただきありがとうございました！

参考ドキュメント

Microsoft 公式

• Microsoft Cloud PKI for Microsoft Intune
• Microsoft Cloud PKI のルートと発行元 CA を構成する
• サード パーティの証明機関 (CA) を Enterprise NTAuth ストアにインポートする
• EAP-TLS を使用する場合の証明書の要件
• Active Directory ドメインに NPS を登録する
• ネットワーク リモート アクセス用のサーバー証明書テンプレートを構成する